Docker Security

Securing Docker

With the increase in the market demand for container-based applications, Docker security has become one of the prime topics of advancement and focus. As the containers are used in the mainstream deployment and are moved to production, the security of containers becomes crucial. 

This article is dedicated to addressing the concerns and topics related to Docker Security. Docker Security comprises the overall security of Docker, with each of its components along with the data associated. While talking about Docker security, it is important to focus on the following 4 major areas:

• Loopholes in the container configuration, which can be either due to its innate feature or because of user customization.
• The intrinsic security of the kernel along with its support for namespaces and groups.
• The attack surface of the daemon.
• The "hardening" security features of the kernel and how they communicate with containers.

Security Features in Docker

Docker is in-built with many robust features, including an internal provision for security in order to establish a comprehensive system for running applications of various standards of sensitivity.

[Related Page: What is Docker?]

Docker Content Trust Signature Verification

The Docker Engine can be run to allow only the signed images. The Docker Content Trust signature verification is built in the dockerd binary, inside the Dockerd configuration file. This helps in authenticating the images before pulling them into the Docker repository.

You can enable this feature by configuring the daemon.json file, whereby only the signed repositories with user-specified root key can be pulled in. This feature provides more capabilities to the administrators for performing the image signature verification than in CLI mode.

Linux kernel capabilities

By default, Docker runs the containers with certain restricted capabilities. It means that all the processes running inside a container will not be given the "root" capabilities. Processes like web servers, which connect to port 1024, will not need any root access.  They can be just given the net_bind_service instead. Similarly, the processes will be given the root privilege only in case of the need.

Typically, servers run several processes as root by default, including the SSH daemon, cron daemon, logging daemons, kernel modules, network configuration tools, etc. However, a container works differently, with restricted root privilege, as almost all the important tasks will be handled by the infrastructure around. This restricted root access in containers reduces the vectors of attack by malicious users, considerably.

[Related Page: Docker Container Security and Tools You Need to Know]

Control Groups

Control groups are important components of Linux containers. They perform the resource monitoring and accounting. Since the Dockers allow multiple containers at a time, the host resources will be extensively utilized. This essentially causes the denial-of-service attacks or the total system shutdown in cases of resource exploitation by a single container.

Control groups ensure a fair share of these resources to each container. They are particularly important on multi-tenant platforms, like public and private PaaS, to assure a steady uptime (and performance) even when some containers start to fail.

Kernel Namespaces

When you start the Docker containers, Docker creates the namespaces and control groups for the containers in the background. Namespaces: Namespaces provide the basic isolation of containers. The processes running in one container cannot see the processes running in the other containers or in the host. This is essentially a very robust security feature against wrong data usage and hacking.

Besides this, each container will be assigned to its own network stack. This brings isolation of one container from reaching into the other containers' network system. This feature ensures the network insulation, thus providing container network security. However, containers can be configured to gain access between the other containers in a system to enable communication in case of necessity.

[Related Page: Why is Docker so Popular ]

Other Kernel Security Features

There are several security features included in modern Linux kernels. It is also possible to leverage the existing system like TOMOYO, AppArmor, SELinux, GRSEC, etc. to provide the required security to Dockers, in addition to the inbuilt features of security.

Currently, Docker can only enable these features upon installation and doesn't interfere with the system operations.

Here are a few examples of such systems providing added security.

• You can run a kernel with GRSEC and PAX. This gives many safety controls at both compile-time and run-time; it also wins many threats owing to techniques like address randomization. These security apps don't have to know the Docker specifications as they are container-independent and are developed as global software.
• There are templates like AppArmor and Red Hat which comes with SELinux policies for Docker. They provide an extra safety net (even though it overlaps greatly with capabilities). They also allow you to define your own policies using your favorite access control mechanism.

In general, the Docker is quite secure by itself, especially if you run your process as a non-privileged user.

[Related Page:  Kubernetes Vs Docker swarm]

Best Practices Used in Container Security

Previously, we learned about the default security features available in Dockers. Now, it is important to know about the best practices that serve to strengthen the safety against the external malicious attacks in Docker containers. The practices described below inform us about the ways to implement certain procedures, which ultimately prevent or handle the security breach.

• Docker host and Container Applications security

The first best thing to look for while we talk about Docker security is the security of the Docker host. This is because the containers share a common space with the operating system kernel of the host.

Though Docker seems to be isolated from the host, in reality, they are just "namespaced" processes. 
If the host security is compromised, Docker security will be directly threatened. So, always ensure to keep the host updated and properly protected. Similarly, make sure that the containers are protected from safety violations by adopting the best security practices in your application code.

• Docker Runtime Security

You need to know, exactly what each layer of your container images holds. Make sure that each one of them is secured before running them into production. It is just not sufficient to ensure safety during build time. You also ought to make sure that the third-party installations of containers are tested against the security.

Do not directly download any software during runtime. Anything that a Docker executes must be included and tested in a static container image. For the sake of providing light-weight and simple software, some performance tools will be developed with minimal security clauses. Be wise and check for transparency before anything else.

[Related Page: Overview of Kubernetes]

• Docker image Authenticity

The Internet is a public store. No one can completely trust in the authenticity of many products floating online. So is the source of the container images. Always check for this before downloading the images into your registry. Docker Store is the trusted online platform to download the images.

Docker does the vulnerability tests for these images and certifies for the partner's authenticity. While Docker Hub is a place where any person can upload a container image. So, beware of using any images from the Docker Hub. For your internal images, use the PKI-based trust mechanism to authenticate a person, team, or process that publishes the container images.

• Limit the resource utilization

Since Docker containers are the light-weight processes, a greater number of containers can simultaneously run on a host than on a VM. This means that more than one container will be competing for similar resources from the host at a given time. Though this improves the host resource utilization and allows you to optimize total cost of ownership, this might lead to denial-of-service attacks on containers.

[Related Page: Kubernetes Vs Docker swarm]

You can thus limit the resource utilization on each container by employing the orchestration frameworks such as Kubernetes or Swarm. Besides, AppDynamics conditionally monitors the resources consumption by all containers present on a host. Work on the AppDynamics to create the thresholds and alerts for resource consumption and get alerted whenever the limit is crossed.

• Threats of Running in Super-Privileged Mode

Running the Dockers in the super-privileged mode only increases the threat surface of the containers. It basically loosens the isolation and containerization leaving the entire data centre and VPC environments wide open to the potential danger.

By default, the Dockers won't run in Super-Privileged mode. It asks for the access permissions from the user. Only grant the permissions, when Docker has to access the protected resources.

Docker security tools

There are plenty of open-source tools for docker security. These tools are signed by the CIS, National Vulnerability Database, etc to authenticate their sources. They basically scan the container image, reveal its contents, and compare the contents against the threats.

Automating the container for auditing and incorporating other docker container security systems can turn out to be extremely beneficial for the enterprises to detect and protect against the plausible threats.

Below is a list of few selected, mature open-source tools for the Docker Security.

• Docker Bench for Security

This is the best tool for security for the Docker community edition. This is defined as "A script to audit Docker containers against security benchmarks". It is programmed to audit the dockers against the best security practices.

Docker Bench security auditing is according to the standards set by the CIS. It helps in automating the otherwise tedious process of vulnerability testing.

This can be integrated with the host, cloning it through the Docker Compose or run it directly from the base host.

There is one drawback with the Docker Bench and that is the readability of the output. However, the next releases of the Docker security tools have incorporated better ways of displaying output with rather more clarity.

• Clair

Clair performs the static analysis of the vulnerability of the container. It is developed by CoreOS and is used in Quay.io, which is a public registry alternative to the Docker Hub.

It is defined as "An API-driven static container security analysis with a huge CVE database". Clair basically displays the container image features. The developers can query the Clair API for the vulnerabilities related to the image. Clair is easy to be deployed in the Kubernetes cluster. It also lets you customize with the addition of your own driver to avail of the new features.

• Cilium

Cilium performs the security for the network connections in containers. It is more congenial with the Linux containers and Kubernetes. It is described as "API-aware networking and security at the kernel layer".

It is powered by BPF. It lets you apply and update the Cilium Security Policies without having to change the application code or container configuration.

CoreOS has developed the Cilium in order to keep up with the advanced microservices and quick container development. It has amazing support from the developer community and a dedicated slack channel. It can be easily integrated with the Kubernetes.

• Anchore

Anchore engine is designed to test for the security of the container images. Apart from CVE-based security vulnerability reporting, Anchore Engine can evaluate the images using custom policies.

Policies are based on whitelists or blacklists, file contents, configuration types, credentials or other user-generated cues. It results in a pass or fail output. Anchore can run as a standalone application or as an orchestration platform like Kubernetes.  It can be integrated with Jenkins or GitLab for CI/CD.

Anchore has its own CLI, which is used to manipulate the Anchore Engine. It gives the output in a list of threat levels and details, CVE identifiers, and other related information. It operates like SaaS, as user-defined rules are created using the Anchore Cloud Service graphical user interface (GUI).

• OpenSCAP Workbench

OpenScap is a platform developed specifically for the IT Admins and Security Auditors. It has many features like open security benchmark guides, configuration baselines, and open-source tools. This can be used as a GUI to scan virtual machines, containers, and images.

You can install the OpenSCAP workbench using the following command:

# yum install scap-workbench

OpenScap is based on NIST-certified Security Content Automation Protocol (SCAP) and has many machine-readable security policies. The development teams aim to "allow multiple organizations to efficiently develop security content by avoiding redundancy." This is more global in development and is a good choice for the companies looking for the security of the entire platform.

• Dagda

Dagda can be defined as "A tool for scanning for vulnerabilities, Trojans, viruses, and malware in Docker containers".

It is another option for the static analysis of the container images. The CVE sources of the platform include OWASP dependency check, Red Hat Oval, and the Offensive Security exploit database.

In order to scan the container for the threats, you need to first populate the MongoDB with the vulnerability data and perform the command given below to analyse the Docker Image.

Command:

python3 dagda.py check --docker_image jboss/wildfly

The output reveals the vulnerabilities, severity level, and other relevant details.

It can be controlled both through the CLI and the REST API.

[Related Page: Isolated Development Environments with Docker]

• Notary

Notary is the default Docker image signing framework which is now developed to include other features. Currently, it is managed by Cloud Native Computing Foundation.

Notary can be defined as "A framework for boosting container security with a server for cryptographically delegating responsibility". It is basically used to delegate roles and purposes to containers. The package provides for a server and a client to enable a cryptographically secure method of publishing and verifying the content for the vulnerability.

Notary can be integrated with The Update Framework and the Go language to check the cryptographic integrity of a container image.

• Grafaes

This security tool is developed by IBM and Google in 2017. It helps you create your own Docker security scanning projects. It is officially described as "A metadata API to help govern internal security policies".

It can be used as a metadata API to define the metadata of the virtual machines and the containers. It is also integrated with IBM’s Vulnerability Advisor. It is a great tool available as an open-source software that allows for the speedy detection and handling of the container data vulnerability.

• Sysdig Falco

Falco is basically a Kubernetes-aware security tool which is developed by Sysdig to emphasize behavioral monitoring of containers, hosts, and their network activities.

This software can be used to perform a continuous check on the infrastructure to detect anomalies and set up alerts for any Linux based system. The Falco documentation recommends the user to set up Falco as a container. Sysdig provides the container troubleshooting methods.

• Banyanops Collector

Supported by Banyanops, Collector is an open-source security tool, which is used to scan the container images. Using this, the user can collect container data, implement container security policies, etc.

To begin with, Banyanops Collector can be used as a private registry or as a Container on the Docker Hub. It is also capable of providing SaaS products that perform deep data analysis.

This gets us to an end of the exhaustive list of the open-source container security tools.

Frequently Asked Docker Interview Questions

Why Containers Present Special Security Challenges?

There are certain situations, in which the normal, internal security provisions of the Docker containers can be exposed to challenges.

For example, if the process running inside a container has the same namespace as that of a process inside the host system. This easily presents the container data to risk. Anybody who gains as a root user inside the host can easily break into the container process.

Many users don't validate the source of the container image repositories they use to pull the images from. This is more of a cultural issue existing than a technical problem. People are more informed about authenticating the source in case of downloading packages, say in Linux from public repositories, than while performing the same in the Docker environment.

These are the plausible cases of threats encountered in providing proper Docker Security.

Docker Logging

Michael Floyd, Sumo Logic’s Head of Developer Programs explains in a blog saying, “Sumo Logic delivers a comprehensive strategy for monitoring your Docker infrastructure with a native collection source for events, stats, configurations, and logs, and provides views into things like container performance for CPU, memory, and the network.” He also states that monitoring and collecting the data output and events from the Docker becomes necessary to validate container performance and resource stabilization.

Sumo Logic’s advanced analytics and machine learning capabilities enable you to analyze, troubleshoot, and perform the root cause analysis of the issues related to the distributed container-based application systems.

This brings us to the end of the chapter on Docker Security and its challenges.

List Of MindMajix Docker Courses:

Kubernetes Administration

OpenShift

Docker Kubernetes

OpenShift Administration