Container Image Security: Best Practices

Container images envelop the code in all states of the application development.

20:25 05 August 2021

 

Many modern businesses appreciate the importance of integrating security in the development process to secure applications. For containerized workloads, protecting the container image throughout the lifespan of the app is important for security. 

 

However, most organizations rarely follow the basic practices for guaranteeing the security of container images. As a unit of execution in applications, container images envelop the code in all states of the application development. 

 

As a result, it is easier for organizations to reduce security risks in production by securing the container image early in the life cycle. It is not to say that organizations can ignore security practices later on. 

 

Since it is difficult to see inside containers, attacks may capitalize on vulnerabilities that you are yet to identify or never anticipated. Container image security demands constant vigilance and adaptable processes. 

 

Read on to find out the best practices for securing container images. 

 

Container image security practices

Below are some of the best practices for ensuring the security of container images through the life cycle of an application. They are the foundations of strong security. 

 

Incorporate image scanning at every stage

Image scanning is not something you can do once and be done with it. Instead, you should include Docker image security scanning whenever possible during the application life cycle. 

 

You should include image scanning when the image is being built, when it is in your repo, and continuously when running. Scanning images in the registry and at runtime enhances protection. 

 

Also, you can control image execution via policies that block images with severe common vulnerability exposure (CVE). It depends on the sensitivity of the environment the image will be running in. 

 

Avoid using root users

With Docker, you can run containers on privileged mode. Even though bypassing some security protocols can be faster, you should refrain from using this approach. 

 

It increases the risk of opening the door for malicious activity. In Docker, a privileged user has the same properties as the root. So, a malicious user can enter the system via the container endangering everything. 

 

So, it is advisable to stick with non-root users since it is simple and is the default setting in Docker. 

 

Setup resource quotas

One way of protecting your application from compromised containers is to set memory and CPU usage limits. If you fail to configure resource quotas, you let the container have full access to the host’s CPU and RAM resources. 

 

Since it is not set by default, it is recommended that you limit the amount of resources a container can use. Doing so ensures the container does not interfere with other services.

 

What’s more, it prevents the container from using all the resources and helps ensure that the Docker environment is efficient. Besides enhancing security, setting resource quotas ensures containers run at the expected speed. 

 

Update host and Docker regularly 

It is important to make sure Docker and your host are always up to date. Embrace the latest operating system release and containerization software as a way of preventing security vulnerabilities. With each update, you get critical security patches that are important for protecting data and the host. 

 

Since running containers do not update automatically, you need to update them and their images. 

 

Scan OS and non-OS packages

One misconception about container image security is that you only need to scan operating system packages. Everything in the container be it OS or non-OS, open-source or commercial should be scanned. 

 

Vulnerability can be in both OS and non-OS packages. Usually, non-OS packages tend to have very severe vulnerabilities. 

 

Keep images as lean as possible 

For security reasons, it is better to have smaller images. When the image surface layer is smaller, it leaves few opportunities to exploit the image. From a security perspective, the ideal situations are when images run a single process. However, that is rarely the case but it should be your goal. 

 

As a developer, you should work on removing anything in images that are not necessary. Whenever possible, use static links and avoid too many dynamic libraries. The aim is to decrease the attack surface without compromising the operations of the container. 

 

Restrict system calls from containers

You can allow or deny system calls from within containers. To run a container, not all system calls are necessary. So, you can monitor containers to get a list of all their system calls. This makes it easy to explicitly allow those calls. 

 

So, it is essential to base the configuration on your observation of the container at runtime. It lets you know the specific system calls made by your container components. 

 

Use multi-stage builds

The use of multi-stage builds is common for building containerized applications. The approach has security and operational advantages - and will include creating an intermediate container that holds all the tools required to compile the final artifact. 

 

A well-executed multi-stage build contains minimal dependencies and binary files for the final image. As such, it considerably decreases the attack surface. 

 

Also, the approach offers you extra control over the files that go into the container image. It makes it harder for insiders or attackers to include malicious artifacts without authorization. 

 

Monitor container activity 

Monitoring is important for both security and the smooth operation of containers. Monitoring is essential to understanding what is taking place in your containerized environment, detecting anomalies and dealing with them. 

 

Each container image has multiple running instances. Because of the rate at which new images and versions are deployed, it is easy for issues to affect various containers. Thus, it is important to establish issues early and handle them at the source. 

 

By establishing a faulty image, you can fix, and rebuild all the containers that use that image. As well, you can have practices and tools in place that assist you in monitoring various components of a container. 

 

Conclusion

In containerized applications, secure container images are necessary but not sufficient for a strong security posture. If the container image is not secure enough, other security measures will not be able to keep malicious actors at bay.