opensource/rkt
1
0
Fork 0
mirror of https://github.com/rkt/rkt.git synced 2026-03-13 09:40:21 +08:00
Code Issues Packages Projects Releases Wiki Activity

Documentation: security: unexpected host-pod communication channels

Browse Source 
We cover file descriptor passing and runtime mount injection.
This commit is contained in:
Iago López Galeiras
2018-01-08 17:55:33 +01:00
parent 8c7fb082da
commit d690bf74cf
1 changed files with 28 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

29
Documentation/security.md
View File

@@ -1,6 +1,6 @@
# Security best practices
This document tries to give an overview of the security recommendations to follow when running rkt containers.
This document tries to give an overview of the security recommendations to follow when running rkt containers and discuss non-obvious communication channels between the host and the pod.
## General recommendations
@@ -21,8 +21,35 @@ Here are some security best practices:
* To avoid the previous point: **share a full filesystem instead of just a directory in a filesystem if possible**. For example, a mounted partition or some file mounted with `mount -o loop`.
* **Sharing devices from the host to the container is generally not recommended**. If you need to do it, you can find examples in the [block devices documentation](block-devices.md).
## Incoming mounts
Mounts can be added to a pod at runtime by using [`machinectl bind`][machinectl-bind] or when adding apps to a rkt pod with the [app experiment][app-experiment].
This could be used in a malicious way although it requires privileges on the host.
## File descriptors
In certain situations, some file descriptors belonging to the host namespaces are sent to the pod.
### Socket activation
rkt supports [socket-activated services][rkt-socket-activated] and [socket-proxyd][socket-proxyd].
This means some file descriptors will be passed from the host to the container when using those features.
In particular, all file descriptors defined in the socket unit file accompanying the service file where rkt is started are passed to the container.
### sd\_notify
rkt supports the [sd_notify][sd_notify] mechanism to notify systemd on the host that the pod is ready.
This means systemd in the pod will receive a file descriptor which can be used to send information about whether the apps are initialized or not to the host.
[aci-schema]: https://github.com/appc/spec/blob/master/spec/aci.md#image-manifest-schema
[rkt-run-subcommands]: subcommands/run.md#options
[capabilities-guide]: capabilities-guide.md
[seccomp-guide]: seccomp-guide.md
[user-ns-limitations]: devel/user-namespaces.md#current-limitations
[rkt-socket-activated]: using-rkt-with-systemd.md#socket-activated-services
[socket-proxyd]: using-rkt-with-systemd.md#bidirectionally-proxy-local-sockets-to-another-possibly-remote-socket
[sd_notify]: https://www.freedesktop.org/software/systemd/man/sd_notify.html
[machinectl-bind]: https://www.freedesktop.org/software/systemd/man/machinectl.html#bind%20NAME%20PATH%20%5BPATH%5D
[app-experiment]: devel/pod-lifecycle.md#app