Move generation of CA to the main reconciliation loop

[flavio]

Is your feature request related to a problem?

Currently the kubewarden-controller generates certificates for each Policy Server instance declared by the user. All these certificates are signed by a self-signed CA.

The CA data is stored inside of a Secret which is generated the 1st time a PolicyServer resource is created.

The audit-scanner needs to make https requests against the Policy Servers defined inside of the cluster. Because of that, we mount the certificate of this CA into the audit scanner Cron Jobs. In this way we can ensure a secure communication between the audit-scanner and the Policy Servers.

The problem

The audit-scanner Cron Job is currently created by the kubewarden-controller helm chart; this happens as soon as the helm chart is installed. However, in the beginning there's no Policy Server defined, hence there's no root CA yet, hence there's no Secret containing the CA information. Kubernetes will immediately schedule the execution of the Cron Job, which will fail for as long as the 1st Policy Server is created.

This leaves a better impression to the end users, they might think their installation is broken.

Solution you'd like

We should move the generation of the CA outside of the reconciliation loop that monitors Policy Server resources. This should be done inside of the main control loop.

By doing that we will ensure the CA secret is created almost immediately.

This is not enough to solve the issue, but it's a starting point. I'll file another issue to keep track of what has to be done.

Alternatives you've considered

We have thought about other solutions, but unfortunately there's no other way to go. We could generate the CA via helm, but we don't want to go this way. We prefer to keep full control over the CA, particularly about how often this is automatically renewed.

Anything else?

Changing the name and purpose

While moving the code, we would like to rename the CA. Right now the CA is explicitly about "Policy Server", both in terms of the name of the secret and its x509 details.

We would like to make this CA more "generic", make it just about Kubewarden (the project). This would allow us to leverage this CA later on, when getting rid of cert-manager. We could in fact use this CA to sign all the certificates used by the Kubewarden stack:

• Policy Server (already done)
• Kubewarden Controller Webhook (to be done - currently handled via cert-manager)

Relation with 1.7.0 release candidates

We are about to tag 1.7.0-rc2. We don't want this change to be part of RC2 because it's too invasive. RC2 will cope with the limitations described at the top of the issue.

This will be part of RC3

TODO:

• [x] https://github.com/kubewarden/kubewarden-controller/issues/547
• [ ] https://github.com/kubewarden/kubewarden-controller/issues/544
• [ ] https://github.com/kubewarden/kubewarden-controller/issues/545
• [ ] https://github.com/kubewarden/kubewarden-controller/issues/546
• [ ] https://github.com/kubewarden/docs/issues/252
• [ ] https://github.com/kubewarden/helm-charts/issues/321

Nice to have:

• [x] https://github.com/kubewarden/kubewarden-controller/issues/548

[flavio]

@jvanz this could be something for you to tackle during the next sprint

[jvanz]

There is no "main reconciliation loop". Inside the controller manager we have 3 reconciler. One for each of our CRDs (aka AdmissionPolicy, ClusterAdmissionPolicy and PolicyServer). Therefore, I can see three possible solutions:

1. Merge all controllers into one: I don't think we should do this. We had this single controller in the past and we split it to improve user experience
2. Add a new controller for CA stuff: I'm in favor of this one. This give us more control over the CA. And this seems to be the ultimate goal, and in the future removing cert-manager.
3. Create the certificate during controller manager setup: this seems the easy fix for now. But considering option two it seems not worth it.

I've started to work in the option 2. Let me know if I'm missing something.

[flavio]

Sure, go ahead with option 2

[fabriziosestito]

Superseded by #7, #818 , #819