Using containerisation

Manage the supply chain of any base images you use.

• Only use base images from sources you trust
• Verify the origin, authenticity, and integrity of base images
• Use base images that only include the tools used by your application
• Assess not just the base images you use directly, but also transitive base images

Container images are often built on top of other container images. This makes it easier to manage common dependencies, such as programming language runtimes, cryptographic tools, and system data. While base images bring considerable value, they can also be a significant source of vulnerable software.

The ideal base image will contain the tools necessary for the application and no more. While large general-purpose base images are convenient for prototyping, they present a considerably larger attack surface than more specialised images. Applications with no external dependencies may even be able to use an empty base image, or to use no base image.

Many base images are built on other base images, also known as transitive base images. You should ensure that you apply your security controls to all base images you use, whether you use them directly or transitively.

Each container image should only include one application and its dependencies.

• Identify the application’s runtime dependencies and exclude other contents
• Use tooling to help identify unnecessary contents that can be removed
• Ensure your image building tools minimise the image’s contents
• Check that your container images do not include hidden contents
• Do not store credentials in container images

Unlike a virtual machine, a running container can be debugged and analysed using tools not present in the container. For example, you can attach an extra container to a running container to make additional debugging tools available. This makes it possible to have much smaller containers without compromising on usability. Removing unnecessary contents from a container image reduces the attack surface, reduces the likelihood that known vulnerable software will be present, leaves fewer tools available to a successful attacker, and makes the image easier to analyse and understand.

For example, containers should not normally need remote management tools like SSH or RDP, as container management is typically performed using container-specific tooling that exists outside the container. Similarly, containers should not need system package management tools, as the container is not expected to change its contents at runtime.

You should consider how you can use your container image building tools to minimise the contents of the resulting container images. For example, it may be possible to use one base image to build the application and another to build the final image. This would allow the use of package managers and compilers during the build process, without those being present in the final container image.

The ideal is to build container images that consist of a single executable binary (which might be an interpreter like CPython or a virtual machine like the JVM) and a few data files, such as a time zone database or the trust pool of root TLS certificates. While this will not always be possible, you should be confident that no files in the container image are unnecessary.

Some container image building tools can remove contents from a base image when producing another image. This may only prevent those files from being visible when the container runs, while still including the files in the container image. You should be sure that any files removed during the image building process are entirely removed from the final container image. Alternatively, use a smaller base image so that there is no need to remove anything. It is particularly important to ensure that any temporary secrets used duing the image building process are not stored in the resulting container image.

Container images are easy to analyse and might be stored in untrusted locations. As a result, you should not store credentials or other secrets in container images. The container orchestrators and cloud platforms typically used to run containers have built-in identity and credentials management functionality, which should be used to access credentials at runtime instead.

Container images should be configured to make make compromise difficult at runtime.

• Configure images to run as a low-privilege user
• Configure standard security features for the operating system you use
• Configure images to have no access to the host operating system
• Configure images to apply network access controls, if possible

As with any application, containers need to harden the system configuration to help defend against attack.

While most hardening is applied at runtime, some security features can be configured in the container image. This means that those security features will be enabled by default when the container runs. The security features available to you will vary, depending on the container ecosystem you use. For example, some will focus on the execution environment of the container, while others will also include wider considerations like network access control.

You should identify the security features available to you and select those appropriate for your use case. Make sure that the security features you choose do not interfere with the correct behaviour of the application.

Security updates should be applied promptly and consistently to all software in your containers. Typically, this is achieved by building a new container image with the updated software, rather than updating existing containers in place.

Applying prompt security updates is one of the most universal tasks in computer security. Unlike traditional applications, containers cannot normally be updated in place. To apply updates to a container, an updated container image is built and then used to replace the previous container. Since containers are updated in a different way from traditional deployments, it’s important to check that your approach is working in practice.

Tools that build container images often use caching to accelerate the build process. However, this can result in a failure to apply security updates when rebuilding a container image. You should ensure that any build caching does not prevent security updates from being applied.

You should use automated scanning to detect malware, known vulnerabilities, and misconfiguration in the container images you use.

• Check for malware and known vulnerabilities in third-party images, including base images
• Check images for software with known vulnerabilities
• Check that images are configured securely
• Check that the software in images is up to date
• Check that images do not contain any credentials
• Scan each image throughout its lifecycle
• Scan by analysing container images, not by including antivirus in your containers
• Prepare incident response plans for how you would respond to serious vulnerabilities in your containers

Container images are designed to be easy to analyse, which makes container image scanning much easier and more widely used than with traditional equivalents, such as virtual machine disk images. You should ensure that all container images you use are scanned throughout their lifecycle. This should include both prior to deployment and while the image is still in use. This allows you to identify issues before they manifest, while also alerting you when corrective action needs to be taken on an image already in use.

Your approach to container image scanning should take into account your wider approach to container security. For example, if you invest in your container image supply chain and minimise image contents, then scanning container images for malware will bring little benefit. Alternatively, if you choose to accept more risk in your supply chain, scanning for malware will become more important. If you have a secure development and deployment process and build all your own software, then image scanning is unlikely to provide significant benefit, but can provide defence in depth. Note that your vulnerability scans should work by analysing the contents of a static container image, not by including traditional antivirus software in the container. In other words, you should never need to run the container to scan it for vulnerabilities.

You should use automated scans to confirm that you are minimising image contents, applying security updates effectively, and hardening the image configuration, as described in the previous sections. This will help to give confidence that your processes are working as expected.

You should maintain an audit trail of the container images you use.

• Set a retention period for your container images
• Keep a copy of each container image you use for that retention period
• Keep relevant metadata necessary to understand when and how images were used
• Prevent container images from being deleted from the audit data early

Container images are space-efficient in how they are stored and should be small in size, as described above. These two factors mean that it should be possible to retain all used container images for a reasonable retention period after use, without incurring significant cost. Keeping this audit trail can provide valuable forensic data to support an incident response. You should ensure that you include any dynamic version information (such as image tags) in your audit records so that you can be certain which versions of each image were used.