-
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
v1.12.X release Infinite loop with 2 certs with different keystore settings #6992
Comments
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. |
Thanks @SgtCoDFish for the info. I was looking purely on the website for changes around this but did not see it. 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
|
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! |
Thanks @SgtCoDFish for correcting / improving the documentation on this. If you absolutely want to avoid referencing the same 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:
|
Describe the bug:
Have two
Certificates
using the samespec.secretName
and have both outputtingspec.keystores
, but have one with just jks and the other with both jks and pkcs12.Once the second cert is issued, cert-manager logs will show it continually evaluating the secret. The annotation in the secret will also constantly be changed back and forth between the cert names as show:
Expected behaviour:
An error message on the second object identifying the secret as in use by the first Certificate resource. Such as this:
Steps to reproduce the bug:
New kind cluster with cert-manager
My values FYI:
Setup resource:
Create credential for keystores, This is just "changeme", so is safe to share. Don't use this anywhere.
Create first cert
See normal behaviour and cert created.
Now create a second cert that reuses the
secretName
field but also includes thespec.keystores.pkcs12.create
as trueWatch the cert-manager logs as it loops over the keystore being there or not there
Anything else we need to know?:
I will raise another issue, but assuming the
spec.keystores
is the same, the second cert, "my-app-4" in my case would just take control of the secret.The main issue here is the permanent log frenzy which will just obliterate the ability to effectively see anything else going on in cert-manager logs. This type of configuration is very easy for tenants to do and doesn't throw up any warning to them. The platform team will then have to deal with the fallout.
Upgrading to v1.14.4 does fix this error immediately. (v1.13.6 is also unaffected.)
We should maybe back port that functionality to v1.12 release as the LTS?
I think v1.12.10 and earlier to be affected by this.
Environment details::
/kind bug
The text was updated successfully, but these errors were encountered: