So you are currently in the Virtual Machine world and considering the transition 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, run by root by default, and have tons of capabilities that just scare you. Yes, we have a lot of benefits to the containerized environment and for some application stacks, containers are the only way to do it. However, we have a new attack surface with some of the benefits of deploying containers. 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 security options.
Use Case: I’m Sorry to Say This Happened
More than often the tools and appliances you have in place are completely blind to containers. The tools just look at a running process and think, well if the process is secure then I’m secure. One of my clients run a container with the DockerFile and pulled an insecure image. The tools onsite did not know what an image was, therefore could not scan it. As a result, we had malware right in the core of the network, 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 fully secure it. For a container to function, it needs the support of the infrastructure around it such as the CI/CD pipeline. For this, you need to consider all of the infrastructures to improve your security posture. If you are looking for quick security tips on docker security, this course I created for Pluralsight may help you with Docker security options.
We have 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 need to 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.
Containers 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 tools and techniques that are purpose-built for a containerized environment.
The Need for Proper 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 to be proactive in these findings. It is not something that you can buy and it’s a cultural change. You want to know how the application is working with the server, how the network is with the application, and what data transfer looks like in transfer and also in 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.
Container Attack Vectors: New Threat Model
We must consider a different threat model and understand how security principles such as least privilege and defense in depth apply to the available Docker security options. With Docker containers, we have a completely different way to run applications and, as a result, a different set of risks to deal with.
Instructions are built into Dockerfiles, which run applications considerably differently from a normal application workload. With the correct rights, a bad actor could put anything in the Dockerfile without the necessary guard rails in place that understand containers, there will be a threat. Therefore, we need to 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 set of attack vectors. Bad actors’ intent stays the same. They are not going away anytime soon. But they now have a different and potentially easier attack surface to play with if not configured correctly. Personally, I would consider the container attack surface to be pretty large and if not locked down, there will be many default tools at the disposal of bad actors.
For example, we have image vulnerability, access control exploits, container escape, privilege escalation, and application code exploits and attacks on the docker host and all of the docker components.
Docker Security Options: A Final Security Note!
Containers by themselves are secure, and the kernel is pretty much battle-tested it’s not often you will come across a kernel compromise but they do happen from time to time. A container escape is hard to orchestrate unless a container misconfiguration could result in excessive privileges. You should stay clear of setting container capabilities that provide excessive privileges from a security standpoint. If you minimize the container capabilities, you are stripping down the container’s functionality to a bare minimum. 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.