Pod Security policy feature for k8s version 1.29

[LeonardPoiana]

Hello,

We are trying to follow the security best practices in which a pod/container should not run as root.
Considering this, we are trying to install the trident helm chart on k8s version 1.29 and we don't have the posibility to set the pod/container security policy via the values file.
In order to use the helm chart smoothly and perform upgrades we belive that we should have this option integrated into the values file.

Thanks in advance.

Leonard Poiana
DevOps Engineer

[wonderland]

As a driver (vs. a "normal" app), Trident will need specific privileges for operations such as mounting/unmounting volumes on the nodes. As Pod Security Policies are deprecated/removed since many K8s releases, Trident set the required Pod Security Standard pod-security.kubernetes.io/enforce: privileged label on its namespace. Pods are then defined to follow a least-privilege approach. For example, the security context of the trident-controller pod will drop all privileges, while the trident-node pods will add the required privileges that they specifically need.

Not exactly sure what you are trying to change, that should be surfaced in the Helm chart?

[dmc5179]

The helm chart shows that trident uses security context constraints, at least for OpenShift. I had not noticed until now that trident gives itself the power to create SCCs

  - apiGroups:
      - security.openshift.io
    resources:
      - securitycontextconstraints
    verbs:
      - get
      - list
      - create

Operators are typically installed by a cluster admin. Perhaps it would be best to put the SCCs as yaml files in the helm chart as opposed to giving the application the permanent ability to create SCCs? That would allow trident to do things like create high privilege SCCs. It's akin to creating an IAM role in AWS that has IAM create permissions. It's limitless power to the operator no?