Cert-manager: Default Issuer not working in 0.12

[jonkerj]

Describe the bug:
The default issuer (name, kind) is supplied to the ingress shim, but seemingly not picked up. I've (helm-)deployed cm using the following values:

ingressShim:
  defaultIssuerKind: ClusterIssuer
  defaultIssuerName: letsencrypt

My issuer:

$ kubectl get clusterissuers.cert-manager.io
NAME          READY   AGE
letsencrypt   True    64m

And this is (an excerpt) of my ingress:

kind: Ingress
apiVersion: extensions/v1beta1
[..]
spec:
  tls:
  - hosts:
    - echo.<redacted>
    secretName: echo-tls
  rules:
  - host: echo.<redacted>
    http:
[..]

The logs show this (and only this) when above ingress is deployed. Even when I wait half an hour:

I1203 15:20:14.810142       1 controller.go:129] cert-manager/controller/ingress-shim "level"=0 "msg"="syncing item" "key"="default/echo"
I1203 15:20:14.810293       1 sync.go:50] cert-manager/controller/ingress-shim "level"=0 "msg"="not syncing ingress resource as it does not contain a \"cert-manager.io/issuer\" or \"cert-manager.io/cluster-issuer\" annotation" "resource_kind"="Ingress" "resource_name"="echo" "resource_namespace"="default"
I1203 15:20:14.810327       1 controller.go:135] cert-manager/controller/ingress-shim "level"=0 "msg"="finished processing work item" "key"="default/echo"

Whenever the following annotation is added, a request, order and certificate are immediately created:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt

Expected behaviour:
I would expect the certificaterequest, order and certificate to appear using the defaultIssuer/defaultKind.

Steps to reproduce the bug:
Deploy the cert-manager 0.12 CRDs
Deploy a ClusterIssuer:

apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
  name: letsencrypt
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: <redacted>
    privateKeySecretRef:
      name: letsencrypt-privkey
    solvers:
    - http01:
        ingress:
          class: nginx

Deploy cert-manager using the jetstack/cert-manager chart, version v0.12.0, using the following values:

ingressShim:
  defaultIssuerName: letsencrypt
  defaultIssuerKind: ClusterIssuer

Deploy a pod/svc/ingress, with proper tls on the latter.

Anything else we need to know?:
I noticed Helm renders the related values properly into arguments for the controller:

$ kubectl describe pod -n cert-manager cert-manager-bbcbc9968-xh8bw
[..]
Containers:
  cert-manager:
    Container ID:  docker://5d6250cb8071f9c952f3cf44e2f465958c4a309973be9c74b024f840076dfc9b
    Image:         quay.io/jetstack/cert-manager-controller:v0.12.0
    Image ID:      docker-pullable://quay.io/jetstack/cert-manager-controller@sha256:eab95c0d67dfe5a0b0474e71a255e809965d2d000018a3f84df1d5ef27b12164
    Port:          9402/TCP
    Host Port:     0/TCP
    Args:
      --v=2
      --cluster-resource-namespace=$(POD_NAMESPACE)
      --leader-election-namespace=kube-system
      --default-issuer-name=letsencrypt
      --default-issuer-kind=ClusterIssuer
      --webhook-namespace=$(POD_NAMESPACE)
      --webhook-ca-secret=cert-manager-webhook-ca
      --webhook-serving-secret=cert-manager-webhook-tls
      --webhook-dns-names=cert-manager-webhook,cert-manager-webhook.cert-manager,cert-manager-webhook.cert-manager.svc

Environment details::

• Kubernetes version: v1.15.5
• Cloud-provider/provisioner: Kubespray/CoreOS/VMWare
• cert-manager version: v0.12.0
• Install method: Helm

/kind bug

[carlpett]

@jonkerj I stumbled on this too. From my understanding of
https://github.com/jetstack/cert-manager/blob/4073080089be8a7843cc83fc62139298b82588eb/pkg/controller/ingress-shim/sync.go#L49
and the logic in shouldSync, annotating with kubernetes.io/tls-acme: "true" is required. This will then use the default issuer.

@munnerz Wasn't it at some point possible to not have any annotations at all? I seem to recall having such a setup some years ago... :thinking: If not, wouldn't that be a good thing to allow? We never have a case where we don't want a certificate for an ingress, at least. Having a mode where certificate requests are opt-out via annotation would suit us.

[munnerz]

@munnerz Wasn't it at some point possible to not have any annotations at all?

Nope, this has never been the case. You've always had to include at least one annotation to trigger 'auto-management'!

I'm not sure why I added this to the milestones above, but I'm going to close this issue as I don't think automatically creating a Certificate for every Ingress by default is a widely requested feature, but if you disagree and think it'd be helpful please feel free to open an issue and mark it with /kind feature 😄