Docker is the most popular containerization technology. Upon proper use, it can increase the level of security (in comparison to running applications directly on the host). On the other hand, some misconfigurations can lead to downgrade the level of security or even introduce new vulnerabilities.
The aim of this cheat sheet is to provide an easy to use list of common security mistakes and good practices that will help you secure your Docker containers.
To prevent from known, container escapes vulnerabilities, which typically end in escalating to root/administrator privileges, patching Docker Engine and Docker Machine is crucial.
In addition, containers (unlike in virtual machines) share the kernel with the host, therefore kernel exploits executed inside the container will directly hit host kernel. For example, kernel privilege escalation exploit (like Dirty COW) executed inside a well-insulated container will result in root access in a host.
Docker socket /var/run/docker.sock is the UNIX socket that Docker is listening to. This is the primary entry point for the Docker API. The owner of this socket is root. Giving someone access to it is equivalent to giving unrestricted root access to your host.
Do not enable tcp Docker daemon socket. If you are running docker daemon with -H tcp://0.0.0.0:XXX or similar you are exposing un-encrypted and un-authenticated direct access to the Docker daemon.
If you really, really have to do this, you should secure it. Check how to do this following Docker official documentation.
Do not expose /var/run/docker.sock to other containers. If you are running your docker image with -v /var/run/docker.sock://var/run/docker.sock or similar, you should change it. Remember that mounting the socket read-only is not a solution but only makes it harder to exploit. Equivalent in the docker-compose file is something like this:
volumes:
- "/var/run/docker.sock:/var/run/docker.sock"Configuring the container to use an unprivileged user is the best way to prevent privilege escalation attacks. This can be accomplished in three different ways as follows:
- During runtime using
-uoption ofdocker runcommand e.g.:
docker run -u 4000 alpine- During build time. Simple add user in Dockerfile and use it. For example:
FROM alpine
RUN groupadd -r myuser && useradd -r -g myuser myuser
<HERE DO WHAT YOU HAVE TO DO AS A ROOT USER LIKE INSTALLING PACKAGES ETC.>
USER myuser
- Enable user namespace support (
--userns-remap=default) in Docker daemon
More information about this topic can be found at Docker official documentation
In kubernetes, this can be configured in Security Context using runAsNonRoot field e.g.:
kind: ...
apiVersion: ...
metadata:
name: ...
spec:
...
containers:
- name: ...
image: ....
securityContext:
...
runAsNonRoot: true
...As a Kubernetes cluster administrator, you can configure it using Pod Security Policies.
Linux kernel capabilities are a set of privileges that can be used by privileged. Docker, by default, runs with only a subset of capabilities.
You can change it and drop some capabilities (using --cap-drop) to harden your docker containers, or add some capabilities (using --cap-add) if needed.
Remember not to run containers with the --privileged flag - this will add ALL Linux kernel capabilities to the container.
The most secure setup is to drop all capabilities --cap-drop all and then add only required ones. For example:
docker run --cap-drop all --cap-add CHOWN alpineAnd remember: Do not run containers with the --privileged flag!!!
In kubernetes this can be configured in Security Context using capabilities field e.g.:
kind: ...
apiVersion: ...
metadata:
name: ...
spec:
...
containers:
- name: ...
image: ....
securityContext:
...
capabilities:
drop:
- all
add:
- CHOWN
...As a Kubernetes cluster administrator, you can configure it using Pod Security Policies.
Always run your docker images with --security-opt=no-new-privileges in order to prevent escalate privileges using setuid or setgid binaries.
In kubernetes, this can be configured in Security Context using allowPrivilegeEscalation field e.g.:
kind: ...
apiVersion: ...
metadata:
name: ...
spec:
...
containers:
- name: ...
image: ....
securityContext:
...
allowPrivilegeEscalation: false
...As a Kubernetes cluster administrator, you can refer to Kubernetes documentation to configure it using Pod Security Policies.
By default inter-container communication (icc) is enabled - it means that all containers can talk with each other (using docker0 bridged network).
This can be disabled by running docker daemon with --icc=false flag.
If icc is disabled (icc=false) it is required to tell which containers can communicate using --link=CONTAINER_NAME_or_ID:ALIAS option.
See more in Docker documentation - container communication
In Kubernetes Network Policies can be used for it.
First of all, do not disable default security profile!
Consider using security profile like seccomp or AppArmor.
Instructions how to do this inside Kubernetes can be found at Security Context documentation and in Kubernetes API documentation
The best way to avoid DoS attacks is by limiting resources. You can limit memory, CPU, maximum number of restarts (--restart=on-failure:<number_of_restarts>), maximum number of file descriptors (--ulimit nofile=<number>) and maximum number of processes (--ulimit nproc=<number>).
Check documentation for more details about ulimits
You can also do this inside Kubernetes: Assign Memory Resources to Containers and Pods, Assign CPU Resources to Containers and Pods and Assign Extended Resources to a Container
Run containers with a read-only filesystem using --read-only flag. For example:
docker run --read-only alpine sh -c 'echo "whatever" > /tmp'If an application inside a container has to save something temporarily, combine --read-only flag with --tmpfs like this:
docker run --read-only --tmpfs /tmp alpine sh -c 'echo "whatever" > /tmp/file'Equivalent in the docker-compose file will be:
version: "3"
services:
alpine:
image: alpine
read_only: trueEquivalent in kubernetes in Security Context will be:
kind: ...
apiVersion: ...
metadata:
name: ...
spec:
...
containers:
- name: ...
image: ....
securityContext:
...
readOnlyRootFilesystem: true
...In addition, if the volume is mounted only for reading mount them as a read-only
It can be done by appending :ro to the -v like this:
docker run -v volume-name:/path/in/container:ro alpineOr by using --mount option:
docker run --mount source=volume-name,destination=/path/in/container,readonly alpineTo detect containers with known vulnerabilities - scan images using static analysis tools.
- Free
- Commercial
- Snyk (open source and free option available)
- anchore (open source and free option available)
- Aqua Security's MicroScanner (free option available for rate-limited number of scans)
- JFrog XRay
- Qualys
To detect misconfigurations in Kubernetes:
To detect misconfigurations in Docker:
By default, the Docker daemon is configured to have a base logging level of 'info', and if this is not the case: set the Docker daemon log level to 'info'. Rationale: Setting up an appropriate log level, configures the Docker daemon to log events that you would want to review later. A base log level of 'info' and above would capture all logs except the debug logs. Until and unless required, you should not run docker daemon at the 'debug' log level.
To configure the log level in docker-compose:
docker-compose --log-level info upMany issues can be prevented by following some best practices when writing the Dockerfile. Adding a security linter as a step in the the build pipeline can go a long way in avoiding further headaches. Some issues that are worth checking are:
- Ensure a
USERdirective is specified - Ensure the base image version is pinned
- Ensure the OS packages versions are pinned
- Avoid the use of
ADDin favor ofCOPY - Avoid curl bashing in
RUNdirectives
References: