Turning TLS off on a converged engine does not withdraw the trust anchor that was published for it. The projection stays in the tenant namespace, and the tenant keeps reading a CA for a service that no longer serves TLS.
The CA-extraction contract (#3286, implemented in #3299) publishes <release>.tenant-ca while a release opts in — through the publish-ca-cert labels on a chart-authored Certificate, or through spec.caCert in the ResourceDefinition. The controller does withdraw the projection when the declaration disappears, and when a labelled source is definitively gone. What it does not see is the case where the chart simply stops rendering the TLS chain because the operator set the toggle to off: the source Secret is not deleted by that (cert-manager runs with enableCertificateOwnerRef: false, so removing a Certificate leaves its Secret behind), so from the controller's point of view nothing has been retracted.
The result is a stale anchor: still labelled, still tenant-visible, still describing a CA that is no longer in use. It is not a key leak — the projection is ca.crt-only by construction — but it is a correctness and hygiene problem, and it points a tenant at trust material for a connection that is now plaintext.
Today this is handled by documentation: the affected charts tell the operator which Secrets to delete by hand after disabling TLS. That is a reasonable stopgap and a poor contract.
Worth deciding as part of the contract rather than per engine, since every converged engine inherits it:
- Should disabling TLS actively retract the anchor — for instance by having the chart stop rendering the source and delete it, so the controller sees a definitive removal?
- Or should the projection carry an ownership relationship that makes it collectable when the chain goes away?
- Or is a documented manual step acceptable, in which case it should be stated once in the contract rather than repeated in each chart's README?
Raised while converging the per-app TLS series (#2814); it affects every engine in it, not the one where it happened to be noticed.
Turning TLS off on a converged engine does not withdraw the trust anchor that was published for it. The projection stays in the tenant namespace, and the tenant keeps reading a CA for a service that no longer serves TLS.
The CA-extraction contract (#3286, implemented in #3299) publishes
<release>.tenant-cawhile a release opts in — through thepublish-ca-certlabels on a chart-authored Certificate, or throughspec.caCertin the ResourceDefinition. The controller does withdraw the projection when the declaration disappears, and when a labelled source is definitively gone. What it does not see is the case where the chart simply stops rendering the TLS chain because the operator set the toggle to off: the source Secret is not deleted by that (cert-manager runs withenableCertificateOwnerRef: false, so removing aCertificateleaves its Secret behind), so from the controller's point of view nothing has been retracted.The result is a stale anchor: still labelled, still tenant-visible, still describing a CA that is no longer in use. It is not a key leak — the projection is
ca.crt-only by construction — but it is a correctness and hygiene problem, and it points a tenant at trust material for a connection that is now plaintext.Today this is handled by documentation: the affected charts tell the operator which Secrets to delete by hand after disabling TLS. That is a reasonable stopgap and a poor contract.
Worth deciding as part of the contract rather than per engine, since every converged engine inherits it:
Raised while converging the per-app TLS series (#2814); it affects every engine in it, not the one where it happened to be noticed.