-
Notifications
You must be signed in to change notification settings - Fork 23
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
Setting .Values.nameOverride makes the pod not have rights to update secret cert-manager-approver-policy-tls #207
Comments
There is something more happening than just the resourceName in the role, because even when I add both |
In playing around, I've just run into this issue, too. The issue appears to be here: approver-policy/pkg/internal/cmd/cmd.go Lines 63 to 72 in a953908
The application hard-codes the name of the I don't know which would be preferred here. |
Thanks for looking into this @jonathanio! This needs to be fixed! Which fix would you personally prefer? |
Setting Also, defining it based on the deployment name feels hidden and implicit. I think it should be a configuration option within the application, which can then be overridden, as needed, by the deployment if |
Thanks! I will bring this issue into our stand-up on Tuesday next week - to discuss the options here. We might also take a look at cert-manager? I would assume we should choose the same approach, at least if it makes sense. |
Yeah, agreed. Thank you for looking into this. |
I had a closer look at this, and I believe the solution is quite obvious. So I opened #534 to fix this. PTAL @jonathanio @smuda! |
https://github.com/cert-manager/approver-policy/releases/tag/v0.17.0 has just been released, containing a fix for this issue. 🎉 |
Description
When setting helm parameter
.Values.nameOverride
to anything else than it's default valuecert-manager-approver-policy
the approver fails to generate it's tls certificate during startup.The role allows access to one secret with a specific name which (when
.Values.nameOverride
is set to smuda) would be smuda-tls. However, inpkg/internal/webhook/tls/tls.go
the name of the secret seems hard coded tocert-manager-approver-policy-tls
.To reproduce:
Expected result
That the approver pod would startup and respond happily to the readiness-probe.
Result
The approver pod looks for and tries to update secret
cert-manager-approver-policy-tls
while the role allowssmuda-tls
. The pod is unhappy.The created role
smuda
:The text was updated successfully, but these errors were encountered: