Anyone involved with modern software development and operations is probably familiar with containers. Systems like Docker and Kubernetes make it easy for DevOps teams to deploy containers in testing and production environments, where they can benefit from the speed and low system footprint of this virtualization technology to run important apps.
While containers might feel like a somewhat esoteric concept to security professionals and leaders, it’s important to understand them and the risks they present. This article offers a primer on container security so that you’ll better understand what containers are, what security risks they face, and some best practices that are worth adding to your organization’s security policies and processes.
A container provides a virtual runtime environment that contains all the code and dependencies required to run a specific application. By isolating an app from the host machine that it runs on, you can, as per Docker’s original marketing messaging, “build once and run anywhere.” To run a container, you use a container image, which is a static executable file that comes prepackaged with everything needed to run a piece of software.
The beauty of this is that containers are incredibly portable, which removes the conflict that often arises when apps behave differently in various testing and production environments. Furthermore, you don’t have to worry about dependency issues, so you can easily run multiple apps on the same machine.
Aside from their portability, containers are smaller and run faster than traditional virtual machines. The adoption of containers surged in 2013 when Docker arrived on the scene, making it easier to run containers, although they were often restricted to testing environments. Container deployment in live production environments has grown over the years, though—one survey from 2021 of mid to large enterprises found that 50 percent of the applications they run are now containerized.
Secure Container Registries
To mitigate supply chain risks, it’s imperative to use a secure and trusted container registry when automatically pulling or manually downloading container images. While public registries are convenient, you can never be certain that the image you’re pulling is not tampered with or that it doesn’t contain a vulnerability.
Deploying a registry that sits behind your own firewall is a more secure way to store container images. To add another layer of security on top of a private registry, use role-based access control to define and restrict exactly who among your team members and collaborators can upload and download container images. Open access to everyone unnecessarily increases the attack surface.
If a container image must be sourced from a public repository, scan and verify it before use. Digitally signed containers add a layer of authenticity, and it’s worth requiring a digital signature from publicly sourced container images to further verify trust.
Scan for Code Vulnerabilities
Since containers run software that’s usually composed of proprietary code and third-party components, you need to scan for code vulnerabilities as a security best practice. If you can be confident that the code within a container is secure, you mitigate an important source of security risk.
Scanning for code vulnerabilities in containers should include the use of a variety of tools, ideally ones that automate the process as much as possible. Consider the following as a bare minimum toolkit for finding vulnerabilities:
Apply Least Privilege Principles
The principle of least privileges is worth embedding as a fundamental security practice when using container technology. Limiting a container or user’s access to only the bare minimum required for their particular function or job role helps to reduce the attack surface and limit the potential damage from vulnerabilities and misconfigurations (such as running a container with privileged/admin permissions).
Applying least privileges must also extend to the resources granted to containers on the underlying host system. If a container becomes compromised, hackers can try to piggyback off host resources to further their malicious activities. Change any defaults and enforce resource quotas in line with the maximum resources (RAM, CPU, etc.) that a container needs to use on the host system.
Adopt Threat Detection and Response
Strengthening container security must also address the potential for threats that bypass other security defenses and practices. Real-time threat detection and appropriate response playbooks are crucial in production environments, where cyberattacks can lead to sensitive database compromises or mission-critical apps being taken down.
Aim to scrutinize container activity so that you get granular insights into anomalies and you have time to remediate in-progress threats before they become breaches. Detection should cover the host systems that containers run on, the container’s workload (the particular tasks it performs) and the container engine you use (e.g., Docker or Kubernetes).
Various container security tools are available to assist with threat detection. It’s also important to have access to skilled personnel who understand detection and response for container ecosystems.