Skip to content

KEP-4639: Allow writeable, container isolated volume content #5288

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.

Sign up for GitHub

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
+13 −4
Open

KEP-4639: Allow writeable, container isolated volume content #5288

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 12 additions & 3 deletions keps/sig-node/4639-oci-volume-source/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -298,7 +298,10 @@ the OS or version of the scanning software.
- Allowing direct mounting of OCI objects introduces potential attack
vectors. Mitigation includes thorough security reviews and limiting access
to trusted registries. Limiting to non-runnable content
and read-only mode will lessen the security risk.
and read-only mode will lessen the security risk. If the image content is
writable in a strictly pod isolated way, then runtimes have to
ensure that proper isolation, as well as the necessary cleanup on
pod removal.
- Path traversal attacks are a high risk for introducing security
vulnerabilities. Container Runtimes should re-use their existing
implementations to merge layers as well as secure join symbolic links in
Expand Down Expand Up @@ -586,8 +589,14 @@ feature cannot be used. Pods using the new `VolumeSource` combined with a not
supported container runtime version will fail to run on the node, because the
`Mount.host_path` field is not set for those mounts.

For security reasons, volume mounts should set the [`noexec`] and `ro`
(read-only) options by default.
For the most conservative security approach, image volumes _should_ be mounted
by runtimes with enabled `ro` (read-only), `rro` (recursive read-only) and/or the
`noexec` flag. Runtimes _may_ support writable or executable volumes in the same
way as the running container image contents are writable (for example by
utilizing overlayfs). This enables users to modify the image volume contents in
a non-persistent and pod isolated environment. **In the end it's ultimately up
to the runtime to define the mounting behavior depending on the underlying
technologies being used.**

Note: in the process of mounting images into the container's rootfs, there may need to be intermediate mounts created. This is especially relevant if
the CRI implementation wishes to support one image being mounted with multiple different SELinux labels. If that's done, the CRI implementation is responsible
Expand Down
2 changes: 1 addition & 1 deletion keps/sig-node/4639-oci-volume-source/kep.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -46,7 +46,7 @@ stage: beta
# The most recent milestone for which work toward delivery of this KEP has been
# done. This can be the current (upcoming) milestone, if it is being actively
# worked on.
latest-milestone: "v1.33"
latest-milestone: "v1.34"

# The milestone at which this feature was, or is targeted to be, at each stage.
milestone:
Expand Down