Reconsider error condition on empty secretnames in TLS hosts.

[jacobstr]

Is your feature request related to a problem? Please describe.

Note: occurred to me after writing all of this that the underlying ask is to have some way to ignore a subset of hostnames in the TLS spec when the certificate-shim does it's thing.

In our cluster, we provide wildcard certificates via ingress-nginx's default certificate functionality. The documentation states:

The default certificate will also be used for ingress tls: sections that do not have a secretName option.

There appears to be some disagreement between nginx's interpretation of the Ingress spec and cert-manager here. One of our goals is to use the certificate shim to manage only a subset of the TLS hostnames - ideally, only those that have a secretName specified.

E.g. our hosts section typically looks like:

    tls:
    # These first two hosts will be handled by a wildcard cert for *.ingress.prod.k8s.example.com
    - hosts:
      - example.next.ingress.erb-01.staging.k8s.example.com
    - hosts:
      - erb-example.staging.example.com
      secretName: example-tls

This kinda/sorta works today - cert manager ignores the the TLS blocks with empty secretnames but does produce error logs / events. It doesn't inspire complete confidence that this behavior will be supported in the future and that this only works incidentally rather than being an explicit choice.

Describe the solution you'd like

• Simply ignore TLS blocks with empty secret names instead of considering this an error condition.

Describe alternatives you've considered

If we do specify the secretName (e.g. cluster-wildcard-tls) like so:

    - hosts:
      - example.next.ingress.erb-01.staging.k8s.example.com # should present a *.erb-01.staging.k8s.example.com cert
      secretName: cluster-wildcard-tls

Cert-manager will try to create this certificate with the non-wildcard DNS name. To get around this in the past, we typically pre-provisioned the namespace with an explicit cluster-wildcard-tls certificate resource specifying our wildcard record before any ingresses were created. This had proven problematic - if, for whatever reason (e.g. a newly created namespace is created) this certificate doesn't exist and a new ingress appears cert manager will create it and "squat" on it with the wrong configuration.

---

Additionally, we tried omitting the tls block for the DNS name we want to map to the wildcard record entirely. In this case ingress-nginx simply omits TLS for the hostname entirely. Arguably, this is an issue with ingress-nginx.

Additional context

The wildcard hostnames are typically used to help service owners hit the ground running with a working hostname ASAP. Once a service is ready for prime time, folks typically create "vanity" DNS names that provide some additional indirection (e.g. we ellide the cluster name from this record).

• Alternative would be having some way of opting-in to certificates for specific tls blocks. Appears an annotation could work, but whatever I come up with feels unergonomic.

cert-manager.io/ignored-secretNames: cluster-wildcard-tls,other-secrets
or
cert-manager.io/ignored-tls-hosts: example.next.ingress.erb-01.staging.k8s.example.com

Environment details (remove if not applicable):

• Kubernetes version: 1.18
• Cloud-provider/provisioner: gke
• cert-manager version: 1.3.1
• Install method: e.g. helm/static manifests static manifests

/kind feature

[jetstack-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

[jetstack-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

[jetstack-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to jetstack.
/close

[jetstack-bot]

@jetstack-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to jetstack.
/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.