Operator-controlled TLS Options
As an operator, I can provide the public key certificate and corresponding private key for all TLS endpoints that handle my data. This covers externally-facing API endpoints. Anything that is deployed as part of deploying the OSDU data platform (not the cloud provider's own endpoints).
- Issuing the TLS certificate for the API endpoints from a CA / PKI that the operator controls.
- This must be importable into OSDU
- This must be renewable when it expires
- The TLS cipher policy must be controlled to restrict connections to operator-approved TLS ciphers.
Operator Inputs
- Chevron: This is mandatory for Chevron.
- Repsol: This is mandatory for Repsol.
- Equinor: We do have an internal PKI so we need to be able to configure trust between internal resources and the OSDU install. (Paco comment: this might require BYOK for certificates, it might not)
Definition of Done
-
An operator can provide one or more TLS certificates and they will be deployed to the externally-facing endpoints.
-
An operator can indicate which valid TLS ciphers are acceptable/supported for their OSDU endpoints. (e.g., TLS 1.2 only)
-
When connecting to the API endpoints, the operator's provided TLS certificate is presented in the TLS handshake.
-
When connecting to the API endpoints, TLS connections are rejected unless the client selects an acceptable cipher.
-
The requirements for an operator-provided X.509 certificate (e.g., signature, key size, etc) is documented so that operators can supply compatible certificates. Linking to the appopriate cloud provider's documentation will be necessary, but not sufficient.
-
The requirements for an operator-provided TLS cipher list is documented so operators can select their cipher suites. Linking to the appropriate cloud provider's documentation for mechanisms will be necessary, but not sufficient.