Docker Security Options
So you are currently in the Virtual Machine world and considering transitioning to a containerized environment as you want to smoothen your application pipeline and gain the benefits of a Docker containerized environment. But you have heard from many the containers are insecure and 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.
Containers by themselves are secure, 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:
Docker Security Options |
|
-
A key point: Container security video on Docker network security
In this container security video, we will go through some basics of containers along with the Docker attack surface. The building blocks of containers are namespaces and control groups. However, they share the host kernel, which is a security concern. We will also address container orchestrators with Kubernetes and Kubernetes namespace and discuss PODs, Services, NAT, and VXLAN.
- A key point: Back to basics with Docker security
To use Docker safely in production and development, you must know the potential security issues and the primary tools and techniques for securing container-based systems. The defenses for your system 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.
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. For this, you must consider all the infrastructures to improve your security posture. 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, I.P. 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 to automate 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 have observability into systems and applications and be proactive in these findings. It is not something you can buy and 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.
Data Point | Single Platform |
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, many default tools will be at the disposal of bad actors. For example, we have image vulnerability, access control exploits, container escape, 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. You should stay 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 minimizes the attack vector available to the attacker. You also want to keep an eye on the CAP_SYS_ADMIN. This flag grants access to an extensive range of privileged activities. There are many other capacities that containers run by default that can cause havoc.