Open vistasunil opened 4 months ago
@jvanz any update on this issue?
Hi, thanks for opening this issue.
Policy should only change the fsgroup to minimum range value if not defined in the pod yaml but its goes beyond that and changes mounted file permissions as well.
This is not performed by the policy per se, the policy only sets the Pods' securityContext.fsGroups
.
Changing the mounted file permissions is done by Kubernetes when securityContext.fsGroup
is set. It is its default behavior. One can configure the securityContext further via securityContext.fsGroupChangePolicy
, but note that it doesn't apply to Secrets, as the reproducer you provided. You can learn more about it here:
Steps To Reproduce This can be reproduced by deploying any pod without fsgroup defined and mounting a secret file with 400 permissions.
If you want the policy to accept without performing mutations when no fsgroup has been defined, one can configure the policy settings using MayRunAs
as explained on the readme. Eg:
rule: MayRunAs
ranges:
- min: 1000
max: 2000
If you want the policy to reject without performing mutations, one can configure the policy settings using MustRunAs
, and can deploy the policy with spec.mutating
to false
.
I hope I'm understanding the problem correctly. Does this solve the issue?
Is there an existing issue for this?
Current Behavior
We see this policy changing file permissions during fsgroup changes, which is undesirable and impacting workloads to run as expected. Policy should only change the fsgroup to minimum range value if not defined in the pod yaml but its goes beyond that and changes mounted file permissions as well.
Below is the example: Actual yaml file deployed with example mount:
During deployment, policy mutates the fsgroup to 1 for the pod and changes permission on the file as well:
Expected Behavior
Permissions on the file must not be touched by mutating policy. Because this is impacting the work expected from pods.
So, after mount the file permission should look like below:
Steps To Reproduce
This can be reproduced by deploying any pod without fsgroup defined and mounting a secret file with 400 permissions.
Environment
Anything else?
No response