Containers are commonly used in the application lifecycle, as they solve the “it works on my machine” problem by enabling an application to run reliably across different computing environments. Container security aims to protect containers from security breaches at every stage of the app development lifecycle.

This article discusses the concept of container security and its main challenges, as well as best practices for developing secure containerized applications.

What Is Container Security?

Container security is the continuous process of using security controls to protect containerized environments from security risks. Containerized environments include not just containers and the applications running in them, but also the underlying infrastructure like the container runtime, kernel and host operating system.

According to the 2021 CNCF Survey, 93% of organizations were already using containers in production or had plans to do so. Along with this trend, companies are shifting toward cloud-native architectures and needing to meet the demands for faster application delivery. This means integrating container security best practices throughout the DevOps lifecycle is critical for ensuring secure container applications and preventing severe security breaches and their consequences.

Container Security Challenges

Containers provide many advantages in speeding up application delivery, including portability between different platforms and allowing self-contained applications to execute processes in isolated environments while sharing the underlying kernel. But containers lack their own security capabilities; instead, containers are granted access to hardware via the host OS. A single container can also have multiple underlying container images, further introducing new attack surfaces that present some unique security challenges, some of which we discuss below.

Container Misconfigurations

A common pitfall when developing with containers is that some developers often have a “set and forget” mentality. and there might be default insecure configurations that they may not be aware of. Common security misconfigurations include:

• Exposed insecure ports that are not necessary for the application
• Leaked secrets and credentials, like passwords and authentication tokens
• Overly permissive container runtime privileges, such as running containers as root

Left unchecked before deployment, these misconfigurations can expose containers to a security breach or leave the door open to privilege escalation attacks.

Vulnerabilities in Container Infrastructure

A container infrastructure stack typically consists of application code, configurations, libraries and packages that are built into a container image running inside a container on the host operating system kernel via a container runtime.

Each stage in the container lifecycle can potentially introduce security vulnerabilities into the container infrastructure, increasing the attack surface that could be exploited during runtime. Vulnerabilities can also be inherited from external dependencies built into the container image, or even exist in the host and container runtime within the stack.

Container images can additionally inherit security vulnerabilities from open-source libraries and packages as part of the application, making them susceptible to attacks. Developers might build container images using base images from third-party container registries, which may unintentionally contain security vulnerabilities or may have been intentionally replaced with a compromised image by hackers.

Lastly, containers and hosts might contain vulnerabilities that could be exploitable via networks, hosts and endpoints when the container is running on the host operating system kernel. In particular, container escape vulnerabilities in the host kernel and container runtime could open the door to attack vectors leveraging local privilege escalation to exploit host vulnerabilities and perform network lateral movement, compromising your entire cloud infrastructure.

Visibility into Container Workloads

The primary challenge of container security is visibility into container workloads. As container workloads are highly dynamic and usually ephemeral, it can be difficult for security teams to monitor and track anomalies in container activity.

As container security issues can quickly propagate across containers and applications, it is critical to have visibility into runtime information on both containers and hosts so that protectors can identify and mitigate vulnerabilities in containerized environments.

Issues with Securing CI/CD Pipelines

Container security requires securing all phases of the CI/CD pipeline, from application code to the container workload and infrastructure. But developers typically apply security towards the end of an application lifecycle, often leaving little time for security testing as developers rush to meet tight application delivery timelines.

7 Best Practices for Container Security

Luckily, there are established ways to overcome the above challenges to optimize the security of your containerized environment and application lifecycle at every stage.

1. Secure Your Images

When developing containerized applications with base images from an external container registry, pull images from trusted sources and store them in a secure private registry to minimize the risk of tampering. Attackers can still compromise images in trusted registries, so make sure to verify image signatures via Notary or similar tools.

Also, image tags can be changed, resulting, for example, with several images having a “latest” tag at different points in time. Use fixed image tags that are immutable, such as the image digest, to ensure consistent automated builds and to prevent attacks leveraging tag mutability.

2. Manage Secrets Securely

Avoid storing secrets and credentials in code or configuration files including a Dockerfile. Otherwise, this sensitive data will be copied to containers and cached in intermediate container layers even when the container is removed. A common best practice in managing secrets securely is to use a dedicated secrets manager, such as Vault or AWS Secrets Manager, to store and manage secrets and credentials.

3. Restrict Container Privileges at Runtime

The principle of least privilege refers to granting only the minimum level of permissions that a user needs to perform a given task. This is a key aspect when it comes to security and applies to container security at runtime as well.

Containers typically run as a user with root privileges to allow various system operations within the container, like installing packages and read-write operations on system configuration files. But running containers with root privileges introduces a major security risk in that it enables attackers to leverage privilege escalation within the container if the container runtime is compromised.

This makes it critical to restrict container privileges at runtime to mitigate vulnerabilities in the host kernel and container runtime. You can achieve this by running containers in rootless mode, letting you run them as non-root users. Or, opt to restrict Linux kernel capabilities to those explicitly needed by dropping all default capabilities and only adding those required for the container workload.

4. Identify and Remediate Security Misconfigurations

Identifying security misconfigurations when building container images enables you to remediate vulnerabilities before deploying containerized applications into production. This process involves checking configuration parameters via static configuration analysis, something that can be tedious and prone to human error if done manually.

Cloud security tools such as CrowdStrike Falcon Horizon™ cloud security posture management (CSPM) simplifies the management of security configurations by comparing configurations to benchmarks and providing guided remediation that lets developers mitigate security risks from any misconfigurations found.

5. Automate Vulnerability Scanning and Management

Automating vulnerability scanning and management in the CI/CD pipeline lets you detect security vulnerabilities at each stage in the container lifecycle and mitigate security risks before they occur.

Code scanning involves analyzing the application code for security vulnerabilities and coding bugs. Static application security testing (SAST) detects vulnerabilities in the application code. Software composition analysis (SCA), meanwhile, provides visibility into open-source components in the application build by generating a software bill of materials (SBOM) and cross-referencing components against databases of known open-source vulnerabilities.

Image scanning involves analyzing the contents and build process of container images for vulnerabilities. You can do this via static analysis tools, such as Clair, that scan each layer for known security vulnerabilities. Or use dynamic analysis tools like CrowdStrike Container Security, which detects security risks by tracing the behavior of a running container.

Last but not least, host scanning involves inspecting the container host components, including the host kernel and OS, for runtime vulnerabilities and misconfigurations. For this, developers use dynamic application security testing (DAST), a black-box test that detects vulnerabilities through simulated attacks on the containerized application.

6. Set Up Real-Time Logging, Monitoring and Alerting

Enhancing visibility into container workloads requires the use of observability tools that enable real-time event logging, monitoring, and testing for vulnerabilities in each component of the containerized environment. You can detect container security threats by auditing logs and metrics from different sources in the container stack, as well as analyzing the container details and activity for anomalous behavior in the system.

Setting up real-time logging, monitoring, and alerting provides you with visibility, continuous threat detection, and continuous compliance monitoring to ensure that vulnerabilities and misconfigurations are rectified as soon as they are identified.

7. Adopt “Shift Left” Security

Rather than adopting a “shift right” approach that treats the security of CI/CD pipelines as an afterthought, you can adopt a more proactive approach by shifting security to the left.

“Shift left” security refers to the practice of shifting security to the earliest phases in the application development lifecycle. It lets developers deliver secure container applications without slowing down the application development process since teams have time to identify and resolve issues or vulnerabilities as early as possible. Integrating vulnerability scanning into each stage of the CI/CD pipeline results in fewer production issues and enables DevOps and security to work in parallel, speeding up application delivery without compromising on container security.

Conclusion

Implementing container security best practices involves securing every stage of the container lifecycle, starting from the application code and extending beyond the container runtime. As container security is a continuous process and security threats evolve over time, you can gradually implement some of these practices by integrating CrowdStrike’s container security products and services.