Container Image Registry Security Best Practices
Twistlock sponsored this post.
If your organization is making the move from monolithic applications to container-based microservices, there are, needless to say, more than enough major issues to keep you and your team busy — from overall architecture through the details of deployment.
One detail that can be easy to overlook during this process is container registry security. While you might devote some effort to securing your containers, have you thought about how you will keep the registries secure? If not, this article is for you. Keep reading for container registry security best practices.
What Is a Container Registry?
You don’t store containers for deployment — you store container images, and you generate containers from those images as needed. Each container is an instance of the image. Individual containers may come and go, and they may change under some circumstances, but the container image is like a template that remains in storage and does not change.
The repository in which container images are stored is typically referred to as a registry. There are several public registries, some of which include a very large number of images. Like other major repositories of open source code, these registries are indispensable resources, providing access to important software packages, utilities, and services in the form of ready-made container images.
Scanning and Auditing Container Registries
If a container image includes a vulnerability, then every container generated using the image will also include that vulnerability. While container images are designed to be immutable, container registries aren’t. Developers may upload new containers and new versions of existing containers frequently. Every change carries with it the possibility of introducing a new vulnerability — and all too often, an old vulnerability resulting from the use of an outdated software package.
Scanning…
You need to schedule regular scans of your repository in order to detect such vulnerabilities. Most of the organizations that maintain major public registries (such as Docker) provide their own scanning services. For private registries, security providers such as Twistlock offer extended scanning capabilities, with key features such as scanning-results alerts, and automatically preventing images that are not trusted from being used.
…And More
You can (and should) go beyond scanning for vulnerabilities by auditing images for age, as well as outdated packages. You can flag older images and those with older dependencies as outdated and schedule them for updating. Adopting a policy of regularly updating and refreshing older images makes it easier to eliminate vulnerabilities which may have gone undetected.
Build With Care
Containers are not black boxes. What happens inside a container can have an impact on security, and how you make it happen can have an even greater impact.
Build from Source
It may be tempting to simply clone containers with standard open source packages from trusted public registries and place them in a private registry, or to use the images in the public registry. It is a better practice, however, to build the images in your private registry from source, since this gives you greater control over the image and the conditions affecting its security. It is harder for a vulnerability or an exploit to slip into the container unnoticed when you are in control of the build process.
Limit Resources
A container is designed to operate within a very limited domain; it provides a service consisting of a task or a set of tasks, and the only resources that it needs are those required to perform those tasks, to interact with the host OS, and to communicate with other containers. If a container does not need to include a given resource, it shouldn’t include that resource.
This isn’t just a matter of keeping your containers light on their feet. Every resource, every software package — and for that matter, every line of code that you include — is a potential attack surface. Attackers targeting bare metal or VMs can assume a high probability that a standard set of system resources will be available since the target system will typically include at least a basic version of a full OS.
This does not need to be (and shouldn’t be) the case with containers. Ideally, any attack should fail due to a lack of necessary resources in the containers being accessed, rather than hopping from one container to the next and finding the same set of target resources in all of them.
Limit User Privileges
User privileges within a container should always be limited to those necessary to perform the required tasks. Intruders should not be given any chance to escalate privileges or break out of the container. This means, among other things, routinely checking the default user privileges of any packages that you include in your containers, and any open source container images that you include in your registry.
It also means that when you design containers for your microservices, you should keep close track of the privileges that they actually need. When you access a database, for example, only those containers that read from or write to the database need the privileges required for those tasks. Containers which make use of the data after it has been retrieved should not have read/write access to the database.
Needless to say, you should never allow users root access within a container. If you need to allow root access to perform a task, go back and look at your design. Redesign it without root access if at all possible.
Monitor
Containers are like any other kind of software — for full security, you need to monitor them while they are running. Container security services such as those offered by Twistlock make it easy to do this. A good monitoring service should be able to automatically detect the kinds of anomalous behavior patterns, which can indicate a compromised container or a break-in attempt, and issue alerts when such anomalies are detected.
Any list of recommended best practices is necessarily general, of course. No such list is foolproof, and as always, you will need to adapt these recommendations to the requirements of your software and the circumstances under which it operates. Some of them may be extremely relevant to your operations, and others may not apply at all. By using this list as a starting point, however, you stand a good chance of avoiding the most common security hazards of container deployment.
Feature image via Pixabay.