-
Notifications
You must be signed in to change notification settings - Fork 74
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
[Feature] - Ability to inject a CA cert into a cert-manager managed secret resource #222
Comments
I like this idea, one could even go 1 step further in convenience and annotate an Issuer so that all Certificates by that issuer get their |
What exactly does Redis Operator use the ca.crt file for? For example, does a Redis node use ca.crt to verify the serving certificate of peers that it connects to? I'd just be very interested to know exactly how the users are attempting to use the ca.crt file, I've also asked for details of the OpenLDAP case. |
please also see cert-manager/cert-manager#1571 (comment) |
@wallrj i'm slighlyt surprised to see this pattern in the wild too. OpenSearch has the same requirement. My current assumption is that enterprise is pushing for mTLS. Alternativly perhaps people have been burned to often with outdated trust stores on os level, tool level (java, ...) etc.? |
Issues go stale after 90d of inactivity. |
/remove-lifecycle stale |
After reading through this cert-manager issue: cert-manager/cert-manager#1571 I had a temporary bright spark, although the actual solution might not be the one suggested here.
tl;dr
A single secret where cert-manager controlls
tls.crt
andtls.key
, butca.crt
is injected from trust-manager.Problems
tls.crt
,tls.key
andca.crt
seems to have become a standard for many tools mounting certificates in kubernetes.Goals / Themes
Solution(s)
The main idea that struck me was off the back of this comment, specifcially:
This seems a valid solution, could you manually insert the
ca.crt
into the secret itself. But why do this manually, trust-manager is about automating trust distribution. So what if trust-manager had a watch / trigger forSecrets
that required a certainBundle
output to be inserted.Just an idea but what about:
Annotations are terrible? and there is probably a better way. But with
ManagedFields
it's now possible to safely have multiple controllers manage a resource (or so I believe). This could potentially be added in stages to the two controllers. For example if trust-manager was to watch secrets with valid annotations, then these annotations could be added usingcertificate.spec.secretTemplate.annotations
.. eg..Basically no new cert-manager certificate CRD fields to link to bundle.. but perhaps in the future:
Assuming it was as above, you could potentially avoid annotations and have cert-manager ask trust-manager for the bundle ca at issuance time. Or alternatively, just mark the
Secret
fieldca.crt
in some fashion for trust-manager to do the injection.Other solutions
Concerns
Secrets
, but then again, a workload certificatetls.crt
arguably doesn't need to be secret either, only the key.ca.crt
changes from the bundle being propagated, would you want cert-manager to reissue the actual cert as well? I think this is combated with good practice.Other
I haven't fully thought this out, just wanted to get a brain dump out and collaboratively find the best solution. Also see if this is a good idea, so please vote / comment with input.
The text was updated successfully, but these errors were encountered: