You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, there is a manual step involved when rotating certificates, of copying the certs. I think this is a feature gap, especially given that the sister project, cert-manager, does rotation automatically, and so there's not much more that needs to be done to implement completely automatic certificate management in a Kubernetes cluster.
What I'm thinking is allowing users to configure something like this in their Bundle configuration:
When trust-manager sees keepCertHistory: true, it will copy the cert itself into either a list of certs in the status of the Bundle CRD, or into a new CRD that exists for the purpose of storing historical certs. And any time it notices that the cert has changed, it will copy the new cert into the list (or create a new instance of the historical cert CRD), keeping the old cert around. The trust bundle will then contain both the current cert, and all previous certs that the operator has seen. The operator can clean old certs up, primarily this would be done based on the expiry date in the cert itself, but to prevent resource leaks (eg, in the case of misconfiguration of rotation), certHistoryLimit will specify the maximum number of old certs to keep, with certs being removed in an oldest first fashion if that number is ever reached. This should have a sensible non infinite default.
So, this will automate the copy step described in the docs, and provide a completely automated means for root CA rotation using cert-manager and trust-manager together.
The text was updated successfully, but these errors were encountered:
Right now, there is a manual step involved when rotating certificates, of copying the certs. I think this is a feature gap, especially given that the sister project, cert-manager, does rotation automatically, and so there's not much more that needs to be done to implement completely automatic certificate management in a Kubernetes cluster.
What I'm thinking is allowing users to configure something like this in their
Bundle
configuration:When trust-manager sees
keepCertHistory: true
, it will copy the cert itself into either a list of certs in the status of theBundle
CRD, or into a new CRD that exists for the purpose of storing historical certs. And any time it notices that the cert has changed, it will copy the new cert into the list (or create a new instance of the historical cert CRD), keeping the old cert around. The trust bundle will then contain both the current cert, and all previous certs that the operator has seen. The operator can clean old certs up, primarily this would be done based on the expiry date in the cert itself, but to prevent resource leaks (eg, in the case of misconfiguration of rotation),certHistoryLimit
will specify the maximum number of old certs to keep, with certs being removed in an oldest first fashion if that number is ever reached. This should have a sensible non infinite default.So, this will automate the copy step described in the docs, and provide a completely automated means for root CA rotation using cert-manager and trust-manager together.
The text was updated successfully, but these errors were encountered: