-
Notifications
You must be signed in to change notification settings - Fork 0
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
keps/127: Support User Namespaces #3
Conversation
Co-authored-by: Alban Crequy <[email protected]>
Co-authored-by: Alban Crequy <[email protected]>
Co-authored-by: Alban Crequy <[email protected]>
Co-authored-by: Alban Crequy <[email protected]>
Co-authored-by: Alban Crequy <[email protected]>
Co-authored-by: Alban Crequy <[email protected]>
Co-authored-by: Alban Crequy <[email protected]>
Co-authored-by: Alban Crequy <[email protected]>
…ernetes-enhancements into mauricio/userns_proposal_new
Co-authored-by: rata <[email protected]>
Co-authored-by: rata <[email protected]>
Co-authored-by: rata <[email protected]>
Co-authored-by: rata <[email protected]>
Some runtimes, like cri-o, mitigate these problems by using the `metacopy` | ||
option of overlayfs. This option avoids copying the whole file content when an | ||
operation updating only the metadata, like `chown` or `chmod`, is performed. | ||
This solution could be adopted by other runtimes until a more sophisticated |
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.
Metadata only copy up
--------------------
When metadata only copy up feature is enabled, overlayfs will only copy
up metadata (as opposed to whole file), when a metadata specific operation
like chown/chmod is performed. Full file will be copied up later when
file is opened for WRITE operation.
Container/storage used by CRI-O mounts an overlay file system with the metacopy=on flag set, it then chowns all of the lower files in the image to match the user namespace to which the container will run. This operation is very quick compared to standard chowning, since none of the files data has to be copied up. If a second container runs on the same image with the same user namespace, then the chowned image is shared, eliminating the need to chown again.
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.
LGTM
Additional updates to PRR docs
Ensure Implementation stategy captured in the KEP matches latest implementation
chore: rename to `key_id` and use bytes for metadata
…ategy (kubernetes#3661) * Initial KEP for improving pruning in kubectl apply * Add design details Co-authored-by: Katrina Verey <[email protected]> * Add another open question * Links, clarifications, ownerRef and GKNN explanations * Follow-on to initial feedback, address some unresolved blocks * Fix lint errors * Add more detail about reference implementation (#2) * Apply prune jan25 (#3) * More clearly delineate specification vs kubectl details * Move design details of spec to Design Details section * Updates from synchronous conversation * Remove leftover paragraph (#5) Not an alternative rejected any more, given applyset.k8s.io/inventory * Justin has always been coauthor * KEP-3659: production readiness etc (#4) Fill in the testing/ PRR sections. * Fix test failures * Prune: document confused deputy attack and mitigations Likely pushes us to GKNN-derived IDs. * Constrain applyset id We just choose the constrained applyset id to prevent "applyset ID impersonation". * Update KEP and PRR metadata * Enhance testing description * ID vs name fixes * Fixes from soltysh's review --------- Co-authored-by: Justin Santa Barbara <[email protected]>
No description provided.