Docker Security

Is Docker secure?

It’s a very simple question, and there is no YES or NO as the answer. It’s always depends upon the way we use it. To find answer of the question we need to understand how the Docker security model plays out.

Before starting, let’s know what Docker allow us out of the box.

• Isolate applications from each other.
• Isolate applications from the host.
• Improve the security of the application by restricting its capabilities.
• Encourage adoption of the principle of least privilege.

What is Docker engine?

It’s a lightweight application runtime with built in features for orchestration, scheduling, networking and security features to build and deploy single or multi-container applications.

Docker Engine hosts and runs containers from the container image file. It also manages networks, and storage volumes.

So how all these Docker features works?

The Docker Engine supports the isolation features available in the Linux operating system and makes them available to the end user via the Docker Client. The isolation features are available out of the box with secure default settings while still allowing the user to adjust the configurations at any time.

How to secure Docker Engine?

There are two main key aspects to securing Docker Engine: namespaces, and cgroups (Control groups)

Namespaces (Kernel Namespaces):-

Namespaces is a feature Docker inherits from the Linux Kernel. Namespaces isolate containers from each other so that each process within a container has no visibility into a process running in a neighboring container.

Initially, Docker containers were run as root users by default, which was cause for a lot of concern. However, since v1.10, Docker supports namespaces, and you can run containers as non-root users.

The various namespaces created for a container include:

• PID Namespace: Anytime a program starts, a unique ID number is assigned to the namespace that is different than the host system. Each container has its own set of PID namespaces for its processes. 
• Mount Namespace: Each container is provided its own namespace for mount directory paths.
• Network Namespace: Each container is provided its own view of the network stack avoiding privileged access to the sockets or interfaces of another container.
• UTS Namespace: UNIX Time Sharing namespace provides isolation between the system identifiers; the hostname and the NIS domain name.
• IPC Namespace: The inter-process communication (IPC) namespace creates a grouping where containers can only see and communicate with other processes in the same IPC namespace.
• User Namespace: User namespaces are a feature to provide both privilege isolation and user identification segregation across multiple sets of processes.

cgroups (Control groups):-

The cgroup of Docker actually leverage the Linux control groups. It’s allow to set limits for CPU, memory, networking, and block IO. By default containers can use an unlimited amount of system resources, so it’s important to set limits so that the entire system is not affected by a single hungry container.

Apart from Namespaces and cgroups, Docker Engine can be further hardened by the use of additional tools like SELinux, AppArmor and Seccomp.

Selinux:-

SELinux provides access control for the kernel. It can manage access based on the type of process running in the container, or the level of the process. Based on this, it either enables or restricts access to the host.

Seccomp:-

Secure Computing Mode (seccomp), a feature in the Linux kernel uses security profiles to restrict the number of calls a process can make.

AppArmor:-

AppArmor attaches a security profile to every process running on a host. The profile defines what resources a process can utilize. Docker applies a default profile to processes, but you can apply a custom profile as well.

Linux Kernel Capabilities (Libcap) and How Docker deals with it?

Libcap:- Set root privilege on Linux. 

The root historically had ability to do anything. Libcap is a set of fine grained controls which allow services or even users with root equivalence to be limited in the scope. It’s also allow non-root users to be granted extra privileges.

In containers, many of the capabilities to manage network and other services are actually not needed. Services like SSH, cron, filesystem mounts and unmounts are not needed, network management is not needed, etc. we should not enable it.

By default, Docker disallow many root capabilities, including the ability to modify the logs, change the networking, modify the kernel memory etc.

Linux hosts can be hardened in many other ways and while deploying Docker enhances the host security. Specifically, Docker site recommend users to run Linux kernels with GRSEC and PAX. These patch sets add several kernel-level safety checks, both at compile-time and run-time, that attempt to defeat or make some common exploitation techniques more difficult. While not Docker-specific, these configurations can provide system-wide benefits without conflicting with Docker.

https://github.com/docker/labs/tree/master/security

Docker Hub:-

Docker Hub is a cloud-based repository in which Docker users and partners create, test, store and distribute container images. Through Docker Hub, a user can access public, open source image repositories, as well as use a space to create their own private repositories, automated build functions, webhooks and work groups.

Third-party security tools for Docker:-

While the above security features provide basic protection for Docker Engine and Repository, they lack the power and reach of a dedicated container security tool. A tool like Twistlock can completely secure your Docker stack end-to-end. It goes beyond any one part, and gives you a holistic view of your entire system.

How to avoid Security challenges?

1. Use Private or Trusted Repositories and Images.
2. Use Docker Content Trust to enforce client-side signing and verification of image tags.
3. Follow common best practices around deploying Docker containers in production using the tool like Docker Bench Security.
4. Don’t use privileged containers unless you treat them the same way you treat any other process running as root.
5. Remove all capabilities except those explicitly required for the processes.
6. Make use of other Linux security options, such as AppArmor, SELinux, grsecurity and Seccomp to customize specific security profiles and guard against unauthorized access.
7. Limit Available Resource Consumption.
8. Implement an Audit Trail with Proper Logging and add the notifications, whether via email, or others such as IRC, Slack, and HipChat.
9. Secure the OS and reduce attack surfaces by removing all unneeded modules and files. Update to the latest security patches.
10. Scan containers for vulnerabilities. Use tool like Jfrog Xray, Twistlock, Aquasec etc.
11. Network segmentation.
12. Protect secrets such as passwords and API keys required for run-time container access by using third party tools or key management services and keep it encrypted using tool like HashiCorp Vault.
13. Reduce the risk by running application containers in read-only/non-persistent mode.
14. Understand normal application network behaviour, and enact a security policy to enforce authorized connections. Monitor every container for abnormal behaviour or policy violations.
15. Perform live scans of all running containers and hosts.
16. Use session level or network encryption where needed.
17. Implement container threat detection to recognize real-time attacks, including threats at the application layer (DDoS, XSS, Slowloris, etc.).
18. Store forensic data on all container security events and perform offline analysis to understand the nature of these events. Capture network data if needed to help forensic analysis of attacks.