FIle permissions changes during mutation

[vistasunil]

Is there an existing issue for this?

• I have searched the existing issues

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:

...
terminationGracePeriodSeconds: 30
volumes:
- name: example
  secret:
    defaultMode: 400
    secretName: example
 ...

During deployment, policy mutates the fsgroup to 1 for the pod and changes permission on the file as well:

/example/..2024_05_30_14_22_45.1613250004:
total 8
drwxr-sr-x. 2 root bin   80 May 30 13:30 .
drwxrwsrwt. 3 root bin  120 May 30 13:30 ..
-r--r-----. 1 root **bin** 1679 May 30 13:30 example

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:

/example/..2024_05_30_14_22_45.1613250004:
total 8
drwxr-xr-x. 2 root root   80 May 30 14:22 .
drwxrwxrwt. 3 root root  120 May 30 14:22 ..
-r--------. 1 root **root** 1679 May 30 14:22 example

Steps To Reproduce

This can be reproduced by deploying any pod without fsgroup defined and mounting a secret file with 400 permissions.

Environment

- OS: Linux
- Architecture: x86_64

Anything else?

No response

[vistasunil]

@jvanz any update on this issue?

[viccuad]

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:

https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods

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?