v1.12.X release Infinite loop with 2 certs with different keystore settings about cert-manager

[hawksight]

Thanks @SgtCoDFish for correcting / improving the documentation on this.
I spent some time today to figure out the Kyverno solution to this as well.

If you absolutely want to avoid referencing the same secretName from two Certificates here is an example ClusterPolicy that can do that. I have done some simple tests, but do your own testing to validate.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: limits
spec:
  validationFailureAction: Enforce
  rules:
  - name: limit-secretname-refs
    match:
      any:
      - resources:
          kinds:
          - Certificate
          operations:
          - CREATE
          - UPDATE
    context:
    - name: certCount
      apiCall:
        urlPath: "/apis/cert-manager.io/v1/namespaces/{{request.namespace}}/certificates"
        jmesPath: "items[].spec.secretName" 
    validate:
      message: "Only one Certificate is allowed to reference Secret: {{ request.object.spec.secretName }}"
      deny:
        conditions:
          any:
          - key: "{{ request.object.spec.secretName }}"
            operator: AnyIn
            value: "{{ certCount }}"

Example usaged:

> k apply -f ts-cert-1.yaml
certificate.cert-manager.io/ts-cert-1 created

> k apply -f ts-cert-2.yaml
Error from server: error when creating "ts-cert-2.yaml": admission webhook "validate.kyverno.svc-fail" denied the request:

resource Certificate/kyverno-secretname/ts-cert-2 was blocked due to the following policies

limits:
  limit-secretname-refs: 'Only one Certificate is allowed to reference Secret: another-secret-cert'

I will close this out as resolved on the assumptions:

• There will be no baked in solution to v1.12.X
• You can avoid conflicts in templating / usage
• There is another workaround above ^

[SgtCoDFish]

I think we documented this as a known issue for https://github.com/cert-manager/cert-manager/releases/tag/v1.12.6 and then it's not documented further - maybe we should add a note about this to all future 1.12.x versions.

If I remember correctly backporting was going to take a lot of effort because of architectural changes between 1.12 and 1.13.

[hawksight]

Thanks @SgtCoDFish for the info. I was looking purely on the website for changes around this but did not see it.
I can see it in GitHub as your linked.

But there is nothing about the issue on the releases page for v1.12 here: https://cert-manager.io/docs/releases/release-notes/release-notes-1.12#v1126

This raises another concern about what Long Term Support (LTS) means, but perhaps that's for an in person call / discussion. To take action here, a PR to the cert-manager website reffering to the bug would help others.

Strategies for avoiding spec.secretName collisions otuside of cert-manager?

1. Perhaps a Kyverno policy might have the option to introspect the environment?
2. Default the value based on the certificate name so you would end up copying over a cert instead, which might highlight the problem more quickly?

[SgtCoDFish]

I've raised cert-manager/website#1477 to rework these docs, because I agree they weren't super clear! I'm not really sure on what might be the best way to handle this outside of cert-manager - if it's possible to do a kyverno thing that sounds great but I don't have a lot of bandwidth atm!