introduce DOCKER_REMOUNT_SYS_RW (allow Docker-in-Kata without --privileged)#191
introduce DOCKER_REMOUNT_SYS_RW (allow Docker-in-Kata without --privileged)#191AkihiroSuda wants to merge 1 commit intodocker-library:masterfrom
Conversation
AkihiroSuda
changed the title
|
Does this change also allow DIND on non-kata runtimes?
Curious; do we know if a more limited set of caps works? |
…leged) Docker-in-Kata can be launched with `--privileged` but it ruins the benefit of Kata because it mounts `/dev` from the host. Now Docker-in-Kata can be launched without `--privileged`: $ docker run --runtime kata -e DOCKER_REMOUNT_SYS_RW=1 --cap-add all --security-opt seccomp=unconfined --security-opt systempaths=unconfined docker:dind Tested with Kata Containers 1.8.0 (1.8.1 is broken: kata-containers/runtime#2047) Alternative to moby/moby#39702 Signed-off-by: Akihiro Suda <[email protected]>
This doesn't seem to work on runc, however, even if it worked with runc, it doesn't make sense, because
Probably we can drop some capabilities related to power management and Smack stuffs, but I don't see any benefit because anyway we need |
| # | ||
| # Full flags needed for Docker-in-Kata: | ||
| # --runtime kata -e DOCKER_REMOUNT_SYS_RW=1 --cap-add all --security-opt seccomp=unconfined --security-opt systempaths=unconfined | ||
| echo "Remounting /sys in RW" |
There was a problem hiding this comment.
Per the comment above;
- Should this print a
WARNING:? - Should this produce an error if runtime is default/runc ?
There was a problem hiding this comment.
Should this print a WARNING: ?
I don't think this is WARNING. Because dind is typically launched with --privileged and sysfs is already RW
Should this produce an error if runtime is default/runc ?
I'm not sure there is a robust way to detect runc
There was a problem hiding this comment.
I'm not sure there is a robust way to detect runc
Perhaps if --runtime is not set, idk (it was just a thought)
There was a problem hiding this comment.
Can't inspect docker run flags from containers :p
There was a problem hiding this comment.
🤦♂ arch, my bad, wasn't thinking; was thinking the flag was passed to the dind daemon 😂
|
Hilariously, this used to be a major part of the purpose of the |
|
Do you think this should be moved to |
|
I do think this functionality makes more sense there, yes. Do you think there's anything that can be done to auto-detect the "bad" state to some degree? You can see the old "cgroups mounting" implementation in the commit which deleted it, which might be useful for reference: moby/moby@81aa1b5#diff-fbcad9c68dbfcabbf5f6bf87019cc571 As a perhaps cleaner (in this case, meaning more generic) idea, is it potentially possible to detect that the https://github.com/tianon/cgroupfs-mount/blob/481f8b684fd67656f9d4c79828b48e24b6f9f321/cgroupfs-mount is probably another OK example, although it might have more edge cases (often used by folks/distributions without This is also further complicated by cgroups v2, right? |
|
Kata maintainers seems preferring moby/moby#39702 |
3 participants
Docker-in-Kata can be launched with
--privilegedbut it ruins the benefit of Kata because it mounts/devfrom the host.Now Docker-in-Kata can be launched without
--privileged:Tested with Kata Containers 1.8.0
(1.8.1 is broken: kata-containers/runtime#2047)
Alternative to moby/moby#39702
Signed-off-by: Akihiro Suda [email protected]