Containers have definitely become a popular way to deploy applications. Which is great because they have a huge number of advantages over deploying to a virtual machine. Some of those advantages include being portable, immutable, and lightweight. You can control what is inside of the container that runs your service, and this can lead to a clear, auditable trail. For a security professional, this makes your work easier because you understand what is going on. Securing the container isn't scary, but there is definitely work to do.
What to focus on in container security?
One of the first things you need to remember about container security is that containers are still just running software. They still run code that someone wrote, and usually it's someone else who wrote it.
You want to start off by looking at the pieces that make up your container images. You need to ensure that everything actually needs to be there, and you have nothing extra that may lead to problems down the road. Next, look into what is actually running the container. The container orchestrator has pieces to look at and lock down appropriately. This will prevent an attacker from getting too far into your network if a container is vulnerable to something you aren't aware of.
While containers are different from virtual machines, they can be analyzed for vulnerabilities and secured in many of the same ways. There is overlap in tools looking for things at runtime to ensure that the piece of software is secure. There is also overlap in tools looking for vulnerabilities before the container even deploys.
Because of this, there are a lot of tools and vendors out there to make securing your containers easier, no matter your scenario. There is something out there to help you watch over your system. This helps to ensure that, as the security professional, you can do your job and do it well.
Getting a container security boost
Now we get to the nuts and bolts of securing a container. Start by looking at what goes into the container image being built. This means understanding any of the base images you start from, then understanding how your software is placed inside.
Containers are made of different layers. Each layer comes from somewhere, and understanding how and what built them will ensure that you can understand their security. Again, there are tools to help with this endeavor because doing this manually would be a daunting task.
Working with container images
One way to help ensure that your images are correct is to have a way to sign container images and ensure that those images come from a trusted source. This establishes a system of trust that what was built deploys to your container orchestrator correctly. By only allowing known, good signatures, you can ensure that what the system builds is the same as what is delivered into the production system. This way an attacker can't alter an image and distribute it inside of your system without you knowing about it. At the very least, you will be aware of changes in the system.
Another part to get right is the base image you start from. Using a distroless image when possible can help. Many base images use a standard Linux distribution like Ubuntu, Debian, or Fedora. This means that they come with a lot of standard tools you would find on a normal Linux machine. For containers, that is usually far more than what you need to run your specific software. Distroless images try to limit the number of ancillary pieces that are part of the image. For example, they may remove a shell (i.e., bash or PowerShell) from the system. This would limit an attack's ability to pivot inside of an exploited image. A lot of attacks use other types of scripts or tools that rely on a shell being present to actually execute the attacker’s code. This makes the attacker's job that much more difficult and may slow them down enough for them to give up.
Validating the dependencies
Understanding the different layers means you understand the supply chain that brought the bits of code you are running to you. This helps ensure you are protected against supply chain attacks, which have been increasing over the years. If you don't understand what a software bill of materials (SBOM) is, this would be a good place to start. Try and ensure your dependencies have these so you know your supply chain of software is secure.
Scanners that look at the different layers of your containers are super important. They can catch a number of issues and vulnerabilities that you may not even be aware of. Scanners have looked at software dependencies for years, and extending this to containers is a natural fit. This also reminds you that containers usually have many different pieces and you should be aware of what is in there alongside your software.
Another blunder that happens from time to time is accidentally forgetting either test or development dependencies that are along for the ride. Always make sure that when you build your image that is going to production, you remove any development or test libraries or data before shipping the image. Development and test libraries especially have a lot of known issues that may not be a problem locally, but can unnecessarily expose you to some harmful attacks. Mitigating this kind of exposure is as easy as preventing this kind of data or libraries from leaking into your production environment.
Ensuring a secure runtime
Now your containers are ready, and you have ensured that this is the software you want to run. Let's concentrate now on actually running the software. One of the first things to get right in a container environment is isolating everything correctly. That means having good network policies in place to ensure known containers are talking to known endpoints. Maybe even going as far as ensuring that you follow a zero trust policy. Being aware of how and where your network data flows is critical to detecting threats before they become serious problems.
Some low-hanging fruit to start with are your secrets. Ensure that those secrets are not in plain text configuration files, but are actually using the orchestrator's secret mechanism. Ensuring that those secrets are actually stored as a file on the running container instead of environment variables is also important. This way, if an attacker did break out of the container, they couldn't just find your secrets in environment variables. Instead, they would need to find the file source. Again, this is a way to slow down an attacker and make them work for the important information in your system instead of just handing it to them.
The next thing to look at is locking down root on containers. This ensures that if a container is compromised, they can't escape your container and actually take over the machine that the container runs on. Being very careful of your container's privileges is a great way to limit an attacker's ability to gain control of anything.
Follow good security policies
Next, ensure that you follow good security policies for your container orchestrator. The U.S. military recommends how to secure your Kubernetes cluster and has good practices to follow. For instance, on top of running as non-root, they also recommend:
- Ensuring that you have an immutable file system
- Encrypting your etcd database
- Creating an explicit network deny policy
- Enabling audit logging
This list is just a start. There are many different guides on how to harden your container orchestrator. Some from the government, some from private companies. Try and review a few to get an overview of what are good practices to keep your orchestrator secure.
Tools
With all of these considerations it is important to find tools to ensure that everything is secure as you build your system. There are tools to watch over everything that goes into the system and alert you when you need to take action. Getting these kinds of tools early on can help you pinpoint changes that introduce problems to address. However, if your system is already mature, tools can help you inventory problems. They can also help you figure out what needs to be fixed now rather than later.
Other tools that help you continuously monitor your containers as they run inside of your system are also important. Finding anomalies or new, unexpected behaviors creates an early detect ion system. This ensures that the sooner you spot attacks, the better the outcome will be for you and your customers.
Sonatype has a good offering of container security tools to look at if you are starting from square one, or even if you are trying to augment your existing tools.
I hope this blog post has given you a helpful understanding of what container security means and how to boost the security of your containers. Securing your containers isn't frightening, it's all about understanding the risks.
As with all risks, there are ways to mitigate them. Hopefully this blog post demonstrates some of the risks, and how they can be mitigated.
Use tools to help with this mitigation. They can help out and ensure that your system is secure from the beginning or even if your system is mature, taking an inventory of what is going on. It is always good to ensure that you have the right tools in the right places to get you where you need to be.