mirror of
https://github.com/jpetazzo/container.training.git
synced 2026-07-18 20:39:17 +00:00
163 lines
3.7 KiB
Markdown
163 lines
3.7 KiB
Markdown
# Security models
|
|
|
|
In this section, we want to address a few security-related questions:
|
|
|
|
- What permissions do we need to run containers or a container engine?
|
|
|
|
- Can we use containers to escalate permissions?
|
|
|
|
- Can we break out of a container (move from container to host)?
|
|
|
|
- Is it safe to run untrusted code in containers?
|
|
|
|
- What about Kubernetes?
|
|
|
|
---
|
|
|
|
## Running Docker, containerd, podman...
|
|
|
|
- In the early days, running containers required root permissions
|
|
|
|
(to set up namespaces, cgroups, networking, mount filesystems...)
|
|
|
|
- Eventually, new kernel features were developed to allow "rootless" operation
|
|
|
|
(user namespaces and associated tweaks)
|
|
|
|
- Rootless requires a little bit of additional setup on the system (e.g. subuid)
|
|
|
|
(although this is increasingly often automated in modern distros)
|
|
|
|
- Docker runs as root by default; Podman runs rootless by default
|
|
|
|
---
|
|
|
|
## Advantages of rootless
|
|
|
|
- Containers can run without any intervention from root
|
|
|
|
(no package install, no daemon running as root...)
|
|
|
|
- Containerized processes run with non-privileged UID
|
|
|
|
- Container escape doesn't automatically result in full host compromise
|
|
|
|
- Can isolate workloads by using different UID
|
|
|
|
---
|
|
|
|
## Downsides of rootless
|
|
|
|
- *Relatively* newer (rootless Docker was introduced in 2019)
|
|
|
|
- many quirks/issues/limitations in the initial implementations
|
|
|
|
- kernel features and other mechanisms were introduced over time
|
|
|
|
- they're not always very well documented
|
|
|
|
- I/O performance (disk, network) is typically lower
|
|
|
|
(due to using special mechanisms instead of more direct access)
|
|
|
|
- Rootless and rootful engines must use different image storage
|
|
|
|
(due to UID mapping)
|
|
|
|
---
|
|
|
|
## Why not rootless everywhere?
|
|
|
|
- Not very useful on clusters
|
|
|
|
- users shouldn't log into cluster nodes
|
|
|
|
- questionable security improvement
|
|
|
|
- lower I/O performance
|
|
|
|
- Not very useful with Docker Desktop / Podman Desktop
|
|
|
|
- container workloads are already inside a VM
|
|
|
|
- could arguably provide a layer of inter-workload isolation
|
|
|
|
- would require new APIs and concepts
|
|
|
|
---
|
|
|
|
## Permission escalation
|
|
|
|
- Access to the Docker socket = root access to the machine
|
|
```bash
|
|
docker run --privileged -v /:/hostfs -ti alpine
|
|
```
|
|
|
|
- That's why by default, the Docker socket access is locked down
|
|
|
|
(only accessible by `root` and group `docker`)
|
|
|
|
- If user `alice` has access to the Docker socket:
|
|
|
|
*compromising user `alice` leads to whole host compromise!*
|
|
|
|
- Doesn't fundamentally change the threat model
|
|
|
|
(if `alice` gets compromised in the first place, we're in trouble!)
|
|
|
|
- Enables new threats (persistence, kernel access...)
|
|
|
|
---
|
|
|
|
## Avoiding the problem
|
|
|
|
- Rootless containers
|
|
|
|
- Container VM (Docker Desktop, Podman Desktop, Orbstack...)
|
|
|
|
- Unfortunately: no fine-grained access to the Docker API
|
|
|
|
(no way to e.g. disable privileged containers, volume mounts...)
|
|
|
|
---
|
|
|
|
## Escaping containers
|
|
|
|
- Very easy with some features
|
|
|
|
(privileged containers, volume mounts, device access)
|
|
|
|
- Otherwise impossible in theory
|
|
|
|
(but of course, vulnerabilities do exist!)
|
|
|
|
- **Be careful with scripts invoking `docker run`, or Compose files!**
|
|
|
|
---
|
|
|
|
## Untrusted code
|
|
|
|
- Should be safe as long as we're not enabling dangerous features
|
|
|
|
(privileged containers, volume mounts, device access, capabilities...)
|
|
|
|
- Remember that by default, containers can make network calls
|
|
|
|
(but see: `--net none` and also `docker network create --internal`)
|
|
|
|
- And of course, again: vulnerabilities do exist!
|
|
|
|
---
|
|
|
|
## What about Kubernetes?
|
|
|
|
- Ability to run arbitrary pods = dangerous
|
|
|
|
- But there are multiple safety mechanisms available:
|
|
|
|
- Pod Security Settings (limit "dangerous" features)
|
|
|
|
- RBAC (control who can do what)
|
|
|
|
- webhooks and policy engines for even finer grained control
|