[Feature Request]: Support for Inserting Pod/Container Fields (e.g., SecurityContext, AutomountServiceAccountToken) in datasciencepipelinesapplication Custom Resource #707
In environments with strict security policies (e.g., Kyverno policies enforcing non-root containers), it is essential to customize the security context at the pod and container levels for workloads deployed by the datasciencepipelinesapplication CR. For instance:
Setting securityContext.runAsNonRoot: true
Controlling whether the automountServiceAccountToken is enabled or disabled (e.g., automountServiceAccountToken: true)
Currently, these fields cannot be directly set or modified via the datasciencepipelinesapplication CR, which causes issues in clusters where such settings are mandatory for pod creation. This results in blocking from security policies that enforce non-root execution and other security measures.
Ideally, these fields could be specified in a manner similar to the resources section of the CR
Describe alternatives you've considered
My current alternative is to mutate datasciencepipelinesapplication deployments with a different Kyverno policy. I would welcome any other suggestions as well !
Feature description
In environments with strict security policies (e.g., Kyverno policies enforcing non-root containers), it is essential to customize the security context at the pod and container levels for workloads deployed by the datasciencepipelinesapplication CR. For instance:
securityContext.runAsNonRoot: trueautomountServiceAccountTokenis enabled or disabled (e.g., automountServiceAccountToken: true)Currently, these fields cannot be directly set or modified via the datasciencepipelinesapplication CR, which causes issues in clusters where such settings are mandatory for pod creation. This results in blocking from security policies that enforce non-root execution and other security measures. Ideally, these fields could be specified in a manner similar to the resources section of the CR
Describe alternatives you've considered
My current alternative is to mutate datasciencepipelinesapplication deployments with a different Kyverno policy. I would welcome any other suggestions as well !
Anything else?
No response