-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Option to preserve default file mode bit in atomicwriter volumes #2606
Option to preserve default file mode bit in atomicwriter volumes #2606
Conversation
Welcome @abhisheksinghbaghel! |
Hi @abhisheksinghbaghel. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/ok-to-test |
/assign |
/test pull-enhancements-verify |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: abhisheksinghbaghel The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/test pull-enhancements-verify |
1 similar comment
/test pull-enhancements-verify |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.../sig-storage/2605-option-to-preserve-default-file-mode-bit-in-atomicwriter-volumes/README.md
Outdated
Show resolved
Hide resolved
.../sig-storage/2605-option-to-preserve-default-file-mode-bit-in-atomicwriter-volumes/README.md
Outdated
Show resolved
Hide resolved
Can you make it non-draft PR please? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can the use case be solved by a CSI driver implementation that specifically opts-out of fsgroup based change via #1682 ?
.../sig-storage/2605-option-to-preserve-default-file-mode-bit-in-atomicwriter-volumes/README.md
Outdated
Show resolved
Hide resolved
- We would have to pass the payload information along with PreserveDefaultMode to the SetVolumeOwnership routine | ||
and skip chown\chmod if PreserveDefaultMode is set to true for the file. | ||
- This will be more invasive change, but would allow more granular control at per file level | ||
- If users want to preserve Mode for one file in the volume and not for another they can achieve that by creating |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think another alternative would have been to use field introduced in #695 to respect FSGroupChangePolicy
for secrets/configmaps/emptydirs too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FSGroupChangePolicy is a pod level setting whereas in our case we do want to only specify the atomicwriter volume file permission.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think the difference here is that if user wants the behavior for a specific volume and not all volumes for the pod, which appears to be a common grievance in the discussion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could there be a case where user is using secret volume with more than one container in pod but still wants to preserve mode bits? It would require either both containers to run with same UID or containers running as root.
My main concern is - do we need per-volume granularity? Because when we discussed this with @msau42 @tallclair - while @tallclair proposed, it might be helpful to have per-volume granularity , in practical terms either pods that use fsgroup will want to apply it to all volumes or not. Also per-volume granularity is confusing for end users.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gnufied I think these are the ones which were being highlighted in the discussions. Take a look at this one. In certain scenarios users apparently want to preserve the fileMode bit set and that's the motivation here.
istio/istio#32217
I am not sure if there are workarounds available for issues such as above. Just following the conversation and making an educated attempt to address.
We are trying to address the issue for the existing AtomicWriter Volumes like configmaps etc. I am not sure if the CSI driver is in picture here. |
done! |
fb63434
to
2211163
Compare
.../sig-storage/2605-option-to-preserve-default-file-mode-bit-in-atomicwriter-volumes/README.md
Show resolved
Hide resolved
.../sig-storage/2605-option-to-preserve-default-file-mode-bit-in-atomicwriter-volumes/README.md
Outdated
Show resolved
Hide resolved
I think this is looking good. @msau42 to take a look. |
// the volume is modified to be owned by the fsGroup. | ||
// If PreservePermissions is not specified in the volume spec, it defaults to false. | ||
// +optional | ||
PreservePermissions *bool |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that I am looking at the API, would it make sense to move the flag into struct Volume
? This way, it could be used with any volume, incl. in-line ephemeral CSI volumes and, if someone really needs, to opt-out any volume in a pod from fsGroup.
I am not sure if it makes things easier or harder on kubelet side.
Also CC @liggitt because he has been tracking similar issue for awhile now. |
|
||
For the volumes that use AtomicWriter today the files are created with the Mode set in the KeyToPath struct. | ||
If the Mode is not specified then the DefaultMode set for the source is used. | ||
If DefaultMode is not specified then the file is created with mode bit set to 0600. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From definition of DefaultMode
in SecretVolumeSource
:
// YAML accepts both octal and decimal values, JSON requires decimal values
// for mode bits. Defaults to 0644.
This is the default case. | ||
- *Case 2*: The volume has PreservePermissions set to true. | ||
In this case the payload/volume/files are created using Mode/Default mode. | ||
Then the call to SetVolumeOwnership is skipped, in turn preserving the Default file mode on the files. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have we tried commenting out call to SetVolumeOwnership
and just setting the mode on files? It sounds like this will cause files within secret to become inaccessible to the container's process (unless container runs as root). I am not sure if setting the mode is enough.
@abhisheksinghbaghel if we want to preserve the mode, we will have to apply user based ownership to the volume. Please take a look at - #1598 |
If you're targeting alpha for 1.22, you need to answer the enable/disable questions in the production readiness review template: https://github.com/kubernetes/enhancements/blame/master/keps/NNNN-kep-template/README.md#L359-L667 For simplicity, I suggest copying the entire thing and only filling in the sections required for alpha. |
This is the default case. | ||
- *Case 2*: The volume has PreservePermissions set to true. | ||
In this case the payload/volume/files are created using Mode/Default mode. | ||
Then the call to SetVolumeOwnership is skipped, in turn preserving the Default file mode on the files. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ownership and Permissions are different concepts. When PreservePermissions
is true, should the group ownership continue to be driven by fsGroup
?
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close |
@k8s-triage-robot: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/reopen |
@benjaminxie: You can't reopen an issue/PR unless you authored it or you are a collaborator. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
xref #2605
/sig storage