design/20191218-security-context-deprecation.md
The idea is to be able to define a securityContext from an arbitrary yaml block without being restricted to just the attributes currently supported.
For example, by supporting a block like the following in the values.yaml file:
securityContext:
fsGroup: 1111
runAsUser: 2222
runAsNonRoot: true
The logic for supporting the new securityContext in the values.yaml file should be backwards compatible with the securityContext.enabled parameter.
No security context block should be defined if:
securityContext is empty
or securityContext.enabled is defined and securityContext.enabled is false
Otherwise a securityContext block should be defined
When a securityContext block has to be generated, we should fall back and support the deprecated structure if:
securityContext.enabled is true
Otherwise, we copy the securityContext block as it is to support the new format.
Defaults
Input:
No security context specified
Output:
Nothing generated
Legacy parameters with enabled only and no additional parameters
Input:
securityContext:
enabled: true
Output:
securityContext:
fsGroup: 1001
runAsUser: 1001
Legacy parameters with enabled, group and user
Input:
securityContext:
enabled: true
fsGroup: 1111
runAsUser: 2222
Output:
securityContext:
fsGroup: 1111
runAsUser: 2222
New default format
Input:
securityContext: {}
Output:
New format with arbitrary block
Input:
securityContext:
fsGroup: 1111
runAsUser: 2222
runAsNonRoot: true
Output:
securityContext:
fsGroup: 1111
runAsNonRoot: true
runAsUser: 2222
Legacy parameters with enabled set to false and extra parameters that should be ignored
Input:
securityContext:
enabled: false
fsGroup: 1111
runAsUser: 2222
Output:
Legacy parameters with enabled set to false
Input:
securityContext:
enabled: false
Output:
Block with only fsGroup and runAsUser
Input:
securityContext:
fsGroup: 1111
runAsUser: 2222
Output:
securityContext:
fsGroup: 1111
runAsUser: 2222