Implement deployment with client certificate

[sgaist]

What this PR does / why we need it:

Implement client certificate creation using cert-manager as part of the deployment process.

Doing so, one can directly have a usable certificate to connect to the webhook. The certificate, key and ca can be retrieved to be put in the webhook configuration using kubectl.

Which issue(s) this PR fixes:
Fixes #129

Special notes for your reviewer:

Release note:

Webhook operator can now automatically create a client certificate upon installation using the new `global.certManager.generateClientCertificate` attribute. The duration of the certificate can be controlled using `global.certManager.clientCertificateDuration` which defaults to 90 days.

[gardener-robot]

@sgaist Thank you for your contribution.

[gardener-robot-ci-1]

Thank you @sgaist for your contribution. Before I can start building your PR, a member of the organization must set the required label(s) {'reviewed/ok-to-test'}. Once started, you can check the build status in the PR checks section below.

[dimityrmirchev]

Hi @sgaist and thank you for opening this PR! I did test the PR and here is my input on it.

Right now the oidc authenticator delegates authentication and authorization to a kube-apiserver. If we set --client-ca-file to the CA used for the webhook authenticator then certificates issued by the authenticating kube-apiserver will no longer be accepted by the oidc webhook (see the same flag in https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/). This is not a functional issue, but it brings inconsistency across the authentication flow in a sense that service account tokens issued by the kube-apiserver will be accepted, but certificates will not.

As a second point it feels weird to me to have an independent CA that verifies the presented client certificate and then the permissions to be checked against the kube-apiserver with a SubjectAccessReview.

The more I think about it reusing the kube-apiserver's authentication and authorization flags was probably not the best solution when the oidc webhook authenticator was first implemented. I think that independent auth capabilities will suite the project better instead of delegating everything to a kube-apiserver. As we see the current setup is not easy to understand and not flexible enough. Reworking that part will be a breaking change in what we have today and will require more time and involvement which is probably not worth it since Structured Auth is already coming in Kubernetes.

This PR enhances the charts to expose an existing capability which I think was not meant to exist in the first place when the initial version of this project happened. Having written than I am reluctant to move forward with the PR, since it might bring more confusion and inconsistency to the authz topic w.r.t. this project.

See also #142

[sgaist]

Hi,

Thanks for the insights. I thought that the certificate and thus the CA would be used for client authentication between the web hook and the API server.

When you write that certificates generated by the API server will not work anymore, do you mean such as the one for the admin user when deploying a cluster using kubeadm ? If so, I did not experiment any issue with that specific certificate but I will do some more testing.

Note that I do understand your hesitation with this patch, I just want to ensure I am not doing something that would break anybody's authentication.