Describe the current problem
Currently the problem is twofold:
- Some
securityContext are not configurable by the helm chart.
- Several default values for
securityContext are not as secure as they should be
For example, the deployment for the gpu-operator has no configurable securityContext and, by default, it is left empty.
It is doubtful that this deployment needs full capabilities, privilege escalation, etc. Hence it would make sense to provide a good security posture out of the box.
Describe the solution you'd like
Allow configuring securityContexts of the different pods that can be deployed through this helm chart. (partially discussed here #2070)
Provide good default for the various securityContext (aka stricted possible while allowing the container to fulfill its role), e.g.:
securityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL
readOnlyRootFilesystem: true
runAsGroup: 2000
runAsNonRoot: true
runAsUser: 2000
seccompProfile:
type: RuntimeDefault
What is the added value?
This would improve the default security out of the box for helm chart users. If the containers currently support it, there isn't much downside to improving the default security.
It also helps clarifying to the end-user that these values are officially supported and will not cause any problem with the containers (e.g.: readOnlyRootFilesystem: true could for example cause problems for containers expecting to write to specific directories). By having them already specified, the end-user does not need to do extensive testing to ensure it does not cause any issue.
Describe the current problem
Currently the problem is twofold:
securityContextare not configurable by the helm chart.securityContextare not as secure as they should beFor example, the deployment for the
gpu-operatorhas no configurablesecurityContextand, by default, it is left empty.It is doubtful that this deployment needs full capabilities, privilege escalation, etc. Hence it would make sense to provide a good security posture out of the box.
Describe the solution you'd like
Allow configuring securityContexts of the different pods that can be deployed through this helm chart. (partially discussed here #2070)
Provide good default for the various
securityContext(aka stricted possible while allowing the container to fulfill its role), e.g.:What is the added value?
This would improve the default security out of the box for helm chart users. If the containers currently support it, there isn't much downside to improving the default security.
It also helps clarifying to the end-user that these values are officially supported and will not cause any problem with the containers (e.g.:
readOnlyRootFilesystem: truecould for example cause problems for containers expecting to write to specific directories). By having them already specified, the end-user does not need to do extensive testing to ensure it does not cause any issue.