What Is Container Security?

The large scale at which organizations have adopted containers, combined with the fact that containers work differently than other types of technology, mean that container security must be a central component of overall cybersecurity strategy for the typical organization. The protections that are effective in securing non-containerized applications don’t always work for containers, making container security a unique discipline.

Keep reading for a deep dive into what container security means, how to address it across all stages of the software development lifecycle, and which types of tools can help protect containers against security risks today.

In this article:

• What is container security?
• Understanding the container security architecture
• Threats and challenges of container security
• Securing popular container platforms
• Securing containers across the SDLC
• Best practices for container security in DevSecOps
• Securing containers with Aqua

What is container security?

Container security is the practice of securing containerized applications and infrastructure against security risks. The goal of container security is to detect, assess, and remediate misconfigurations, software vulnerabilities, and other issues that threat actors could exploit to take control of containers themselves or the systems on which they run.

Container security is similar to application security in general. It includes some of the same practices, such as scanning for vulnerabilities. However, containers work differently in many respects from non-containerized applications:

• Application architecture: Containers are often used to host microservices applications, which are more complex than their monolithic counterparts.
• Deployment architecture: Containers are often deployed across a cluster of servers, rather than residing on just one server.
• More layers: Containers often depend on the deployment of complementary tools and services, such as orchestrators, that don’t exist in traditional application deployments.
• Development processes: Containers are often developed and deployed using a different set of processes and procedures. For example, an immutable infrastructure approach is common with containers but not traditional apps.

Because of these differences between containerized and non-containerized apps, container security is a discipline unto itself. You can’t simply deploy the same tools and practices that you use to defend traditional apps and expect them to secure containers as well – you need a dedicated set of container security solutions.

Understanding the container security architecture

The fact that containers are more complex than traditional apps, and that the container architecture includes more components, means that container security is a multi-faceted practice. It requires securing a range of resources, including:

• Container images, which are the binary files used to create running containers. Images could contain vulnerable code or settings that attackers could exploit.
• Container repositories, which host container images. If attackers breach repositories, they could inject malicious code into images.
• Container runtimes, which execute container images into running containers. Flaws in these runtimes could allow attackers to take control of containers.
• Container hosts, meaning the servers on which containers reside. Security vulnerabilities and misconfigurations at the server level could also lead to breaches.
• Orchestrators, which manage containers deployed across a cluster of servers. Here, too, misconfigurations or lack of effective access controls could enable malicious activity.

So, when we talk about container security, we’re not talking about just one type of practice. We’re referring to a broad set of practices that, when used together, help provide end-to-end protection for containerized applications.

Threats and challenges of container security

Beyond the fact that containerized application deployments involve more layers and moving parts, containers are subject to certain other threats and challenges that don’t apply to most traditional applications. One is the sheer size of the container attack surface. As noted above, it’s not uncommon for an organization to deploy thousands of individual containers. A security flaw in any one of them could lead to a breach.

The fast-changing nature of container environments is also a challenge. Typically, developers deploy new containers on a frequent basis as a way of updating applications – sometimes as often as multiple times per week. With such a rapid pace of change, it’s easy for mistakes to slip through that open the door to breaches.

The use of third-party resources within containers can present a security challenge, too. Container images for an application that a company deploys are often based on other images borrowed from open source repositories. Plus, containers sometimes include commands that install libraries or other dependencies when the containers start. If any of this third-party software is insecure, it could lead to security risks inside containers, making it critical to secure the software supply chain in addition to containers themselves.

Securing popular container platforms

There are too many container platforms to make it feasible to provide guidance here on how to secure each one. But let’s take a look at security basics for four popular container platforms.

Docker

Docker is a platform for building and running containers that includes an optional orchestrator, called Swarm. (If you don’t use Swarm, you can use a different orchestrator to run Docker containers.) To secure Docker, your key focus should be on securing container images by avoiding insecure base images and dependencies. You should also avoid insecure configuration settings, like containers that run with root privileges. Protecting the Docker runtime by ensuring it’s up-to-date is important, too, as is securing hosts that run Docker containers.

Kubernetes

To secure Kubernetes environments, you must first ensure that the containers you deploy using Kubernetes are free of vulnerabilities and misconfigurations. In addition, consider using the Kubernetes Role-Based Access Control (RBAC) framework to manage access permissions for your containers. Kubernetes also provides an audit logging feature that tracks access requests to the Kubernetes API and can be useful for detecting anomalous activity associated with attacks.

OpenShift

Most of the security principles that apply to Kubernetes also apply to OpenShift, which is developed by Red Hat and based on Kubernetes. Additional security controls may be available through Red Hat Enterprise Linux or Atomic Host, the operating systems that OpenShift supports, these additional layers of security provide organizations with more robust protection for their containerized environments.

Tanzu

Tanzu, which is developed by VMware (now part of Broadcom), is also an application deployment platform based on Kubernetes, and most of the security principles that apply to Kubernetes also apply to Tanzu. However, Tanzu also provides some additional security tools and features, such as those that help integrate Tanzu with other VMware/Broadcom products.

Securing containers across the SDLC

Implementing container security requires deploying a variety of protections across various stages of the Software Development Lifecycle (SDLC). Here’s a look at what container security entails during each major phase of the SDLC.

Development phase

During development – meaning the part of the SDLC where developers write code that they will turn into container images and deploy using containers, teams can maximize container security through:

• Secure coding practices: These help to minimize the risk of introducing security flaws and vulnerabilities into source code.
• Using trusted base images: Use base images (meaning the image that developers use to create new, custom images) from a legitimate source to avoid malicious code inside the images.
• CI/CD pipeline security: Lock down access to CI/CD tools to prevent attackers from injecting malicious code.
• Image scanning: Scan images prior and during the deployment to detect vulnerabilities.
• Static and Dynamic Application Security Testing: These types of tests can also uncover vulnerabilities in applications prior to deployment.
• Software Composition Analysis: Use SCA to detect insecure dependencies and other software supply chain risks.
• Implementing digital signatures: Signatures provide unique identifiers for tracking container images and ensuring that the image users download is from a legitimate source.
• Image hardening: Harden images against attack through practices like removing unnecessary components, which reduces the attack surface.
• Secrets management: Ensure that passwords, API keys, and other secrets that containers need to access are managed securely during the development process. For example, don’t embed secrets in plain text, where attackers who manage to access development environments could read them.

Deployment phase

During deployment – meaning the process by which containers are moved from development into a production environment or infrastructure – the following practices can help protect against risks:

• Host security: Deploy containers to a host that is up-to-date and that does not include unnecessary libraries, services, or other resources. In addition, consider hardening the host with a framework like SELinux, which helps reduce the risk of vulnerability exploitation. This helps prevent container escape, which occurs when code running inside containers accesses resources outside the container.
• Role-Based Access Control: The RBAC systems available from orchestrators can restrict which types of resources each container can access, as well as the types of requests containers can make.
• Orchestration security: More generally, ensure your orchestrator is up-to-date and configured to minimize unnecessary access.
• Secrets management: To avoid exposing sensitive secrets during the deployment process, use secrets management tools like those built into Kubernetes.

Runtime phase

After deployment, you need to secure the runtime environment in which containers operate. The following practices can help:

• Monitoring and logging: By tracking metrics and analyzing logs, you can identify anomalies that could be a sign of an attack.
• Container isolation: Using namespaces, isolate containers from each other to prevent interactions that could help attacks to escalate.
• Network security: Prevent unnecessary access to containers over the network, and monitor network traffic for anomalous activity.
• Automated patch management: To reduce the risk of vulnerability exploitation, automatically patch vulnerable software components as soon as patches become available.
• Incident investigation: Consistently and systematically investigate incidents using forensics, and formulate response plans that allow you to remediate container security risks quickly.
• Malware protection: Scan for malware that may lurk inside containers, as well as on host systems.
• Container compliance: Ensure that containers comply with any compliance mandates your business must need, and that you collect the data (such as access logs) necessary to demonstrate compliance.
• Secrets management: As with the deployment phase, avoid storing secrets in plain text; instead,  use dedicated secrets management tools and features.

Best practices for container security in DevSecOps

In addition to taking steps to secure containers across the SDLC, the following best practices can help reduce the risk of introducing security risks into containers. (For more guidance, visit our article on container security best practices.)

Regularly scan and update base images

Because new security vulnerabilities appear on a regular basis, scanning base images once is not sufficient to detect all potential risks. You should scan them regularly to uncover vulnerabilities that were disclosed since your initial scan. In addition, updating to newer versions of base images whenever they become available is important for ensuring that the images remain patched against the latest threats.

Use read-only containers

In some cases, containers can be deployed with read-only file systems, preventing attackers from injecting malware into them. Read-only mode is not always feasible because some containers need to make changes, like installing software, during the course of their operations. But when read-only is an option, enable it to improve container security.

Limit container resource usage

Using features like Kubernetes resource limits, restrict how many resources containers can consume. Doing so won’t prevent attack, but it will help contain or reduce the speed of attacks by preventing malicious processes (like cryptominers) from consuming unlimited volumes of resources.

Enforce network segmentation

Network segmentation prevents containers from communicating with each other unless they have a reason to do so. In this way, it reduces the risk that a breach of one container will spread to others. You can enforce network segmentation using firewalls, service meshes, or through orchestrator features like Network Policies in Kubernetes.

Perform regular auditing and compliance checks

Routinely scanning container images, orchestrator configurations, and other resources helps to identify not just vulnerabilities, but also deviations from best practices. By looking for these issues proactively, you can correct them before attackers exploit them.

Security tools for container security in DevSecOps

Because container security is a multi-faceted process, it requires multiple types of container security tools and solutions, including:

• Container image scanners: These can scan container images both for vulnerabilities and for insecure configuration settings.
• Runtime security tools: By monitoring running containers and their host environments, container runtime security tools can detect anomalous behavior in live containers.
• Kubernetes security tools: The complexity of Kubernetes requires security solutions purpose-built to ensure that Kubernetes configurations are secure, as well as to detect anomalous requests within Kubernetes environments.
• Secrets management tools: Secrets managers store secrets in a secure, encrypted location and make them available as needed, reducing the risk of accidentally exposing secrets to unauthorized parties.
• CI/CD security tools: Solutions that help to secure the CI/CD pipeline reduce the risk of allowing attackers to inject malicious code into containers or container images by comprising development environments. 

Securing containers with Aqua

As an application security platform built from the start to protect containers and other cloud-native workloads, Aqua provides the complete set of container vulnerability scanning, configuration scanning, runtime security, and risk remediation capabilities that organizations need to keep their containers secure. Whether you’re deploying just a few containers or tens of thousands, count on Aqua to keep them safe.

Learn more about how Aqua manages security risks in containers and beyond.