Docker containers introduce consistency for applications and their various components and configurations by packaging them together in an isolated environment that remains consistent regardless of where they are hosted. Docker containers have their own processes, network and mounts while they share the same operating system kernel.
While the isolation provided by containers does improve application security, they do, however, introduce new security challenges since they change the way an application environment is configured, and where and how applications run. Containers can be open to attack through poorly configured images and containers or even unknowingly pulling images from a malicious publisher.
The following are essential security features you should know:
NAMESPACES – Namespace provide isolation for the container by limiting what processes it can see and access within a system or other containers. This also provides each container with its own network stack, and those containers can interact using each other's network interfaces. Available namespaces are:
- Mount: This provides a container with its own unique and isolated filesystem. This prevents a container from accessing the mount namespace of a host or other containers.
- Process ID : Process ID isolates the process tree of each container and prevents container from seeing the processes of other containers or the host that it is running on.
- Network: This is what provides a container with its own isolated network stack e.g. network interfaces, IP addresses, port ranges, and route tables.
- Inter-process Communications (IPC): This is used for sharing memory access within a container and also isolates it from other containers.
- UTS (hostnames): Provides a container with its own unique hostname
- User (user): This allows containers to have their own user and group ID, and with the ability to be mapped to a user on the host.
Note: Though container namespacing isolates container environment from the host and other containers, it is possible to configure them to share a namespace to allow containers to access each other’s namespace.
CONTROL GROUPS (CGROUPS) – They are responsible for accounting and limiting resources in a container. By default, containers have no resource constraints so CGROUPS allow for control of how much share of resources a container can have e.g. memory, cpu and disc IOPS. Without enforcing these limits a compromised container could use up all the system resources resulting in system failure. Setting these limits will also help guarantee quality of service to applications by giving them a sufficient share of resource they required to fulfill their function.
CAPABILITIES – Capabilities are a set of privileges that can be added or removed to limit operations that can be performed by a container. By default, a container runs as root user with a lot of the capabilities that a system root user has. By removing some of these capabilities you can limit the container to those capabilities necessary for it to perform its function effectively while reducing the opportunity for abuse.
MANDATORY ACCESS CONTROL (MAC) – With MAC you can set security policies that cannot be modified by the user a container runs with. With Docker you can use Linux Security Modules (LSM) like AppArmor and SElinux. AppArmor can associate a profile with an executable assigned with a set of capabilities and file access permissions. SElinux is another type of LSM that lets you enforce constraints on a process’ access to files and other processes.
SECCOMP – Seccomp is Linux kernel feature that allows you to restrict actions available within a container. It puts restrictions on what system calls can be made by a process e.g. “mkdir”, “chown”, etc. These restrictions can be set with a profile configuration on the Docker daemon. On executing a “docker run” command your container will inherit these settings. Alternatively, you could assign a custom profile configuration directly on the container to give it permissions/restrictions compatible with its intended function.
DOCKER CONTENT TRUST – This allows you to verify the integrity of the publisher and the image so you can establish if the image you’ve pulled came from a legitimate source. Docker Content Trust allows developers to sign their images before pushing them to the registry. Using the docker daemon, you can sign images, create signing keys, and add/remove users who are allowed to sign your images.
SECURITY SCANNING – Security scanning helps identify vulnerabilities within your images. This is done by performing a binary level scan on images and uses a database of known vulnerabilities. You could used Docker Hub's integrated security feature for image scans or use other tools such as Anchor Engine, Gitlab CI's intergrated image scan feature, Clair, and Trivy, to name a few.
MULTI-STAGE BUILD – A running container looks and functions like an Operating Systems but it is meant to run a single process, your application. On accessing the shell of a running container you can run familiar commands that you’d find on a Linux OS but chances are you don’t need all that functionality for your application to fulfill its intended function. Access to full OS capabilities in your containers means a compromised container would make it possible for an attacker to take advantage of those OS capabilities and use that as a springboard for a wider attack on your system.
With Multi-Stage Build you can configure your Dockerfile to build your image in multiple stages where your first stage would serve the purpose of providing all dependencies you need to build and compile your application. You can then use that first stage’s output by copying it into the second stage which will use a Distrolless docker image as a base image for your final image. The container you’ll create from this will run with no shell or programs you expect to find on a Linux OS. What will be available is your application and language runtime dependencies. The resulting image will be significantly smaller as only the second stage is built into it, therefore, significantly reducing the attack surface.
Final Thoughts:
As with many popular technologies, Docker attracks attention from malicious actors so it is therefore important to be aware of available features to tighten security in your environment. Ensure that you always run the latest version as there could be vulnerabilities discovered in older versions that will definitely be exploited by hackers. Lastly, standard principles of securing your host environment should be applied to avoid attacks on your containers.
Top comments (2)
Sometimes I wonder if it's worth the hassle or if you should just go barebone. With tools like docker many people (including me) will just take it a run it. We don't have the luxury of reading the documents end to end and we end with very risky setup just waiting to be hacked.
I hear you. My personal preference are cloud serverless technologies like Lambda, DynamoDB, RDS, API Gateway, etc. These give you a significantly reduce responsibility on dealing with security just based on not having to deal with servers.