global ca-bundle

[lknite]

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?

global:
  imageRegistry: ""
  imagePullSecrets: []
  storageClass: ""
  # specify by providing the name of a secret and use all data as .crt files
  ca-bundle-secret: ca-bundle
  # or specify directly
  ca-bundle: |
    -----BEGIN CERTIFICATE-----
    MIIFrDCCBJSgAwIBAgIQCfluwpVVXyR0nq8eXc7UnTANBgkqhkiG9w0BAQwFADBh
    MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    MIIFrDCCBJSgAwIBAgIQCfluwpVVXyR0nq8eXc7UnTANBgkqhkiG9w0BAQwFADBh
    MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
    -----END CERTIFICATE-----

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.

[lknite]

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:
argoproj/argo-cd#7572 (comment)

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.

[fmulero]

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 postStart but I don't see how it can be possible, as you mentioned, each app has its own way to set trusted certificates and the postStart hook could be "too late" to do it.

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.

[github-actions]

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.