cert rotation

[mhenriks]

What this PR does / why we need it:

Currently certs expire after a year. This fixes that by having the operator create/refresh certs. The apiserver and uploadproxy mount certs as secrets and watch for updates to update TLSConfig appropriately.

The operator also creates/manages CA certs for upload server/client.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #

Special notes for your reviewer:

The apiserver doesn't support non disruptive update of their CA certs. This would be a pretty easy add on, though. Have to watch CA bundles and reregister apiserver when it changes.

Release note:

Cert rotation

[mhenriks]

/hold

Still want to think on a couple things

[coveralls]

Coverage decreased (-2.2%) to 60.496% when pulling bb42b35 on mhenriks:cert-rotation into 5b3365f on kubevirt:master.

[coveralls]

Coverage decreased (-0.8%) to 61.724% when pulling d9d8d3c on mhenriks:cert-rotation into 4bceec8 on kubevirt:master.

[maya-r]

(I might be misreading the code...) Having the private and public keys files in the same directory and accessing it by mounting the directory probably means that the pods verifying keys can also impersonate that key.
Is this a concern?

[maya-r]

It would be nice to write more of the design somewhere, at least in the commit message
for example:

keys are stored on the master node's filesystem in
/var/run/certs/cdi-uploadproxy-server-cert
... several other places ...
readers watch them for change using fsnotify
writers modify the file

[mhenriks]

(I might be misreading the code...) Having the private and public keys files in the same directory and accessing it by mounting the directory probably means that the pods verifying keys can also impersonate that key.
Is this a concern?

@maya-r Not quite sure I understand your concern. But the paths we are protecting are as follows. And in no case does the client have direct access to the server key. In all cases, verification is done via the CA bundles which are stored in configmaps and separate from the keys/certs stored in secrets.

upload proxy -> upload server: upload proxy has upload server CA bundle configmap mounted
clone source -> upload server: clone source has upload server CA bundle passed in as env var
kube apiserver -> cdi apiserver: kube apiserver get apiserver CA bundle in apiserver and webhook registrations
openshift outer -> upload proxy: upload proxy CA bundle is included Route resource

[mhenriks]

/test pull-containerized-data-importer-e2e-k8s-1.16.2-ceph

[mhenriks]

/test pull-containerized-data-importer-e2e-k8s-1.16.2-ceph

[mhenriks]

using fork until this is merged: openshift/library-go#540

[aglitke]

If we merge this could you create a gh issue so we don't forget to back to the trunk?

[mhenriks]

/test pull-containerized-data-importer-e2e-k8s-1.16.2-upg

[mhenriks]

/retest

[mhenriks]

/hold cancel

[aglitke]

LeaderElectionAnnotation?

[mhenriks]

lol yup

[awels]

/lgtm
/approve

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: awels

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 [awels]

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

[awels]

/test pull-containerized-data-importer-e2e-k8s-1.15.1-ceph