feat(controller,api): adds a cabundle option to the values.yaml file. #2382
Conversation
If enabled, it adds an initContainer to the controller deployment which mounts certs provided via either a configMap or secret. Uses an emptyDir, or optionally a pvc, for the actual certs mount within the controller; this allows the controller to write to the certs folder if needed. Signed-off-by: Leland Knight <[email protected]>
✅ Deploy Preview for docs-kargo-akuity-io ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
lknite
changed the title
|
What is the point of the init container and the volumes here? I'm not clear about what would be insufficient about just mounting a user-provided secret into the container that contains the trust store. |
|
Following up on my previous comment: The original issue was #2271 and it seemed to be about CA for the OIDC IDP, so in the back of my mind, that was the context/scope. That issue can be solved by adding more CA certs directly to the http client that the Kargo API server uses to communicate with the IDP and that doesn't require anything more than those certs to be mounted somewhere where the API server will look for them. e.g. Secrets do the trick. No init container needed. Very small code change needed. This PR seems to address the issue of custom CA certs more-broadly, at the system level, which is nice, but also seems to do it for the controller and not the API server, meaning it doesn't solve the original issue. Perhaps what is required here is some clarification on the scope of what you are trying to solve for. |
lknite
changed the title
|
If we liked this approach I was going to submit a pr for the api also doing the same thing, maybe for all the services. I started with the controller because the controller also wants to write to the /etc/ssl/certs folder and (unless i'm mistaken) just mounting a secret will make the path read-only, so we at the least for the controller need to use an 'emptyDir' instead. The initContainer approach is nice because it can take a ca-bundle with multiple certs and split them up into individual certs and add each one. This is a little easier on the SRE because in general update-ca-trust and update-ca-certificates expects a single cert per file, though its common to have many in one, e.g. trustmanager , such as the root ca & int cert in one file. ... the initContainer would only be added if someone specifically enabled the ca-bundle option |
|
@lknite, ok I get where you were going. It was the scope / area where you implemented the change that confused me a bit. With greater clarity on that now, I will take another look. |
- added to 'or' before the 'volumes' section to ensure cabundle related volumes are added Signed-off-by: Leland Knight <[email protected]>
Signed-off-by: Leland Knight <[email protected]>
lknite
changed the title
lknite
changed the title
|
added to kargo-api as well will now resolve issue #2271 |
…t.yaml to ensure cabundle is mounted if enabled Signed-off-by: Leland Knight <[email protected]>
Merge branch 'feature-add-ca-bundle-to-controller' of https://github.com/lknite/kargo into feature-add-ca-bundle-to-controller
If enabled, it adds an initContainer to the controller deployment which mounts certs provided via either a configMap or secret. Uses an emptyDir, or optionally a pvc, for the actual certs mount within the controller; this allows the controller to write to the certs folder if needed. Signed-off-by: Leland Knight <[email protected]>
…com/lknite/kargo into feature-add-ca-bundle-to-controller
|
tried to update my fork, might have messed up things will redo with a new pull request |
If enabled, it adds an initContainer to the api/controller deployment which mounts certs provided via either a configMap or secret.
Uses an emptyDir, or optionally a pvc, for the actual certs mount within the controller; this allows the controller to write to the certs folder if needed.