Allow running conversion webhooks/mutating webhooks/validation webhooks without cert-manager

[jonathan-innis]

Right now, if you want to run a webhook attached to a CRD that you are using with controller-runtime and controller-gen, you have to run cert-manager alongside it. This requires users that are using your component to have to install a separate component alongside yours.

We (kubernetes-sigs/karpenter) worked around this problem for a bit by using knative's webhook reconciler to avoid the cert-manager dependency. This worked well, but caused other problems due to the dependency closure that knative takes. Ideally, we could implement some kind of self-signed certificate reconciliation mechanism in controller-runtime to reduce this dependency chain.

[jonathan-innis]

/kind feature

[vincepri]

This is only true for kubebuilder, but in general you don't need certmanager in controller runtime. As long as you have certificates exposed, you should be good.

[jonathan-innis]

As long as you have certificates exposed

I think the issue is in generating a self-signed cert -- is there a path for generating and self-renewing a self signed certificate with controller-runtime?

[damsien]

For now, there is no way to do that. I think that it will not be implemented since the controller-runtime project only provide a tool for building controllers. If you want to have a self-renewal mechanism, then you should create your own or use cert-manager.

I already asked a native implementation of a certificate self-renewal mechanism without using cert-manager in the Kubebuilder slack channel. And the answer was that most of the companies already use cert-manager, so why should we use another mechanism

[alvaroaleman]

I think the issue is in generating a self-signed cert -- is there a path for generating and self-renewing a self signed certificate with controller-runtime?

That is not enough, you also need to put the correct CA into the webhook config. Generating a cert in go is IMHO pretty straight forward, there is even an example in the stdlib so I don't really see the point in adding something for that to controller-runtime. What is more tricky is the distribution of the CA to the webhook config objects, but controller-runtime doesn't know anything about them so you'd have to configure it to do - At that point, you might as well just add the ca there yourself.

[jonathan-innis]

doesn't know anything about them so you'd have to configure it to do - At that point, you might as well just add the ca there yourself

I think this was exactly my point. That there is no mechanism to inject the CA into the webhooks for self-signed certificates but other projects do seem to support this kind of reconciliation mechanism.

Adding cert-manager certainly isn't free -- it's one more thing to manage for people installing your project and it also generally makes it extremely cumbersome to add webhooks to your CRDs (there is an argument that it's intentionally painful so that it pushes folks away from using webhooks entirely -- which I get -- but for those of us who are unfortunate enough to have to use them, it would be nice to make it as easy as possible)

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[jonathan-innis]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[jonathan-innis]

/remove-lifecycle stale