security: user-provided TLS Secrets are not cryptographically or semantically validated

[dcmcand]

Summary

When a NebariApp supplies its own TLS Secret, the operator checks only that the Secret exists, is of type kubernetes.io/tls, and has non-empty tls.crt and tls.key. It does not parse the certificate or key, confirm they match, check validity dates, or confirm the certificate covers the requested hostname. The Gateway listener is attached before this best-effort check runs.

Affected code

• internal/controller/reconcilers/tls/reconciler.go - checkUserProvidedSecret (L559-598) performs three checks: existence (L561-575), Type == kubernetes.io/tls (L577), and non-empty cert/key bytes (L588), then returns ready (L595). There is no x509/tls parsing, key-to-cert match, validity check, or SAN/hostname comparison. The function comment (L554-558) states it is best-effort and does not block listener attachment, and the listener is attached earlier at L184 (check runs at L208).

Impact

A malformed, mismatched, expired, or wrong-hostname certificate passes the check as long as the byte fields are non-empty, which can produce TLS listener failures, serving a certificate for the wrong hostname, and a misleading TLSReady status.

Remediation

• Parse the PEM blocks and X.509 certificate, and prove the private key matches the public key.
• Check validity dates and hostname (SAN) coverage against the requested hostname.
• Attach the listener only after successful validation.
• Prefer administrator-owned certificate allocations over raw Secret names.

Acceptance criteria

• A Secret whose certificate is malformed, mismatched, expired, or does not cover the hostname does not report TLSReady=True and does not result in an attached listener.

References

• CWE-295 (Improper Certificate Validation)
• Related: Watch user-provided TLS secrets to fast-track TLSReady transitions #115 (watch user-provided TLS secrets)

Line numbers reference commit 4ad2c10.