-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automatically add annotations to TLS secrets #933
Comments
Issues go stale after 90d of inactivity. |
Stale issues rot after 30d of inactivity. |
Closing in favour of #977 |
It appears that #977 does not solve this issue, but issues labels only instead, Am i wrong? |
@dioguerra I am also on it and found this: λ k explain certificate.spec.secretTemplate.annotations
KIND: Certificate
VERSION: cert-manager.io/v1
FIELD: annotations <map[string]string>
DESCRIPTION:
Annotations is a key value map to be copied to the target Kubernetes
Secret. |
Not sure if this link can solve the issue? |
I believe this is the right way to apply annotations to secrets generated by cert-manager: https://cert-manager.io/docs/reference/api-docs/#cert-manager.io/v1.CertificateSecretTemplate |
FEATURE REQUEST
WHAT
I would like cert-manager to automatically apply annotations from either a given list in values.yaml, or copy from annotations applied to the certificate resource itself.
WHY
I use [kubed|https://github.com/appscode/kubed] to propagate TLS secrets across namespaces and clusters. kubed uses the following annotation to accomplish this:
kubed.appscode.com/sync=""
but can also target specific labels.HOW
Right now I have cert-manager creating Let's Encrypt wildcard TLS certs in the kubed namespace, but I still must manually apply annotations to each TLS secret in order for those updated secrets to be propagated across the cluster. I have not yet had a renewal so I cannot say whether or not the annotations would need to be reapplied after each renewal.
I realize I could add a CronJob to automate the applying of these annotations, however, having this built-in would mean one less service to manage in every cluster.
/kind feature
The text was updated successfully, but these errors were encountered: