self-generated secret non-compliant

[raffaelespazzoli]

by convention, secret containing certificates in kubernetes should be of type "kubernetes.io/tls"
also the entries should be:

• tls.key
• tls.crt
• ca.crt
  compliance helps interoperability with other certificate generation systems, such as for example cert-manager

[maxsmythe]

Self-generated certs are goverened by the Kubebuilder code. Here is the source for the most recent release:

https://github.com/kubernetes-sigs/controller-runtime/blob/12d98582e72927b6cd0123e2b4e819f9341ce62c/pkg/webhook/internal/cert/writer/secret.go#L150

Getting this bug addressed in that central library should go a lot farther in addressing the cross-compatibility issues generally. Please link any filed bugs back to this one and we'll upgrade our libraries to include published fixes as we are able.

In the interim, is it possible to have cert-management projects create the cert prior to start up? As long as the cert remains valid the self-management shouldn't overwrite it.

Another feature request you may want against the controller-runtime library is to disable the automatic overwriting of expired/incompatible certs, as that could interfere with the functioning of external cert generation systems.

[ritazh]

You can also use the enable-manual-deploy flag to deploy the secret, service, webhook config manually instead of having kubebuilder do it. https://github.com/open-policy-agent/gatekeeper/blob/master/pkg/webhook/policy.go#L46

[raffaelespazzoli]

@maxsmythe I opened an issue in that project: kubernetes-sigs/controller-runtime#430
@ritazh that's exactly where the issue lies, if I do that what do I use then to automatically generate secrets? The keys expected by the code are the standard keys that other certificate operators generate

[maxsmythe]

@raffaelespazzoli thanks!

one thing about enable-manual-deploy is that it disables automatic generation of the webhook config, it does not disable automatic generation of the secrets themselves.

To have that feature, controller-runtime would need to implement the feature mentioned above:

Another feature request you may want against the controller-runtime library is to disable the automatic overwriting of expired/incompatible certs, as that could interfere with the functioning of external cert generation systems.

[ritazh]

@maxsmythe Today we are using the DisableWebhookConfigInstaller flag which

controls if the server will automatically create webhook related objects during bootstrapping. e.g. webhookConfiguration, service and secret.

https://github.com/kubernetes-sigs/controller-runtime/blob/5fd1e9e9fac5261e9ad9d47c375afc014fc31d21/pkg/webhook/server.go#L57-L60

But looks like this flag and the ability to generate your own webhook related objects were dropped in this commit: kubernetes-sigs/controller-runtime@81b48be#diff-fbc18bb07cdd05391b7081acc1dfe170

[maxsmythe]

@ritazh DisableWebhookConfigInstaller is half the battle here. The other issue is the cert which the server uses to sign its responses, which is currently unaffected.

ValidatingWebhookConfiguration configures the API server and which public/authority certs it expects. The server itself either mounts a secret or maintains one on local disk and will rotate as needed. This locally mounted cert is the one used to sign responses. If the two configurations don't agree, then the mTLS handshake will fail.

Currently, I know of no levers to control secret generation other than making sure a pre-existing valid secret is installed.

re: removal of DisableWebhookConfigInstaller. From what I can tell there is a major refactoring going on related to how the server is generated. I haven't seen any documentation, so I can't say for sure whether that option has been removed completely or just relocated.

[maxsmythe]

I think this has been fixed with the migration to Kubebuilder V2. Re-open if not.