[Feature] Add securityContext to de default deployment from the operator.

[BobVanB]

Describe the solution you'd like
We use common policies in our cluster, like:

• capabilities.drop: ALL
• runAsNonRoot: false
• resourceLimits: must exists
• allowPrivilegeEscalation: false

This feature request is for adding default securityContext to the deployment that the operator makes or add a parameter in the values.yaml that will add a securityContext.

securityContext:
  capabilities:
    drop:
    - ALL

For the helm deployment we also add allowPrivilegeEscalation

securityContext:
  allowPrivilegeEscalation: false
  capabilities:
    drop:
    - ALL

It would be nice if the containers started with the operator are least priviliged possible, to minimize the attack surface of a container.

Describe alternatives you've considered

tridentctl
Currently we use tridentctl to deploy. But where not happy with the way of upgrading.
We have kustomize patch files for this.

Additional context

---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: trident-csi
spec:
  template:
    spec:
      containers:
      - name: trident-main
        securityContext:
          capabilities: {drop: ["ALL"]}
      - name: driver-registrar
        securityContext:
          capabilities: {drop: ["ALL"]}

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: trident-csi
spec:
  template:
    spec:
      containers:
      - name: trident-main
        securityContext:
          capabilities: {drop: ["ALL"]}
      - name: trident-autosupport
        securityContext:
          capabilities: {drop: ["ALL"]}
      - name: csi-provisioner
        securityContext:
          capabilities: {drop: ["ALL"]}
      - name: csi-attacher
        securityContext:
          capabilities: {drop: ["ALL"]}
      - name: csi-resizer
        securityContext:
          capabilities: {drop: ["ALL"]}
      - name: csi-snapshotter
        securityContext:
          capabilities: {drop: ["ALL"]}

[gnarl]

Hi @BobVanB,

We've done some testing in this area and are going to be updating our documentation regarding the required security settings in the near future.

The trident-main container in the daemonset Pod in particular needs to run as a privileged container within the Pod to access the needed binaries on the K8S worker node. We believe that in Kubernetes that allowPrivilegeEscalation is ignored in a privileged container. Also, a privileged container likely ignores the following:

- name: trident-main
        securityContext:
          capabilities: {drop: ["ALL"]}

[gnarl]

Hi @BobVanB,

We've updated our documentation with details on permissions needed by Trident. These permissions were recently reviewed and reflect the least privileges possible for the Trident 22.07 release.