-
Notifications
You must be signed in to change notification settings - Fork 9.1k
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
global ca-bundle #19744
Comments
I created an initContainer which could be used as an example implementation, it would need to be altered for application / image specific requirements, but shows how it could pretty easily be implemented: This is using a PVC as a work around, but if the solution was provided by the helm chart it could be much much more simply implemented with a postStart or similar technique (no pvc needed). This example also shows just how hard it is to create a work around when a helm chart lacks the needed template integrations. |
Hi @lknite, Thanks a lot for all the details. The proposal is very interesting but there is a thing I don't fully understand. You mentioned that the solution could be simpler with a I'll open an internal task to analyse it. Please keep in mind that we are a small team that this task could require a lot of work so we can not provide any ETA. PRs are welcome and the Bitnami Team will be happy to review it. |
This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback. |
Name and Version
all
What is the problem this feature will solve?
In enterprise environments onprem certificates are necessary to perform man in the middle inspection.
These onprem certificates need to be added to each pod which needs to access a url.
As a workaround this can be accomplished with a configmap or secret which maps to /etc/ssl/certs/ca-certificates.crt . However there are complications, some base images with different os's requires the certs in a different location. Python wants certs in a different location, java based apps require 'keytool' to be used to generate certs in a particular format. Also, sometimes you need more than just the onprem certs, you need all the original certs plus the onprem certs, so you don't want to wipe them out, and sometimes trying to put all the existing certs + the onprem certs is too big for a configmap or secret.
A solution would be to standardize how to provide a ca-bundle to be implemented by an application in the values.yaml.
Implementation in general would result in an image-specific technique to add the specified onprem ca-bundle by splitting the multiple scripts up into individual .crt files, placing them into /user/local/share/ca-certificates and then importing them by running update-ca-certificates or update-ca-trust, whatever the os requires.
Splitting the file is as easy as running:
awk 'BEGIN {c=0;} /BEGIN CERT/{c++} { print > "cert." c ".pem"}' < ca-bundle.pem
The keycloak helm chart has a way of specifying a ca-bundle which is automatically imported, we just need to standardize where the ca-bundle is specified rather than have it in a different place unique in each chart. And also, pretty much every chart needs to implement this ability to have onprem certs imported.
What is the feature you are proposing to solve the problem?
What alternatives have you considered?
I've considered writing a controller to implement this functionality and looked for a k8s based solution. If implemented ClusterTrustBundles, a possible future feature of k8s, may help to add in ca-bundles.
Alternatively, if 'postStart' was added to all the deployments then a work around could be implemented as needed. However, since the technique needed can be different in different apps / images it'd be nice to not have to try and figure out what to do every time.
The text was updated successfully, but these errors were encountered: