8 Major Risks and 33 Best Practices for Docker Container Security丨IDCF

Containers and orchestrators such as Kubernetes usher in a new era of application development methods, supporting microservices architecture and continuous development and delivery. According to our latest State of Containers and Kubernetes Security Report, Docker is by far the dominant container runtime engine, with a penetration rate of 91%.

Containerization has many benefits and is therefore widely adopted. According to Gartner, by 2020, more than 50% of global organizations will be running containerized applications in production environments. However, using Docker containers to build applications also brings new security challenges and risks. A single compromised Docker container can threaten all other containers as well as the underlying host, highlighting the importance of Docker security.

Docker security protection can be roughly divided into two aspects: protecting and hardening the host so that container leaks will not lead to host leaks, and protecting Docker containers. Focusing on container security, this article highlights Docker container security risks and challenges and provides best practices for hardening your environment during the build and deployment phases and protecting Docker containers at runtime.

Given Kubernetes' widespread adoption and critical role in orchestrating containers, we also share best practices for securing Kubernetes. Finally, we provide 11 critical security questions that a container security platform should be able to answer, giving you the insight and protection you need to run containers and Kubernetes securely in production.

8 container security challenges Docker must solve

Enterprises have long deployed applications on virtual machines (VMs) or bare metal servers. Security for this type of infrastructure involves protecting your applications and the hosts they run on, and then protecting them while the applications are running. Containerization introduces new challenges that need to be addressed.

Containers enable microservices, which increases the complexity of data traffic as well as network and access control.
Containers rely on base images, and it can be challenging to know whether the source of the image is safe or not. Images may also contain vulnerabilities that can be propagated to all containers using the image.
Containers have a short life cycle, so monitoring them, especially while running, can be difficult. Another security risk comes from a lack of visibility into the changing container environment.
Unlike VMs, containers are not necessarily isolated from each other. One substandard container can cause damage to other containers.
Containerized environments have more components than traditional VMs, including Kubernetes, which presents its own set of security challenges. Can you tell which deployments or clusters are affected by a high-severity vulnerability? Was it exposed to the Internet? If a given vulnerability is exploited, what is the blast radius? Are the containers running in a production environment or a development/test environment?
Container configuration is another area that poses security risks. Is the container running with higher privileges than it should? Does the image launch unnecessary services that increase the attack surface? Are there secrets stored in the image?
As one of the biggest security drivers, compliance can be a special challenge given the rapid growth of container environments. Many traditional components that help demonstrate compliance, such as firewall rules, take very different forms in a Docker environment.
Finally, existing server workload security solutions are insufficient to address container security challenges and risks.

26 Docker Security Best Practices

The following is a list of best practices from industry standards and StackRox customers for securely configuring your Docker containers and images.

Always use the latest version of Docker. For example, the runC vulnerability earlier this year was patched quickly after the release of Docker version 18.09.2.
Make sure that only trusted users are members of the Docker group so that only trusted users are allowed to control the Docker daemon. Check out this article to learn more about reducing the attack surface of the Docker daemon.
Ensure appropriate rules can provide an audit trail:
1. Docker daemon
2. Docker files and directories:
  1. /var/lib/docker
  2. /etc/docker
  3. Docker.service
  4. Docker.socket
  5. /etc/default/docker
  6. /etc/docker/daemon.json
  7. /etc/sysconfig/docker
  8. /usr/bin/containerd
  9. /usr/sbin/runc
Protect all Docker files and directories by ensuring that they are owned by the appropriate user (usually root) and that their file permissions are set to restrictive values (see the CIS Baseline section of the Docker daemon configuration file).
Use a registry with a valid registry certificate or one that uses TLS to minimize the risk of traffic interception.
If you are using a container that does not have an explicit container user defined in the image, you should enable user namespace support, which will allow you to remap container users to host users.
Disables the container from acquiring new permissions (by default, containers are allowed to acquire new permissions), so this configuration must be set explicitly. Another step you can take to mitigate privilege escalation attacks is to remove setuid and setgid permissions from the image.
As a best practice, containers should be run as a non-root user (UID other than 0). (The default is for the container to run as root within the container.)
Only use trusted base images when building containers. This tip may seem obvious, but third-party registries often do not have any governance policies for the images stored in them. It's important to know which images are available on a Docker host, understand where they come from, and see what's inside. You should also enable content trust for Docker for image verification and only install verified packages into the image.
Use a minimal base image that does not contain unnecessary packages that could lead to a larger attack surface. Fewer components in a container reduce the number of attack vectors available, and the smallest images also yield better performance because there are fewer bytes on disk and less network traffic to copy the image. BusyBox and Apline are two options for building a minimal base image.
Implement a strong governance policy that enforces frequent image scans. Before entering the build phase, stale images should be rejected, or images that have not been scanned recently should be rescanned.
Build a workflow to regularly identify and remove stale or unused images and containers from hosts.
Don't store secrets in images/Dockerfiles. By default, you can store secrets in a Dockerfile, but storing secrets in an image makes the secret accessible to any user of that image. When you need ciphertext, please use the ciphertext management tool.
When running a container, remove all functionality required for the container to run. You can use Docker's CAP DROP feature to remove features (also known as Linux features) from a specific container, and CAP ADD to add only those features that are required for the container to function properly.
Do not run containers with the --privileged flag, as this type of container will have most of the functionality available to the underlying host. This flag also overrides any rules you set using CAP DROP or CAP ADD.
Do not mount sensitive host system directories on containers, especially in writable mode, as this may expose them to malicious changes that may result in host compromise.
Don't run sshd inside a container. The ssh daemon does not run in the container by default and should not be installed to simplify the security management of SSH servers.
Do not map any ports lower than 1024 within the container as they are considered privileged ports and will transmit sensitive data. By default, Docker maps container ports to ports in the range 49153–65525, but it allows mapping containers to privileged ports. As a general rule of thumb, make sure only the required ports are open on the container.
Do not share the host's network namespace, process namespace, IPC namespace, user namespace, or UTS namespace unless necessary to ensure proper isolation between the Docker container and the underlying host.
Specify the amount of memory and CPU required for the container to run as designed, rather than relying on arbitrary amounts. By default, Docker containers share their resources equally without restrictions.
Set the container's root filesystem to read-only. Once running, the container does not require changes to the root filesystem. Any changes made to the root file system may be for malicious purposes. To maintain the immutable nature of containers—new containers are not patched but recreated from new images—you should not make the root filesystem writable.
Apply PID restrictions. One of the advantages of containers is strict process identifier (PID) control. Each process in the kernel has a unique PID, and containers leverage the Linux PID namespace to provide each container with a separate view of the PID hierarchy. Limiting the PID effectively limits the number of processes running in each container. Limiting the number of processes in a container prevents excessive spawning of new processes and potentially malicious lateral movement. Imposing PID limits also prevents fork bombs (processes that continually replicate themselves) and abnormal processes. In most cases, if your service always runs a specific number of processes, then setting the PID limit to that exact number can mitigate many malicious behaviors, including reverse shells and remote code injection.
Do not configure mount propagation rules for shares. Shared mount propagation means that any changes made to a mount will be propagated to all instances of that mount. Mount propagation should be set to slave or private mode so that necessary changes to the volume are not shared with (or propagated to) containers that do not require the change.
Do not use the docker exec command with privileges or the user=root option, as this setting can provide extended Linux capabilities to the container.
Do not use the default bridge "docker0". Using the default bridge exposes you to ARP spoofing and MAC flooding attacks. Instead, the container should be on a user-defined network, not the default "docker0" bridge.
Do not mount a Docker socket inside the container, as this approach will allow the process inside the container to execute commands, giving it full control of the host.

7 Best Practices for Kubernetes Security

As the de facto standard for container orchestration, Kubernetes plays a key role in ensuring application security. To effectively protect containerized applications, you must leverage contextual information from Kubernetes and its native policy enforcement capabilities. For example, Kubernetes has several built-in security features that make it easier to operate container security throughout its lifecycle, including Kubernetes RBAC, network policies, and admission controllers. Leverage the power of these inherent controls in Kubernetes to secure your containerized environment.

Here are some Kubernetes security best practices to help secure containers throughout their lifecycle.

For RBAC, assign roles and ClusterRoles to specific users or groups rather than granting cluster administrator privileges to any user or group.
Avoid duplicating permissions when using Kubernetes RBAC as doing so may create operational issues.
Remove unused or inactive RBAC roles to focus on active roles when troubleshooting or investigating security incidents.
Use Kubernetes network policies to isolate pods and explicitly allow only the communication paths required for your application to run. Otherwise, it will face horizontal and north-south threats.
If a pod requires Internet access (either ingress or egress), create an appropriate network policy to enforce the correct network segmentation/firewall rules, then create a label for said network policy to target, and finally associate the pod with that label.
Use the PodSecurityPolicy admission controller to ensure proper governance policies are enforced. The PodSecurityPolicy controller can prevent a container from running as root or ensure that the container's root filesystem is mounted read-only (these suggestions should sound familiar, as they were both in the previous list of Docker measures).
Enforce image registry governance policies using the Kubernetes Admission Controller to automatically deny all images obtained from untrusted registries.

Final Thoughts – Make sure you answer these 11 security questions about Docker container environments

To help quickly assess your security posture, we’ve compiled a list of questions that your security, DevSecOps, or DevOps team should be able to answer easily if your cloud native stack has been built with appropriate security measures.

How many images are there on a host whose last scan date is more than 60 days ago?
How many images/containers have high severity vulnerabilities?
Which deployments are affected by these high-severity vulnerable containers?
Are any containers in the affected deployment storing secrets?
Are any of the vulnerable containers running with root or privileged flags?
Are there any vulnerable containers in the pod that don't have a network policy associated with it (meaning it allows all communication)?
Are any containers running in production affected by this vulnerability?
Where do the images we use come from?
How do we block images pulled from untrusted registries?
Are we able to see which processes are executing while the container is running?
Which clusters, namespaces, and nodes are not compliant with the CIS benchmarks for Docker and Kubernetes?

By following these best practices compiled in this list, you'll be able to take the most important steps to successfully harden your Docker and Kubernetes environments and protect your business-critical applications.