Add validating webhook and webhook tls autoconfiguration

[munnerz]

What this PR does / why we need it:

This PR adds support for ValidatingWebhookConfiguration for cert-manager resources.

This is comprised of a few parts that make it more complex, mostly around securing the TLS endpoint for the webhooks.

Roughly:

• Adds 'webhook tls bootstrap' - when cert-manager starts, it will create an 'internal' CA issuer based on CLI arguments passed to it on startup. We do this because the APIService has failurePolice: Fail, meaning we cannot create real Issuers or Certificates.

Once the secret resource has been provisioned, the webhook will be able to start, and cert-manager will then create the Issuer and Certificate resource in the apiserver, allowing standard renewal to take place from then on.

• Adds a 'apiextensions-ca-sync` CronJob as part of the standard deployment (repo here: https://github.com/munnerz/apiextensions-ca-helper). This periodically syncs Secret resources with APIService and {Validating,Mutating}WebhookConfiguration resources. This job is configured to automatically configure the cert-manager webhook configuration resources with the appropriate caBundle field.

This lays out a general pattern for how webhook TLS can be configured in Kubernetes more generally. I have a doc I'm putting together that details a recommendation for how to secure webhooks other than cert-manager's own webhooks.

Release note:

Add validation webhooks for API types

[munnerz]

So a few more notes on the status of this:

• We need to add a 'selfsigned' issuer first, to make this truly user intervention free. This will allow us to automatically provision the actual signing CA which is then used by the internal ca issuer. Right now, a signing cert still has to be manually provisioned (which cert manager uses to sign webhook serving certs)

• In implementing this, a bug in kube-apiserver was discovered that causes validations to fail in 1/N cases (where N is the number of apiservers) in multi master setups only. This PR fixes that: Ensure webhook service routing resolves kubernetes.default.svc correctly kubernetes/kubernetes#62649 and has been cherry picked into 1.10. We need to provide a way to disable validation checks for 1.10 clusters in the meantime, else nothing will work.

[munnerz]

I am currently blocked on helm/helm#4231 being merged, and helm/helm#3982 making it into a tagged release.

[jetstack-bot]

@munnerz: The following tests failed, say /retest to rerun them all:

Test name	Commit	Details	Rerun command
cert-manager-e2e-v1-7	221fb6f	link	/test e2e v1.7
cert-manager-e2e-v1-8	221fb6f	link	/test e2e v1.8

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

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 understand the commands that are listed here.

[kragniz]

I've tested this locally and it worked well for me. Releasing v0.5 with this turned off by default (and a note in the release notes of how to opt in), maybe defaulting it to on in v0.6 sounds like a good idea.

I got this error when deploying with helm:

helm upgrade cert-manager contrib/charts/cert-manager --reuse-values --set webhook.enabled=true   
Error: found in requirements.yaml, but missing in charts/ directory: webhook

I moved webhook into contrib/charts/cert-manager/charts, which made helm happy.

[munnerz]

Sorry @kragniz - didn't see your review of this PR until now!

Thanks for taking a look 😄

I got this error when deploying with helm:

Yes, if you run helm dep update contrib/charts/cert-manager first, it should build the .tgz in the charts/ directory. I structured it this way so that when the chart is published to helm/charts, it will be package up correctly.

[munnerz]

/check-dco

[munnerz]

As this is disabled by default, I'm going to go ahead and merge this so we can start gathering feedback from users 😄

There may be changes still to make, but let's see what the world thinks first!

[jetstack-bot]

[APPROVALNOTIFIER] This PR is APPROVED

Approval requirements bypassed by manually added approval.

This pull-request has been approved by:

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment