Repository navigation
Unify CA certificates and cover the OIDC provider - #442
Bohreromir wants to merge 2 commits into
Conversation
Replace the per-service CA settings for Trino, PostgreSQL and S3 with STACKABLE_COCKPIT_TLS_CA_CERTS (Helm: tls.caCerts, tls.secretClasses). The CAs are added to the process-wide default trust store, so every outgoing TLS connection, including the OIDC provider, trusts them while publicly trusted endpoints keep working. A missing or invalid certificate now stops the server at startup. Add /readyz, used by the Helm readiness probe: it fails until the OIDC discovery document has been fetched once, and the log names the cause, e.g. an untrusted provider certificate. Warn in production when Trino TLS verification is disabled. Closes #383
Coverage Report
File Coverage
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
labrenbe
left a comment
There was a problem hiding this comment.
Looks good in general, but I'm not so sure about the readiness gate. Maybe that should also be a separate PR?
| /** | ||
| * Fetches the discovery document. Returns true once it has succeeded: afterwards | ||
| * better-auth has (or retries) the provider metadata, so a later outage of the | ||
| * provider doesn't take the cockpit out of service for users with a session. |
There was a problem hiding this comment.
This is only true if the cockpit Pod doesn't restart. If the Pod restarts while the OIDC provider is not available it won't become ready and users can't continue their sessions. It might be ok to just error on misconfiguration.
There was a problem hiding this comment.
Yes, makes sense regarding the readyz. That probably deserves another more intense look so I removed it.
| | `tls.caCerts` | List of PEM files inside the container with CA certificates, e.g. mounted via `extraVolumes`. | `[]` | | ||
| | `tls.secretClasses` | List of Stackable SecretClasses that provide a CA certificate. The Secret Operator mounts each one's `ca.crt` into `/stackable/tls-ca/<secretClass>`. | `[]` | | ||
|
|
||
| The CA certificates from `tls.caCerts` and `tls.secretClasses` are trusted for all outgoing TLS connections (OIDC provider, Trino, PostgreSQL, S3), in addition to the CAs bundled with Node.js, so publicly trusted endpoints keep working. A missing or invalid certificate stops the application at startup. |
There was a problem hiding this comment.
Since there is a single truststore it means that there is no separation between CAs anymore, e.g. when the user adds a secret class used only for Trino it would be implicitly trusted to also provide the cert for the IdP. I think this might be ok but should be documented.
Replace the per-service CA settings for Trino, PostgreSQL and S3 with STACKABLE_COCKPIT_TLS_CA_CERTS (Helm: tls.caCerts, tls.secretClasses). The CAs are added to the process-wide default trust store, so every outgoing TLS connection, including the OIDC provider, trusts them while publicly trusted endpoints keep working.
Closes #383
Description
Docs
Release note
Checklist
Author
Reviewer
Acceptance