-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Embedding cert-manager into CAPI for smaller footprint/less upgrade deps #7443
Comments
I think it's a fair ask to consider getting rid of cert-manager considering what we are using it for. Today we use cert-manager only for generation of the webhook certificates. This roughly works like this:
I think we could take a look if there are libraries nowadays we can embed which provide this functionality without having to deploy & manage cert-manager. Please see this discussion on Twitter: https://twitter.com/ahmetb/status/1549498418174644224?s=20&t=yuvVxSzP1reWQEzTfKNKEg P.S. Istio was doing something like this ca. 3-4 years ago. Not sure if they still do. I'm not a fan of trying to run cert-manager at the right times where it is needd. This is hard to get right and maintain in my opinion. It's also a problem if other components in the mgmt cluster depend on cert-manager. |
/triage accepted It will be interesting to have a security expert taking a look at this; what I would like to avoid is to support both the custom certificate generation process and the cert-manager way of doing stuff due to some corner case like e.g. bring your own certificate issuer or something else that will not be present in our custom solution |
/help |
@fabriziopandini: GuidelinesPlease ensure that the issue body includes answers to the following questions:
For more details on the requirements of such an issue, please see here and ensure that they are met. If this request no longer meets these requirements, the label can be removed In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
I for one like having all the certificate generation code centralized into a well known, well reviewed product like cert-manager. Having each and every project build or at least embed its own is rather scary. I'd say, at very minimum, please keep the option. |
I think we could still keep the option that folks can use cert manager. But I would like to get rid of the responsibility of us having to manage cert manager |
Strongly agree.
|
@kfox1111 While I see your point, let's remember that, by default, the KubeadmControlPlane controller creates all workload cluster certificates. |
Let's remember that external Cluster API providers (infrastructure, bootstrap, etc) also deploy webhooks. They also depend on cert-manager. If we replace cert-manager with a library, the library must provide certificates for external providers' webhooks. One library I know of is https://github.com/open-policy-agent/cert-controller. Design to create, and periodically rotate, certificates for one set of webhooks, a recent PR (open-policy-agent/cert-controller#52) may allow it to support multiple sets of webhooks. We would probably run this controller in the "core" manager. |
@jcmoraisjr as we discussed |
On ingress-nginx we use https://github.com/kubernetes/ingress-nginx/tree/main/images/kube-webhook-certgen which is a forked version of https://github.com/jet/kube-webhook-certgen I'm interested in getting this used more broadly, or having other projects to use the same logic. If this is a path (and turning this certgen not only a CLI but also a library to be consumed by "webhook cases") we should probably turn this project a k-sigs independent subproject. My only concern currently with this project is the "certificate expiration/rotation" that IIRC is not implemented today. |
As someone that has clusters that are ~5 years old, certificate expiration/rotation is starting to feel more and more important. :) |
The webhook certificates we use in CAPI today use the cert-manager defaults. 90 days validity and renewal after 60 days. |
/priority important-longterm |
I recently realized that the 3 cert-manager related processes we use in CAPI are actually not required when a cluster is running, and only required, i believe:
User Story
As a CAPI User I'd like to minimize the number of containers I need to run persistently in my cluster, and thus i'd like a like a default "batteries included" certificate management solution running in one my essential capi pods... so that i dont need to run certmanager after cluster creation.
i.e. the dumbed down version of this would be something like... "lets just vendor certmanager and use it when needed".
Detailed Description
I think these 3 services:
Can
Anything else you would like to add:
/kind feature
The text was updated successfully, but these errors were encountered: