Cert-manager: Allowing customising Certificate's Secret resource

[prune998]

Is your feature request related to a problem? Please describe.
As Cert-Manager can only create TLS secrets (one secret with a key and a crt file in it), we can't group them to take actions like selecting a bunch of them for deletion.

This is especially worse when using a single Ingress Gateway in a Namespace, so all the certs have to be in the same namespace (ex : Istio Ingress Gateway in the istio-system namespace)

Describe the solution you'd like
I would like to be able to add some Labels to the secret created by a Certificate definition, something like :

apiVersion: certmanager.k8s.io/v1alpha1
kind: Certificate
metadata:
  name: acme-crt
spec:
  secretName: acme-crt-secret
  secretLabels:                                           <--------------------------------------
    env: "production"
    customer: "coca-cola"                         ----------------------------------------
  dnsNames:
  - foo.example.com
  - bar.example.com
  acme:
    config:
    - ingressClass: nginx
      domains:
      - foo.example.com
      - bar.example.com
  issuerRef:
    name: letsencrypt-prod
    # We can reference ClusterIssuers by changing the kind here.
    # The default value is Issuer (i.e. a locally namespaced Issuer)
    kind: Issuer

This way, I will be able to kubectl get secrets -l env=production to list all the prod certificates

Environment details (if applicable):

• Kubernetes version (e.g. v1.10.2): 1.10.x
• Cloud-provider/provisioner (e.g. GKE, kops AWS, etc): GKE
• cert-manager version (e.g. v0.4.0): v0.4+

/kind feature

I can try to build a PR if this request sounds legit to the maintainers.
Thanks.

[prune998]

I made a PR for this : https://github.com/jetstack/cert-manager/pull/1027

[retest-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to jetstack.
/lifecycle stale

[munnerz]

There is also a similar request, but for annotations in #933

To me, this shows that the solution we choose needs to encompass the need to set extra fields beyond just annotations/labels, so a secretTemplate or similar would be needed.

Long term plans for cert-manager will involve us looking at ways we can 'deliver' certificates in different ways, as described in your PR before. I think because of this, and given our ultimate drive towards 1.0 within the next few months, we'd like to hold off on implementing this for now.

I definitely want to support this use case in future, but at this point this change could make implementing larger goals more difficult, and it is something that we can solve in a wider, more applicable to more people, way 😄

/remove-lifecycle stale
/priority backlog
/kind design
/remove-kind feature

[tlvenn]

To me, this shows that the solution we choose needs to encompass the need to set extra fields beyond just annotations/labels, so a secretTemplate or similar would be needed.

Question for you @munnerz , how does @prune998 request illustrate in any way the need to go beyond labels / annotations and make you think that some kind of templating is needed ?

I am kinda confused by your statement because if anything, all i am seeing across the different issues related to customising the generated secret is always about labels or annotations.

[raffaelespazzoli]

I also would like to see this feature implemented. In particular I'd like to have a way to pass annotations to the created certificate.
Maybe a simple way would be to just let the generated Secret to have the annotations and labels that exists for the Certificate CR (plus any needed by cert-manager).

[jamessthompson]

Simple support for labels and annotations would also solve my use cases.

[nitishm]

@tlvenn @jamessthompson I second that. Just an annotation/label feature would be sufficient for my use case as well.

[mmckane]

Would one of the possible options allow you to specify Namespace the secret is created in. Also trying to manage an istio use case where currently the secrets need to live next to the ingress gateway which is usually in another namespace from where I want the certificate CRD to exist.

[retest-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to jetstack.
/lifecycle stale

[raffaelespazzoli]

this issue is still important to me and I hope it will not be archived.

[retest-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to jetstack.
/lifecycle rotten
/remove-lifecycle stale

[prune998]

/remove-lifecycle rotten

[prune998]

/remove-lifecycle stale

[JoshVanL]

We would recommend that you first create the target secret with the desired annotation/labels
/close

[jetstack-bot]

@JoshVanL: Closing this issue.

In response to this:

We would recommend that you first create the target secret with the desired annotation/labels
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[tlvenn]

But that does not work @JoshVanL, the entire secret is being overwritten when the certificate is issued.

[McShauno]

This should be implemented. Currently, certmanager has restrictions in place that disallows a standard mechanism for identifying ALL objects within Kubernetes -- labels.

[mdgreenwald]

Supporting annotations and labels would be very helpful to me right now. My use-case is also synchronizing secrets across namespaces using Kubed.

metadata:
  ...
  annotations:
    kubed.appscode.com/sync: ""

[jurgenweber]

@mdgreenwald did you find a solution for adding the annotation?

[tlvenn]

I have the same usecase as @mdgreenwald and sadly there is no clean solution that does not involve annotating the certificate once it is created which is impossible to do outside of the box with a declarative approach such as Terraform.

@JoshVanL did you see my comment regarding your suggestion ? It simply does not work, please reopen this issue that is very much still standing. Thanks.

[dewet22]

@JoshVanL could you take another look at this please? Having just moved to flux myself, being unable to declaratively add annotations is completely breaking my secrets propagation. I don't think this issue can be legitimately closed until that is the case.

[winromulus]

@mdgreenwald @jurgenweber @tlvenn
Mentioning you guys because reflector ( https://github.com/emberstack/kubernetes-reflector ) has built-in support for this (annotating cert-manager secrets for propagation across namespaces) until this annotation is implemented in cert-manager.
That's if you haven't already found a solution to this.

[dbpolito]

Would love to see this too, currently not possible to integrate with kubed.