Home issueshttps://community.opengroup.org/osdu/platform/security-and-compliance/home/-/issues2021-06-08T19:01:43Zhttps://community.opengroup.org/osdu/platform/security-and-compliance/home/-/issues/36Entitlement Exception Mechanism2021-06-08T19:01:43ZPaco Hope (AWS)Entitlement Exception Mechanism## Status
- [X] Proposed
- [ ] Trialing
- [ ] Under review
- [ ] Approved
- [ ] Retired
## Context & Scope
Typically, entitlements are strictly enforced. There are no exceptions. In reality, all rules will have exceptions from time to...## Status
- [X] Proposed
- [ ] Trialing
- [ ] Under review
- [ ] Approved
- [ ] Retired
## Context & Scope
Typically, entitlements are strictly enforced. There are no exceptions. In reality, all rules will have exceptions from time to time. The entitlement mechanism must have a means of permitting exceptions. Ideally, exceptions will be isolated.
## Decision
There needs to be a clear mechanism by which exceptions to rules are implemented. Either by implementing special-purpose, focused rules, or through something else. Given a rule like "users from this country cannot access data with attribute Y" there needs to be a method of saying "except user A" or similar.
## Rationale
Exceptions are conceptually different for operators: temporary or permanent, based on job role, business unit, or individual needs. They are likely to run on different lifecycles. (e.g., broad rule for a whole business unit doesn't change, but temporary exceptions are granted and revoked).
## Consequences
Perhaps defining a different kind of rule, or changing the execution order/precedence.
## When to revisit
In case of performance degradation.
## Decision criteria and trade-offs
- Usability
- Maintainability
- Configurability
- Performance
## Decision timeline
July 2020 - Proposedhttps://community.opengroup.org/osdu/platform/security-and-compliance/home/-/issues/35Entitlements for derived data2020-10-21T12:39:47ZHrvoje MarkovicEntitlements for derived data## Status
- [X] Proposed
- [x] Trialing
- [x] Under review
- [x] Approved
- [ ] Retired
## Context & Scope
The OSDU data platform supports data derivatives as part of enrichment steps. These derivatives can be created from multiple pa...## Status
- [X] Proposed
- [x] Trialing
- [x] Under review
- [x] Approved
- [ ] Retired
## Context & Scope
The OSDU data platform supports data derivatives as part of enrichment steps. These derivatives can be created from multiple parent sources; each with a different entitlement model.
## Decision
In OSDU R3, all derived data will contain the required information to enforce the entitlements and policies. No traversal of original data used for derivatives will be done during entitlements or policy enforcements.
## Rationale
- Current use cases do not require dynamic traversal.
- Complexity of supporting dynamic traversal in R3 would increase the risks of delivering policy engine in given timeframe.
- Users should first get accustomed to simple policies before supporting traversal since this would increase the chances for catastrophic user errors.
- We can easily revisit this in the future.
## Consequences
Derivatives' ACLs would not have a dynamic link to original data ACLs. If additional information is used in policies, this additional information would have to be added to derivative's record.
## Alternatives and implications
One could use dynamic traversal.
## Decision criteria and trade-offs
- Simplicity
- Time to market
- Performance
## Decision timeline
July 2020M1 - Release 0.1Hrvoje MarkovicHrvoje Markovichttps://community.opengroup.org/osdu/platform/security-and-compliance/home/-/issues/34Entitlements: Default closed2020-10-21T12:38:49ZHrvoje MarkovicEntitlements: Default closed## Status
- [X] Proposed
- [x] Trialing
- [x] Under review
- [x] Approved
- [ ] Retired
## Context & Scope
## Decision
In OSDU R3, OSDU will be a default closed system.
OSDU public documentation should include example how to conf...## Status
- [X] Proposed
- [x] Trialing
- [x] Under review
- [x] Approved
- [ ] Retired
## Context & Scope
## Decision
In OSDU R3, OSDU will be a default closed system.
OSDU public documentation should include example how to configure an existing OSDU environment to be an open one. Similarly, OSDU R3 configuration coming from OSDU, will include a setup that uses existing entitlements service and/or additional user attributes to ensure behavior that is consistent with OSDU R2 behavior.
## Rationale
From the security perspective, one would want the default setting to be the tightest possible, ensuring that the system is secure by default.
## Consequences
- System is configurable.
- System is secure by default.
## Decision criteria and trade-offs
- Configurability
- Usability
- Performance
## Decision timeline
July 2020M1 - Release 0.1Hrvoje MarkovicHrvoje Markovichttps://community.opengroup.org/osdu/platform/security-and-compliance/home/-/issues/33Entitlements granularity2020-10-21T12:38:18ZHrvoje MarkovicEntitlements granularity## Status
- [X] Proposed
- [x] Trialing
- [x] Under review
- [x] Approved
- [ ] Retired
## Context & Scope
We need to define what is the granularity at which entitlements can be applied.
## Decision
In OSDU R3, we continue to suppo...## Status
- [X] Proposed
- [x] Trialing
- [x] Under review
- [x] Approved
- [ ] Retired
## Context & Scope
We need to define what is the granularity at which entitlements can be applied.
## Decision
In OSDU R3, we continue to support record level entitlements. We will not support entitling on an attribute or a sub-document level.
Since policies themselves will be contextualized to OSDU environment and to data partitions, it will be possible to have an OSDU environment or a partitions that does not use record level entitlements.
## Rationale
- Record level entitlements ensure back-compatibility to R2.
- Entitling on an attribute or a sub-document level is not required by OSDU R3 E&O use cases.
- Complexity of entitling on an attribute or a sub-document level would be very high and is not feasible within R3 scope.
## Consequences
- Back-compatibility to R2 preserved.
## Decision criteria and trade-offs
- Performance
- Usability
## Decision timeline
July 2020M1 - Release 0.1Hrvoje MarkovicNitesh Selkarijeyakumar DevarajuluHrvoje Markovichttps://community.opengroup.org/osdu/platform/security-and-compliance/home/-/issues/32Policies: scalability and performance2021-07-20T19:54:08ZHrvoje MarkovicPolicies: scalability and performance## Status
- [X] Proposed
- [x] Trialing
- [x] Under review
- [ ] Approved
- [ ] Retired
## Context & Scope
When evaluating a policy engine, its scalability and performance are one of the critical trade-offs. We should seek to test th...## Status
- [X] Proposed
- [x] Trialing
- [x] Under review
- [ ] Approved
- [ ] Retired
## Context & Scope
When evaluating a policy engine, its scalability and performance are one of the critical trade-offs. We should seek to test the example policies with data volumes and complexities that represent what is considered 'normal' user scenarios.
## Decision
We expect to support following volumes in an OSDU R3 data partition:
< 1e9 data items
< 1000 of policies
We expect following performance:
< 100 ms for policy evaluation when a typical request is made to storage or search in case of typical OSDU deployment.
## Rationale
We need to prove that not only does it work in the sense of enforcing policies but also that the performance is acceptable in normal usage.
## Consequences
Likely to be some consequences in terms of the number and complexity of policies that can be supported.
Expect limitations on the granularity at which entitlement can be applied (without impacting performance)
## When to revisit
Once criteria in the decision is not met.
## Decision criteria and trade-offs
Granularity at which entitlement can be set versus performance
Number and complexity of policies versus performance
## Decision timeline
July 2020Hrvoje MarkovicHrvoje Markovichttps://community.opengroup.org/osdu/platform/security-and-compliance/home/-/issues/31Policies and API authorization2021-06-08T19:01:52ZHrvoje MarkovicPolicies and API authorization## Status
- [X] Proposed
- [x] Trialing
- [ ] Under review
- [ ] Approved
- [ ] Retired
## Context & Scope
R2 uses entitlements service and service groups to manage API authorization. API authorization can be viewed as just another fo...## Status
- [X] Proposed
- [x] Trialing
- [ ] Under review
- [ ] Approved
- [ ] Retired
## Context & Scope
R2 uses entitlements service and service groups to manage API authorization. API authorization can be viewed as just another form of policy enforcement.
## Decision
In R3, API authorization should be external from service implementation. Consider feasibility of using policies as API authorization in R3. Document findings and conduct a review. If feasible and accepted, replace current implementation with policies that ensure API authorization.
## Rationale
API authorization can be viewed as just another form of policy enforcement.
## Consequences
Simplification of OSDU implementation and administration.
## When to revisit
In case of performance degradation.
## Alternatives and implications
- Leave API authorization as it is in R2.
- Use different type of policies for API authorization from data entitlements and obligations.
## Decision criteria and trade-offs
- Performance
- Usability
- Configurability
- Maintainability
## Decision timeline
July 2020M1 - Release 0.1Hrvoje MarkovicHrvoje Markovic2020-11-23https://community.opengroup.org/osdu/platform/security-and-compliance/home/-/issues/30Policy enforcement in search and storage2021-06-08T18:59:31ZHrvoje MarkovicPolicy enforcement in search and storage## Status
- [X] Proposed
- [x] Trialing
- [x] Under review
- [x] Approved
- [ ] Retired
## Context & Scope
We need to be able to enforce policies in different services in OSDU. When talking about data, *storage* and *search* services ...## Status
- [X] Proposed
- [x] Trialing
- [x] Under review
- [x] Approved
- [ ] Retired
## Context & Scope
We need to be able to enforce policies in different services in OSDU. When talking about data, *storage* and *search* services present different type of the problem. In *storage*, a simple evaluation of requested record against policies will suffice. In case of *search*, it is unpractical to split user query and evaluation of policies (imagine internally fetching million records and evaluating each one separately).
## Decision
Design how policies will be enforced in storage and search service. In case of search, evaluate feasibility of treating policies as Elasticsearch obligations. Once design is reviewed, proceed with implementation.
## Rationale
*Storage* and *search* are key services to which policies should be applied.
## Consequences
Ability to satisfy OSDU R3 use cases.
## When to revisit
N/A
## Decision criteria and trade-offs
N/A
## Decision timeline
July 2020M1 - Release 0.1Hrvoje MarkovicNitesh Selkarijeyakumar DevarajuluHrvoje Markovic2020-11-23https://community.opengroup.org/osdu/platform/security-and-compliance/home/-/issues/29ACLs and policies2021-06-08T18:59:26ZHrvoje MarkovicACLs and policies## Status
- [X] Proposed
- [x] Trialing
- [x] Under review
- [x] Approved
- [ ] Retired
## Context & Scope
R2 already has entitlements service and ACLs on storage records that are used to control access to data. We need to define how ...## Status
- [X] Proposed
- [x] Trialing
- [x] Under review
- [x] Approved
- [ ] Retired
## Context & Scope
R2 already has entitlements service and ACLs on storage records that are used to control access to data. We need to define how do ACLs and policies relate to each other in R3 and beyond.
## Decision
Evaluate feasibility of making current ACL enforcement a policy:
- Define a policy that would require that a user group is in the ***acl.viewers*** list of the record for a user to be able to view the record in the *storage* and find in the *search*
- Define a policy that would require that a user group is in the ***acl.owners*** list of the record for a user to be able to view/modify the record in the *storage* and find in the *search*
- Evaluate the performance of using policy vs R2 implementation
If feasible:
- Replace R2 implementation with policy
- Make ACL policy part of default OSDU setup
## Rationale
Depending on the CSP and service in question (e.g., search vs storage), current implementation does actually treat it that way. It is just that the policy is not written in a generic way.
## Consequences
- Simplification of the overall system
- ACL enforcement becomes configurable by owner of the OSDU instance
- Potential drop in performance
- Implications for data definitions and data loading teams - all currently working on the understanding that ACL's must be present upon load.
## When to revisit
Once the feasibility has been evaluated.
## Decision criteria and trade-offs
- Performance
- Simplicity
- Customizability
## Decision timeline
July 2020M1 - Release 0.1Hrvoje MarkovicNitesh SelkariHrvoje Markovic2020-11-23https://community.opengroup.org/osdu/platform/security-and-compliance/home/-/issues/28Policy scope and context2020-10-21T12:26:07ZHrvoje MarkovicPolicy scope and context## Status
- [X] Proposed
- [x] Trialing
- [x] Under review
- [x] Approved
- [ ] Retired
## Context & Scope
OSDU has concept of data partition. All the resource in OSDU R2 are accessed and manipulated in the context of data partition (...## Status
- [X] Proposed
- [x] Trialing
- [x] Under review
- [x] Approved
- [ ] Retired
## Context & Scope
OSDU has concept of data partition. All the resource in OSDU R2 are accessed and manipulated in the context of data partition (*data-partition-id* is a header in OSDU APIs). It seems intuitive that policies will be defined in relation to data partition.
We could consider additionally scoping policies to collections or some other container(s).
We could also consider policies to be independent of data partitions.
## Decision
In OSDU R3, we will start with policies that can be applied to an OSDU environment (all data partitions in that environment) and policies that are data partition specific.
Other containers as a scope for policy definition will not considered in R3.
## Rationale
OSDU environment level policies:
- Allow an organization to systematically apply policies across assets in all data partitions;
- Ensure a simple, easy to manage solution when data partition specific policies are not required.
Data partition level policies:
- Allow to differentiate policies for different data partitions (e.g., dev data partition vs prod data partition).
## Consequences
Current proposal satisfies authorization and compliance use cases in R2 and known use cases for R3.
## When to revisit
Once first version of policy service is delivered and/or additional use cases are identified that would require policies to be contextualized to a container of finer granularity than a data partition is.
## Decision criteria and trade-offs
* Performance
* Usability
## Decision timeline
July 2020M1 - Release 0.1Hrvoje MarkovicHrvoje Markovichttps://community.opengroup.org/osdu/platform/security-and-compliance/home/-/issues/27Policy language2021-06-08T18:59:23ZHrvoje MarkovicPolicy language## Status
- [X] Proposed
- [x] Trialing
- [x] Under review
- [x] Approved
- [ ] Retired
## Context & Scope
A language is required to write policies. [Rego](https://www.openpolicyagent.org/docs/latest/policy-language/) and Common Expre...## Status
- [X] Proposed
- [x] Trialing
- [x] Under review
- [x] Approved
- [ ] Retired
## Context & Scope
A language is required to write policies. [Rego](https://www.openpolicyagent.org/docs/latest/policy-language/) and Common Expression Language ([CEL](https://github.com/google/cel-spec)) have been mentioned within OSDU.
Policies are need for the system to enforce entitlement to data and to functionality.
## Decision
We will start with Rego as the first supported language. Documented [E&O use cases](https://community.opengroup.org/osdu/program/-/wikis/Release_Planning/R3/Information_Security/OSDU_Entitlements/Entitlements-Use-Cases) and some example policies to restrict access to functionality will be written in Rego and instrumented as testable requirements. Assuming other functional and nonfunctional requirements are met, this will become part of R3 scope.
## Rationale
Majority of stakeholders expressed desire to start an incubator with OPA as policy engine hence making evaluation of Rego the requirement for the incubator project.
## Consequences
- We might have a policy support in R3 sooner then if we proceeded with head-on comparison.
- We might end up using a less optimal technology just because this was the first choice.
## When to revisit
- Another requirement (e.g., extensibility, performance) is not unachievable using Rego.
## Alternatives and implications
Common Expression Language (CEL) is the alternative.
With Rego, we are deciding to go with more mature ecosystem that has less aggressive performance constraints and higher complexity. This may prove to be a wrong choice.
## Decision criteria and trade-offs
- Time to market
- Solution maturity
- Usability
- Extensibility
- Performance
- Solution complexity
## Decision timeline
July 2020M1 - Release 0.1Hrvoje Markovicjeyakumar DevarajuluHrvoje Markovic2020-11-23https://community.opengroup.org/osdu/platform/security-and-compliance/home/-/issues/26Policy Service and API2021-06-08T18:59:21ZHrvoje MarkovicPolicy Service and API## Status
- [x] Proposed
- [x] Trialing
- [x] Under review
- [x] Approved
- [ ] Retired
## Context & Scope
In OSDU, there is a need to manage policies. A dedicated services with corresponding set of APIs is required.
At the same time...## Status
- [x] Proposed
- [x] Trialing
- [x] Under review
- [x] Approved
- [ ] Retired
## Context & Scope
In OSDU, there is a need to manage policies. A dedicated services with corresponding set of APIs is required.
At the same time, some policy engines (e.g., [OPA](https://www.openpolicyagent.org/docs/latest/rest-api/)) already have REST APIs for policy management.
## Decision
In R3, OSDU ***policy*** service will be designed and implemented. This service might be only a simple wrapper of existing 3rd party REST APIs but no 3rd party APIs will become public interfaces in OSDU.
## Rationale
This will ensure a level of abstraction required to:
- Allow OSDU to evolve irrespective of selected technology;
- Allow policies to be contextual to OSDU.
## Consequences
Another service to maintain and support.
## When to revisit
- Once policies in OSDU have matured
- If there is a high cost to maintaining this service
- If there is no more added value from having the abstraction
## Alternatives and implications
We could just take OPA REST APIs and expose them as policy API. This would create a strong coupling to OPA, making it harder to contextualize the policy API (e.g., data partition support) and if required, switch to different policy engine in the future.
## Decision criteria and trade-offs
- Cost
- Usability
- Extensibility
## Decision timeline
July 2020M1 - Release 0.1Hrvoje MarkovicShankar VelappanHrvoje Markovic2020-11-23https://community.opengroup.org/osdu/platform/security-and-compliance/home/-/issues/25Entitlement Inheritance2020-09-22T03:40:17ZStephen Whitley (Invited Expert)Entitlement Inheritance## Status
- [X] Proposed
- [ ] Trialing
- [ ] Under review
- [ ] Approved
- [ ] Retired
## Context & Scope
The OSDU data platform supports data derivatives as part of enrichment steps. These derivatives can be created from multiple p...## Status
- [X] Proposed
- [ ] Trialing
- [ ] Under review
- [ ] Approved
- [ ] Retired
## Context & Scope
The OSDU data platform supports data derivatives as part of enrichment steps. These derivatives can be created from multiple parent sources; each with a different entitlement model.
``` mermaid
graph LR
P[Enrichment]
S1((Source 1))
S2((Source 2))
S3((Source 3))
style S1 fill:#f9f,stroke:#333,stroke-width:2px
style S2 fill:#9ff,stroke:#333,stroke-width:2px
style S3 fill:#ff9,stroke:#333,stroke-width:2px
R((Result))
S1 --> P
S2 --> P
S3 --> P
P --> R
```
The entitlement of the Result can be a function of the Entitlements of each of the sources, the enrichment that was performed and the organization that created it.
## Decision
For R3 we will explicitly define the entitlements for the Result instead of trying to compute it from its source(s) or traversal of its source(s).
## Rationale
This will ensure that entitlement and performance of evaluation is deterministic.
## Consequences
Derivative data from multiple sources will have to be tagged explicitly.
## When to revisit
After R3 when we have experience and better understand the implications on
- usability
- performance
- maintainability
# Trade-off Analysis - Input to decision
We could try to compute the entitlements based on lineage; however, there is no guarantee that the information required to do this properly would be both available and complete.
This places the burden on establishing access rights for derivative data on the producer of this derivative. This producer would then explicitly access to the new data to other interested parties.
## Alternatives and implications
- **Lineage traversal**: Looking at all ancestor data in real time to evaluate right of access. This would rely on having all the information required to calculate access rights correctly and would have performance implications.
- **Calculated Entitlement**: This would avoid the performance issues of the above; but would still require access to all the information required to assess access rights; including from the producer of the derivative.
## Decision criteria and trade-offs
- Correctness
- Determinism
- Usability
- Performance
## Decision timeline
July 2020M1 - Release 0.1Hrvoje MarkovicHrvoje Markovichttps://community.opengroup.org/osdu/platform/security-and-compliance/home/-/issues/20Don't preclude Endpoint Detection & Response2020-06-19T14:29:48ZPaco Hope (AWS)Don't preclude Endpoint Detection & ResponseWhere instances / VMs are deployed, do not preclude the use of operator-provided endpoint detection & response software installed on the nodes.
### Operator Inputs
- **Shell** lists this as a requirementWhere instances / VMs are deployed, do not preclude the use of operator-provided endpoint detection & response software installed on the nodes.
### Operator Inputs
- **Shell** lists this as a requirementM1 - Release 0.1https://community.opengroup.org/osdu/platform/security-and-compliance/home/-/issues/19Selectable External Content Encryption2020-06-19T14:07:41ZPaco Hope (AWS)Selectable External Content EncryptionSome sensitive content must be configured to be encrypted using an external encryption key source. Data that has the attribute **[TBD:ExternalEncryption]** must be encrypted prior to storage in the underlying cloud provider's storage sys...Some sensitive content must be configured to be encrypted using an external encryption key source. Data that has the attribute **[TBD:ExternalEncryption]** must be encrypted prior to storage in the underlying cloud provider's storage system. The encryption key for this encryption is pre-established by the operator. The external key providing system is reached via API call from the OSDU data platform service prior to encrypting/decrypting. This call can fail (because the operator has withdrawn consent to decrypt this data in the data platform), thus failures must be handled gracefully.
### Operator Input
- **ExxonMobil** lists this as a requirement to store sensitive data (e.g., annotations, commentary) in the OSDU data platform.
### Example: Export data
1. End user requests sensitive data to be exported
2. Data platform service retrieves encrypted data from cloud platform storage
3. Data platform service contacts external key provider to retrieve data key (that decrypts this data element)
4. Choice:
a. External key service replies negative: no key found / available. Data platform returns an error code.
b. External key service replies with a data key: Data platform decrypts the data and continues normally
### Example: Load data
1. End user requests sensitive data to be loaded. Manifest sets the **[TBD:ExternalEncryption]** in the manifest.
2. Data platform service contacts external key provider to retrieve **new** data key (that will encrypts this data element)
3. Choice:
a. External key service replies negative: no key available. Data platform returns an error code for this file.
b. External key service replies with a data key: Data platform encrypts the data with the provided data key and continues normallyhttps://community.opengroup.org/osdu/platform/security-and-compliance/home/-/issues/18Code Integrity, Access Control, Change Management2020-06-26T21:16:14ZPaco Hope (AWS)Code Integrity, Access Control, Change ManagementOperators want to know who has access/authority to commit code to the OSDU Data Platform. This doesn't need to be complex or long. But they need to know who can commit and how those permissions are handled. The process for accepting pull...Operators want to know who has access/authority to commit code to the OSDU Data Platform. This doesn't need to be complex or long. But they need to know who can commit and how those permissions are handled. The process for accepting pull requests/commits and making changes to the code should also be documented.
### Operator Inputs
- **Shell** lists this as a requirement.
### Definition of Done
Documentation and/or a link is probably sufficient. E.g., a link to the current list of approved committers, and a statement like "The OSDU OMC approves committers based on X, Y, Z". A statement about which workstream has authority over change management will satisfy that requirement, too.M1 - Release 0.1Raj KannanJoeRaj Kannanhttps://community.opengroup.org/osdu/platform/security-and-compliance/home/-/issues/17Network Security Requirements2020-09-22T03:40:20ZPaco Hope (AWS)Network Security RequirementsThe infrastructure that runs the OSDU Data platform must have limited outbound connectivity to the Internet.
How this is accomplished will vary by cloud provider. But it is important that individual containers, services, and hosts cann...The infrastructure that runs the OSDU Data platform must have limited outbound connectivity to the Internet.
How this is accomplished will vary by cloud provider. But it is important that individual containers, services, and hosts cannot make arbitrary connections to arbitrary outside IP addresses on arbitrary ports.
# Network security controls
## Egress
What network egress requirements are there for OSDU Data Platform services? E.g., if the data platform needs to/wants to connect to an outside data source, what network security requirements does the Operator impose?
Example controls include:
- Whitelisted domains and/or IP ranges.
- Proxying outbound HTTPS requests through an Operator-supplied proxy.
- For example, if the Load Service calls the Search Service, can that HTTPS API call pass through an HTTPS proxy.
- Egress to the Operator's on-premises network via a dedicated VPN channel
- Some operators want to block all outbound connection to internet IPs
## Ingress
Connections inbound are usually monitored.
- What level of logging / information is required for inbound connections?
## Transit
What network security controls are required inside the internal cloud network (e.g., between services)?
### Operator Input
- **Wintershall Dea**: And the Server(s) will have restrictions to access the Internet, at least it will be strictly controlled. HTTPS outbound only connections are possible. 2) The Deployment run in our on-premises Datacenter(s), here we have only Proxy-based Internet-Access for Servers. HTTPS outbound should be also no problem when it’s agreed.
- **ExxonMobil**: It is a requirement to have any outbound HTTPS pass through a proxy.
- **Shell**: WAF or L7 security inbound is required.https://community.opengroup.org/osdu/platform/security-and-compliance/home/-/issues/14Support SAML/OAuth for authentication2021-06-16T22:20:30ZPaco Hope (AWS)Support SAML/OAuth for authenticationSome operators do not support OpenID Connect and are not prepared to take on a significant app that uses it.
### Operator Inputs
Operators have expressed unwillingness or lack of support for OpenID Connect:
- **Total**: They do not su...Some operators do not support OpenID Connect and are not prepared to take on a significant app that uses it.
### Operator Inputs
Operators have expressed unwillingness or lack of support for OpenID Connect:
- **Total**: They do not support OpenID Connect at this time.
- **Petronas**: indicated that they prefer SAML but are willing to consider OpenID Connect
- **ConocoPhillips**: uses OAuth, not OpenID Connect
- **Repsol**: uses SAML now, but open to OpenID Connect in future
Operators have expressed support and acceptance of OpenID Connect:
- **ExxonMobil**
- **Chevron**
- **Shell**
- **BP**M1 - Release 0.1Ferris ArgyleDania Kodeih (Microsoft)Wladmir FrazaoJoeFerris Argylehttps://community.opengroup.org/osdu/platform/security-and-compliance/home/-/issues/13Static Code Analysis during CI/CD Pipeline2021-06-28T17:21:55ZPaco Hope (AWS)Static Code Analysis during CI/CD PipelineThis probably belongs in the [CI-CD pipelines](https://community.opengroup.org/osdu/platform/ci-cd-pipelines) board.
### Requirements
- Java code needs to pass through a static code analysis tool.
- Infrastructure code needs to pass th...This probably belongs in the [CI-CD pipelines](https://community.opengroup.org/osdu/platform/ci-cd-pipelines) board.
### Requirements
- Java code needs to pass through a static code analysis tool.
- Infrastructure code needs to pass through a static code analysis tool.
- Third party / open source code libraries that are used need to be scanned for vulnerabilities and for compatible open source licenses.
### Operator Input
* **Chevron** lists this as a requirement
* **Shell** lists this as a requirement
* **ExxonMobil** lists this as a requirement
* **BP** lists this as a requirement
### Definition of Done
- Code is scanned as a standard set of tests during the standard pipeline build
- Security tests failing can cause the build to failM1 - Release 0.1https://community.opengroup.org/osdu/platform/security-and-compliance/home/-/issues/12Kubernetes Security Requirements2020-06-24T20:30:44ZPaco Hope (AWS)Kubernetes Security Requirements### Input from Operators
These requirements provided by
- **Chevron**
- **Total**
- **Repsol**
- **Shell**
### Requirements
- K8s diagnostic settings must be enabled and forwarded to Log Analytics
- Azure AD should be enabled in Kuber...### Input from Operators
These requirements provided by
- **Chevron**
- **Total**
- **Repsol**
- **Shell**
### Requirements
- K8s diagnostic settings must be enabled and forwarded to Log Analytics
- Azure AD should be enabled in Kubernetes Service
- Cluster RBAC must be enabled in Kubernetes Service
- Do not directly or indirectly grant cluster admin level access to developers
- The latest version of Kubernetes should be used . Autoupdate daemon to be used
- Ensure containers listen only on allowed ports
- Do not allow privileged containers in AKS
- Container build file must be auditable/visible
- Allow Secrets Injection into containersM1 - Release 0.1https://community.opengroup.org/osdu/platform/security-and-compliance/home/-/issues/6OSDU API Logging Requirements2020-07-14T20:51:29ZPaco Hope (AWS)OSDU API Logging RequirementsFor all OSDU APIs, we need to log a number of attributes in a standard format.
Each log entry should contain:
* The principal from the `id_token`
* Whether the invocation was allowed/denied
* What resources were involved
* Any API hea...For all OSDU APIs, we need to log a number of attributes in a standard format.
Each log entry should contain:
* The principal from the `id_token`
* Whether the invocation was allowed/denied
* What resources were involved
* Any API header containing sensitive information such as authorization token should not be logged
* Unambiguous date and time. Preferably in [ISO-8601](https://www.iso.org/iso-8601-date-and-time-format.html) format
* Origin IP address for caller
* Other information as appropriate to the service being invoked
All OSDU APIs will generate API invocation logs in JSON format. The OSDU data platform will not filter any of the output that is logged. Operators can redact, delete, or retain logs as required.
### Operator Input
* **Chevron** wants JSON format and imported into Azure Log Analytics.
* **ConocoPhillips** wants [CIM (Common Information Model)](https://docs.splunk.com/Documentation/CIM/4.15.0/User/Overview) format to be supported.
* **Repsol**: any Syslog, CEF, GELF, etc. is suitable.
* **Equinor**: CEF and JSON formats are acceptable.M1 - Release 0.1Raj KannanJoeRaj Kannan