What is Container Security and Why Do You Need It?

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.

So, What Exactly Are Containers?

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.

Container Security Threats

• Code vulnerabilities—Since the life cycle of containers ultimately starts with the code that a developer writes, containers are subject to similar code vulnerability risks as any other application. These vulnerabilities include the third-party dependencies (libraries, frameworks) that a specific app might rely on. For example, any container images with dependencies on Log4j became vulnerable after the discovery of a zero-day bug in late 2021.
• Misconfigurations—Container infrastructure requires a lot of tweaking, which introduces similar misconfiguration risks to cloud environments. For example, when building a container image, containers run as a root (admin user) by default, which gives the container excessive permissions and privileges. If the person building the image doesn’t change this setting, the container has root access to the host system and a potential compromise could spell trouble.
• Supply chain attacks—Many organizations use pre-built container images from public registries. Threat actors can use tactics such as misspelling the names of common images and inserting their own malicious code into those images. The developer pulls the malicious image and unknowingly inserts malicious code into their environment.

Best Practices for Container Security

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:

• Static Application Security Testing (SAST) tools that find code flaws and weaknesses in your proprietary code.
• Dynamic Application Security Testing (DAST) tools that find vulnerabilities only emerging when you actually run an application.
• Software Composition Analysis (SCA) tools that identify all third-party components in an app and flag any vulnerabilities in those components.

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.