Security Posture improvements

[Klwilson2272]

cert-manager helm chart version v0.12.1
Does not allow setting security context fields.

Run as non-root. It appears the chart hardcodes the root user 0 in the daemonset.yaml

Also spec.secruityContext.privileged=false is desired, so that this avoids issues with security compliance tools.

[baurmatt]

Doesn't a CSI provider require root and privileged by design?

[wmgroot]

I deploy this csi-driver into my customers' Kubernetes clusters as part of my work, and this is regularly flagged as a high severity security issue. I'd like to get this addressed upstream rather than working with exceptions.

privileged: true is not required for a CSI driver to function. I believe the requirements of this CSIDriver are satisfied with use of hostPaths that are mounted into each pod that needs access to the certs being managed.

Here's the aws-ebs-csi-driver for reference, which does not set privileged: true.
https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/charts/aws-ebs-csi-driver/templates/_node.tpl

Docs for privileged.

kubectl explain pod.spec.containers.securityContext.privileged
KIND:       Pod
VERSION:    v1

FIELD: privileged <boolean>


DESCRIPTION:
    Run container in privileged mode. Processes in privileged containers are
    essentially equivalent to root on the host. Defaults to false. Note that
    this field cannot be set when spec.os.name is windows.

CSIDriver docs.
https://kubernetes-csi.github.io/docs/developing.html

I believe that this line can simply be removed without breaking any of the existing functionality of this CSIDriver, and will drastically improve the security surface area of the tool.
https://github.com/cert-manager/csi-driver/blob/main/deploy/charts/csi-driver/templates/daemonset.yaml#L86