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.
- 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.