Skip to content
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

Rukpak clients should be able to get CA cert without getting access to CA key #475

Open
joelanford opened this issue Aug 2, 2022 · 2 comments
Assignees
Labels
lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release.
Milestone

Comments

@joelanford
Copy link
Member

We use cert-manager to generate a rukpak-wide CA, and then use that CA to sign all of the certs for rukpak services. Clients of rukpak then need to read that CA to be able to verify connections to those rukpak services.

Currently, the situation is that clients read the rukpak-ca secret's data["ca.crt"] value to get the CA cert. However, that secret also contains the CA's key, which clients could use to sign more keys that would be trusted by anyone using the CA.

We need to ensure that the object read by clients contains only the CA cert. It seems like cert-manager does not support this out of the box (see cert-manager/cert-manager#2722 (comment)), so we may need to run our own controller that knows how to inject the CA into a separate configmap.

@timflannagan timflannagan added the priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. label Aug 2, 2022
@timflannagan timflannagan added this to the v0.9.0 milestone Aug 2, 2022
@awgreene
Copy link
Member

awgreene commented Aug 4, 2022

We discussed this in the upstream meeting and it seems like we'll be updating the RukPak operator to include a controller that injects the CA into a separate configMap based on the presence of an annotation.

@github-actions
Copy link

This issue has become stale because it has been open 60 days with no activity. The maintainers of this repo will remove this label during issue triage or it will be removed automatically after an update. Adding the lifecycle/frozen label will cause this issue to ignore lifecycle events.

@github-actions github-actions bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Oct 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants