The fact that containers share the kernel of the Linux server boosts their performance and makes them lightweight. Because of this, Linux containers pose the most significant security risk. Namespaces are not everywhere in the kernel, which is the main reason for this concern.

Because cgroups and standard namespaces provide some necessary isolation from the host’s core resources, containerized applications are more secure than noncontainerized applications. However, containers should not be used as a replacement for good security practices. It would be best if you run all your containers as you would run an application on a production system. The same should apply if your application runs as a nonprivileged user on a server.

Docker Attack Surface

So you are currently in the Virtual Machine world and considering transitioning to a containerized environment. You want to smoothen your application pipeline and gain the benefits of a Docker containerized environment. But you have heard from many that the containers are insecure and are concerned about Docker network security. There is a Docker attack surface to be concerned about.

For example, containers run by root by default and have many capabilities that scare you. Yes, we have a lot of benefits to the containerized environment, and containers are the only way to do it for some application stacks. However, we have a new attack surface with some benefits of deploying containers and forcing you to examine Docker security options. The following post will discuss security issues, a container security video to help you get started, and an example of Docker escape techniques.

New Attacks and New Components

Containers are secure by themselves, and the kernel is pretty much battle-tested. A container escape is hard to orchestrate unless misconfiguration could result in excessive privileges. So, even though the bad actors’ intent may stay the same, we must mitigate a range of new attacks and protect new components.

To combat these, you need to be aware of the most common Docker network security options and follow the recommended practices for Docker container security. A platform approach is also recommended, and OpenShift is a robust platform for securing and operating your containerized environment.

For pre-information, you may find the following posts helpful: 

1. OpenShift Security Best Practices
2. Docker Default Networking 101
3. What Is BGP Protocol in Networking
4. Container Based Virtualization
5. Hands On Kubernetes

Back to basics with Docker Security Options

Docker Security

To use Docker safely in production and development, you must be aware of potential security issues and the primary tools and techniques for securing container-based systems. Your system’s defenses should also consist of multiple layers.

For example, your containers will most likely run in VMs so that if a container breakout occurs, another level of defense can prevent the attacker from getting to the host or other containers. Monitoring systems should be in place to alert admins in the case of unusual behavior. Finally, firewalls should restrict network access to containers, limiting the external attack surface.

Container Isolation:

One of the key security features of Docker is container isolation, which ensures that each container runs in its own isolated environment. By utilizing Linux kernel features such as namespaces and cgroups, Docker effectively isolates containers from each other and the host system, mitigating the risk of unauthorized access or interference between containers.

Image Vulnerability Scanning:

To ensure the security of Docker images, it is crucial to scan them for vulnerabilities regularly. Docker Security Scanning is an automated service that helps identify known security issues in your containers’ base images and dependencies. By leveraging this feature, you can proactively address vulnerabilities and apply necessary patches, reducing the risk of potential exploits.

Docker Content Trust:

Docker Content Trust is a security feature that allows you to verify the authenticity and integrity of images you pull from Docker registries. By enabling this feature, Docker ensures that only signed and verified images are used, preventing the execution of untrusted or tampered images. This provides an additional layer of protection against malicious or compromised containers.

Role-Based Access Control (RBAC):

Controlling access to Docker resources is critical to maintaining a secure environment. Docker Enterprise Edition (EE) offers Role-Based Access Control (RBAC), which allows you to define granular access controls for users and teams. By assigning appropriate roles and permissions, you can restrict access to sensitive operations and ensure that only authorized individuals can manage Docker resources.

Network Segmentation:

Docker provides various networking options to facilitate communication between containers and the outside world. Implementing network segmentation techniques, such as bridge or overlay networks, helps isolate containers and restrict unnecessary network access. By carefully configuring the network settings, you can minimize the attack surface and protect your containers from potential network-based threats.

Container Runtime Security:

In addition to securing the container environment, it is equally important to focus on the security of the container runtime. Docker supports different container runtimes, such as Docker Engine and containerd. Regularly updating these runtimes to the latest stable versions ensures that you benefit from the latest security patches and bug fixes, reducing the risk of potential vulnerabilities.

Docker Attack Surface

Often, the tools and appliances in place are entirely blind to containers. The tools look at a running process and think, if the process is secure, then I’m secure. One of my clients ran a container with the DockerFile and pulled an insecure image. The onsite tools did not know what an image was and could not scan it.

As a result, we had malware right in the network’s core, a little bit too close to the database server for my liking. 

Yes, we call containers a fancy process, and I’m to blame here, too, but we need to consider what is around the container to secure it fully. For a container to function, it needs the support of the infrastructure around it, such as the CI/CD pipeline and supply chain.

To improve your security posture, you must consider all the infrastructures. If you are looking for quick security tips on Docker network security, this course I created for Pluralsight may help you with Docker security options.

Ineffective Traditional Tools

The containers are not like traditional workloads. We can run an entire application with all its dependencies with a single command. The legacy security tools and processes often assume largely static operations and must be adjusted to adapt to the rate of change in containerized environments. With non-cloud-native data centers, Layer 4 is coupled with the network topology at fixed network points and lacks the flexibility to support containerized applications.

There is often only inter-zone filtering and east-to-west traffic may go unchecked. A container changes the perimeter, and it moves right to the workload. Just look at a microservices architecture. It has many entry points as compared to monolithic applications.

Docker container networking

When considering container networking, we are a world apart from the monolithic. Containers are short-lived and constantly spun down, and assets such as servers, IP addresses, firewalls, drives, and overlay networks are recycled to optimize utilization and enhance agility. Traditional perimeters designed with I.P. address-based security controls lag in a containerized environment.

Rapidly changing container infrastructure rules and signature-based controls can’t keep up with a containerized environment. Securing hyper-dynamic container infrastructure using traditional networks ​​and endpoint controls won’t work. For this reason, you should adopt purpose-built tools and techniques for a containerized environment.

The Need for Observability

Not only do you need to implement good Docker security options, but you also need to concern yourself with the recent observability tools. So, we need proper observability of the state of security and the practices used in the containerization environment, and we need to automate this as much as possible—not just the development but also the security testing, container scanning, and monitoring.

You are only as secure as the containers you have running. You need to be observable in systems and applications and proactive in these findings. It is not something you can buy; it is a cultural change. You want to know how the application works with the server, how the network is with the application, and what data transfer looks like in transfer and a stable state.  

What level of observation do you need so you know that everything is performing as it should? There are several challenges to securing a containerized environment. Containerized technologies are dynamic and complex and require a new approach that can handle the agility and scale of today’s landscape. There are initial security concerns that you must understand before you get started with container security. This will help you explore a better starting strategy.

Docker attack surface: Container attack vectors 

We must consider a different threat model and understand how security principles such as least privilege and in-depth defense apply to Docker security options. With Docker containers, we have a completely different way of running applications and, as a result, a different set of risks to deal with.

Instructions are built into Dockerfiles, which run applications differently from a normal workload. With the correct rights, a bad actor could put anything in the Dockerfile without the necessary guard rails that understand containers; there will be a threat.

Therefore, we must examine new network and security models, as old tools and methods won’t meet these demands.  A new network and security model requires you to mitigate against a new attack vector. Bad actors’ intent stays the same. They are not going away anytime soon. But they now have a different and potentially easier attack surface if misconfigured.

I would consider the container attack surface pretty significant; if not locked down, bad actors will have many default tools at their disposal. For example, we have image vulnerabilities, access control exploits, container escapes, privilege escalation, application code exploits, attacks on the docker host, and all the docker components.

Docker security options: A final security note

Containers by themselves are secure, and the kernel is pretty much battle-tested. You will not often encounter kernel compromises, but they happen occasionally. A container escape is hard to orchestrate unless misconfiguration could result in excessive privileges. It would be best if you stayed clear of setting container capabilities that provide excessive privileges from a security standpoint.

Minimise container capabilities: Reduce the attack surface.

If you minimize the container’s capabilities, you are stripping down the container’s functionality to a bare minimum. And we mentioned this in the container security video. Therefore, the attack surface is limited, and the attack vector available to the attacker is minimized. 

You also want to keep an eye on CAP_SYS_ADMIN. This flag grants access to an extensive range of privileged activities. Containers run many other capacities by default that can cause havoc.

As Docker continues to gain popularity, understanding and implementing proper security measures is essential to safeguarding your containers and infrastructure. By leveraging the security options discussed in this blog post, you can mitigate risks, protect against potential threats, and ensure the integrity and confidentiality of your applications. Stay vigilant, stay secure, and embrace the power of Docker while keeping your containers safe.