-
Notifications
You must be signed in to change notification settings - Fork 110
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
Allowing CACertificateRef
to be loaded from a secret
#2629
Comments
Thanks for reporting this @asger-noer! We initially only implementing ConfigMap support as that is the only object that is specifically listed as "core" support under the Gateway API, but as you say, there's no explicit reason why it should be limited to ConfigMaps only. We should be able to look at this in the future, and I'll update this issue as it goes through the process. Otherwise, we are open to PRs on this issue in the meantime! |
Hi, I'd like to add a 👍 for this. We'd like to use NGF as a reverse proxy to an Elasticsearch cluster. ES nodes use TLS for intra-node communication, so the reverse proxy must trust the self-signed root cert. ECK operator creates a Secret with public certs, which is a JSON document, and the root cert is under |
I would like to +1 this as well. Since cert-manager creates certificates as secrets |
I’ve started this #2976, very nifty how this stuff is setup. Now getting into the bit of actually adding the ca bundle to the configuration. |
Is your enhancement request related to a problem? Please describe.
When running CockroachDB in secure mode with Cert-Manager acting as CA. This will produce a CA in a secret instead of in the currently supported ConfigMap. I don't see anything in the API that would prevent the certificate ref being a secret.
What would you like to be added:
The option to provide a secret ref in the
spec.validation. caCertificateRefs[*].kind
Why this is needed:
For supporting different ways of storing CAs.
Additional context
This is the status of the create
BackendTLSPolicy
when created referencing a Secret instead of a ConfigMapVersions
The text was updated successfully, but these errors were encountered: