How do you keep containers secure? That’s a big question, especially given how many distinct components you have to secure in a containerized environment.
But it’s a question that has clear answers. Keep reading for a primer on security best practices for every component involved in your container infrastructure.
Container Host Environment
Container security starts with securing the environment that hosts your containers. That environment can take three different forms.
On-premises Container Environments
The first is on-premises environments, where you set up and manage your own host servers and operating system for your containers. Here, you can enhance security in two main ways:
- Minimize potential attack vectors by keeping your environment’s footprint as small as possible. If you don’t absolutely need to run a service or install a package, then don’t.
- Enforce strong access control. You also want to use your operating system’s access control framework to enable the lowest level of privileges necessary for your users.
Traditional Cloud-based Container Security
If you run your containers in a standard cloud-based environment using a service such as AWS ECS, you typically have less ability to fine-tune the host environment in a way that maximizes security than you do if you run everything yourself on-premises. But that doesn’t mean that you can offload security solely to the cloud provider. There are additional steps you can take to secure the host environment, including:
- Enforce cloud access control by using whichever access-control framework your cloud vendor provides you.
- If the cloud vendor gives you a choice about which operating system to install in the virtual servers that host your containers, choose one that is as minimalist as possible, to reduce the size of potential attack vectors.
- Use a cloud-aware firewall to filter traffic and minimize the exposure of services within your cloud host environment to the public internet.
Fully Managed Containers in the Cloud
Over the past year or so, another type of cloud-based container strategy has become popular. It involves using fully managed container services, such as AWS Fargate. For many users, this approach provides the fastest way to get up and running with containers, but it also minimizes the amount of customization that you can perform at the level of the host environment to secure your containers. You can, however, ensure that you follow the principle of least privilege when using the fully managed container service.
Container orchestrators such as Kubernetes help you to manage containers, but they are not designed to secure them. And they themselves can pose a security risk if you don’t take steps to secure them by:
- Making sure you install your orchestrator from an official, trusted source.
- Keep the orchestrator up-to-date.
If you run containers in the cloud, there is less that you can do here, because your cloud provider most likely handles the installation and configuration of your orchestrator.
A container runtime is the process responsible for executing containers on the nodes that host your environment. It’s one of the most critical parts of your containerized software stack. It is also one that is difficult to secure using conventional security monitoring tools, which in most cases will treat the container runtime as a regular process and fail to understand the special security challenges related to container runtimes.
However, you can take steps to keep the runtime secure, including:
- Establish dynamic baselines, rather than relying on fixed, static ones. Dynamic baselines allow you to identify anomalies that could signal security breaches, even in environments that are constantly changing and have no constant “normal.”
- Embrace an immutable infrastructure strategy, which means destroying and replacing containers rather than applying updates to running containers. Containers make it easy to create an immutable infrastructure architecture, so you don’t want to overlook this important container security advantage.
- Write secure application code to run inside your containers. You should always be writing secure application code in any type of scenario, of course, but it’s worth emphasizing this point, given the minimal level of isolation between different containers and the ease with which a small security breach in one containerized service can morph into a major breach that stretches across your infrastructure.
There are a plethora of container registries now available. All of the mainstream options are designed to be secure. But here again, you can take extra steps to make sure that your registry is even more secure:
- Install the registry from an official, trusted and up-to-date source—or, if it’s a hosted registry running in the cloud, make sure you trust the registry provider and that the provider has experience with containers.
- Make sure you keep registries private unless you want them to be public. (That may sound simple, but major companies have been known to make their registries public by accident.)
- Avoid poor practices such as using your container registry as a general-purpose artifact or code repository. Use it only to host container images.
- Keep the images inside your registry up-to-date. Although you may sometimes need to keep older versions of an image on hand, establish and enforce a policy for cycling out older images once they are no longer needed.
- Use a container registry scanner to detect known vulnerabilities within your images.
Last but not least are container images themselves, which contain the code that powers your actual application (or a part of your application). Best practices for container image security include:
- Minimize the amount of code inside each image. If it’s not essential, don’t include it. For example, resist the temptation to run an SSH server inside the image so that you can connect to it via SSH. Use the Docker shell to log in instead—it’s much more secure.
- Be sure to configure user and file permissions properly within the container, and follow the principle of least privilege when doing so.
- If you use a parent image, make sure it’s secure and up-to-date. This can sometimes be challenging because Docker makes it so easy to include a parent image without verifying its security. That flexibility and simplicity is part of what makes Docker so powerful, but it can be a security risk when used irresponsibly.
Container security starts with understanding your specific infrastructure and pipeline landscape and working to secure every component appropriately. This guide should get you started on your container security journey and help you to answer some of the big picture questions around how to get started.