Implement mutual TLS authentication

[jvanz]

There are some threat from the threat model that explain how a bad actor could intercept the traffic between the admission controller and API server. To mitigate this, the Kubewarden project could implement mutual TLS authentication. This way avoiding a man in the middle (MITM) attack (threat kubewarden/kubewarden-controller#8) and spoofing (threat kubewarden/kubewarden-controller#9).

NOTE: This is an issue created from RFC discussing the admission control threat model. It's created to allow the Kubewarden team discuss the proposed mitigation further and start to work on each actionable item when possible

Proposal

kubewarden-controller

The controller should take a new flag/environment variable that contains the name of the CA used by the client.

The certificate must be injected inside of the Pod. This can be done by extending our helm chart to mount the CA certificate from a ConfigMap into the Pod.

Our controller is built using controller-runtime, which means we can use this feature.

The kubewarden-controller is also in charge of creating the Policy Server Deployment objects. When mTLS is enabled for the kubewarden-controller, this setting should be automatically propagated also to the Policy Server deployments.

Issues:

• [ ] https://github.com/kubewarden/helm-charts/issues/630
• [x] https://github.com/kubewarden/kubewarden-controller/issues/993

Policy Server

The policy-server has a new flag that enables mTLS. The CA certificate is read from the local filesytem and is then used to enforce mTLS. The policy-server should also monitor this file for changes and automatically reload the certificate when it changes.

• [x] https://github.com/kubewarden/policy-server/issues/1067

audit-scanner

audit-scanner makes HTTP connections against the Policy Server, hence it must authenticate itself.

We cannot assume the audit-scanner process is going to use the same client certificate as Kubernetes' API server (hopefully not, it would be a bad security practice).

A more reasonable approach could be to use Kubewarden's internal CA to generate a client certificate that could be used by the audit-scanner process.

We could always generate this certificate and make the audit-scanner use it. Simply, when mTLS is not enabled, the Policy Server is not going to verify the client certificate.

• [ ] https://github.com/kubewarden/audit-scanner/issues/462

Docs

• [ ] https://github.com/kubewarden/docs/issues/540
• [ ] Update threat model page

End to end tests

• [ ] https://github.com/kubewarden/kubewarden-end-to-end-tests/issues/134