Container Security: Build a Program That Meets Your Objectives
Learn how to get started on container security and the basic practices should be present in your container security program.
Securing container environments is far from straightforward. Given their complexity and pace of change, it’s hardly surprising that we consistently see major organizations falling prey to basic exploits. And it’s not that organizations don’t understand the importance of vulnerability management or system hardening—there are simply so many opportunities for vulnerabilities and misconfigurations to creep in.
In this article, we’ll cover the basics of container security—establishing objectives, its main phases, and ways to abstract it. For a more in-depth read, be sure to download our guide on building secure and compliant containers.
Getting Started: Establishing Objectives
Security is undoubtedly a priority for any organization that relies on containers. The first step is to establish objectives for the container security program, which will typically include:
Protect business continuity
Protect the organization’s reputation
Protect against threats and quickly identify incidents
Do all of the above while protecting developer productivity and maintaining the inherent benefits of containers—resilience, scalability, speed, and automation
Naturally, these objectives present the same challenge always faced by security initiatives. You can’t implement every security control, tool, and system possible, because the financial and operational costs would be too high. Instead, each organization must assess the risk associated with containers and design and implement security controls that:
Reduce risk to within acceptable tolerances.
Satisfy all regulatory compliance requirements.
Demonstrate a commitment to security sufficient to meet customer and partner demands.
Stay within an acceptable cost range while protecting against operational disruption.
As a cloud-first organization, you need a flexible, iterative, and cost effective approach to protect your container environment, meet compliance objectives, and maximize performance.
Four Phases of Container Security
When it comes to security, it helps to be more process-oriented. We recommend you start by looking at the four phases of container security:
Development: producing and maintaining secure images.
Infrastructure: hardening the container environment to minimize attack surface.
Application: enforcing network policies and access controls.
Monitoring: tracking activity, preventing threats, and responding promptly to incidents.
Development and the Role of DevSecOps
For many years, development teams have been incrementally accepting responsibility for application security. That’s always been a good thing—but in a container environment, it’s unavoidable. As we’ve already seen, a container environment can harbor many potential weaknesses. If security isn’t considered from the start, it’s easy for small mistakes to lead to gaping holes for attackers to exploit.
A secure container environment requires constant collaboration between development, operations, and security teams. Individuals with a full technical grasp of the container lifecycle—from early development and infrastructure setup through to configuration, hardening, and security—are rare, making collaboration between specialists from each domain essential.
Defining a comprehensive DevSecOps program is beyond the scope of this guide. With that said, some basic practices should be present in any container security program:
Secure coding practices. This should go without saying. If the applications in your environment are vulnerable to basic exploits, you’ll fall at the first hurdle.
Establish secure base images. If you’re consistently working with secure images, the chances of serious breaches are greatly reduced. This requires developers to have a reasonable understanding of what is (and isn’t) secure, and which elements of a container image are most likely to harbor vulnerabilities. It also requires a CI/CD pipeline that includes measures such as code analysis and security scanning.
Supply chain security. Third-party dependencies are a fact of life. However, it’s important to restrict their use to well-maintained projects that are frequently maintained and ensure images are consistently updated with the latest versions. A Software Bill of Materials (SBOM) is crucial here, particularly for evidencing compliance.
A clear shared responsibility model between development and operations. The delivery and security of container environments require constant interplay between these teams, from managing image registries and updates to patch control and securing inter-container communications. Having a clear outline of where responsibilities lie and how you will enforce them helps ensure nothing is missed along the way.
Infrastructure: Hardening the Container Environment
Most attacks against container environments exploit known vulnerabilities and basic misconfigurations in critical technologies. To protect against these threats, system hardening across the environment is essential to minimize the attack surface.
Hardening Container Environments for Security |
|---|
Orchestration platform | Configure platform in line with best practices (e.g., CIS Benchmarks). Follow architecture best practices. Use network policy to control traffic by IP, label, or Namespace. Implement role-based access controls (RBAC) according to least privilege. Set limits on number of users and level of access. Use a policy engine to enforce restrictions. |
Container images | Frequently scan images for new vulnerabilities. Ensure security best practices are followed within the CI/CD pipeline. Train developers in secure coding practices. Have formal supply chain security and risk management processes. Have a formal system for secrets management. Keep all images up to date with the latest versions of dependencies. Always use the latest version of images from public registries. Prefer certified images and sign/verify images before pulling. Produce digital signatures for clean code and trusted applications. Maintain a Software Bill of Materials (SBOM) to keep track of dependencies. |
Image registry | Use private registries wherever possible. Take advantage of all available access controls. Regularly scan registries for new vulnerabilities. |
Host OS | Use a slimline, container-specific OS, e.g., CoreOS. Configure OS according to best practices (e.g., CIS Benchmarks). Monitor OS for vulnerabilities and apply patches promptly. Use cgroups and Namespaces to separate resource quotas and access (Linux). Use strong OS access controls. |
Runtime | Have a baseline for standard app behavior and monitor for deviations. Monitor network protocols and payloads for suspicious activity. Monitor resource utilization to spot malicious activity (e.g., cryptomining, DoS). Use a separate, non-privileged user for commands. |
Orchestration platform agent | Ensure the latest version is installed on all nodes. Apply new versions and patches promptly. |
Network proxy | Ensure the latest version is installed on all nodes. Apply new versions and patches promptly. |
Data | Encrypt all sensitive data at rest and in transit. Secure communication between client and server using certificates (TLS). |
Application: Enforcing Policy and Access
The application phase is crucial and links heavily with governance, which we’ll discuss later. The goal here is to enforce a set of network policies and access controls that limit activity within the container environment to the absolute minimum. Your policies and controls should allow precisely what’s necessary to achieve its operational goals—and nothing more.
It may not be feasible (or possible) to lock things down this much, but this should be your objective when designing your policies and controls. When it comes to enforcement, manual processes are not suitable for such a fast-paced environment. Instead, employ appropriate tools and use the automation capabilities provided by your existing infrastructure.
A simple approach to the application security phase:
Assign access based on need, not convenience, and use access controls in your orchestration platform, container images, registries, OS, and runtimes to protect against unauthorized access.
Use a policy engine to enforce network and security policies across your environment and frequently review policies to ensure they remain in line with your needs and objectives.
Monitoring for (and Responding to) Threats
This phase comes down to visibility, logging, monitoring, and incident response. While traditional security tools typically aren’t suited to container environments, their replacements largely perform similar functions. As in any IT environment, key capabilities include:
Logging of activity data from across the container environment.
Monitoring tools to analyze logs in real-time and alert on suspicious activity (e.g., lateral movement, privilege escalation, or creation of malicious containers).
Firewalls to identify and block threats in the container environment.
Prompt incident response to resolve identified threats and incorporate learning points into monitoring and protective tools to prevent similar threats in the future.
Abstracting Container Security
For many organizations, completing all of the steps we’ve described will be a huge challenge due to cost and a lack of available skills. If that’s the case, you can choose a host and infrastructure profile that reduces your attack surface by passing some responsibilities to the supplier.
Options include:
Employ Kubernetes-as-a-Service via Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), or Google Kubernetes Service (GKS). These services provide automatic updates and security patches and include various functions (e.g., environment monitoring and dynamic access controls) that can further reduce your operational overhead.
Replace Kubernetes with a fully managed alternative such as Amazon Elastic Container Service or Azure Container Service (ACS). This model abstracts away much of the setup and maintenance of self-managed orchestration platforms, further reducing your security responsibility.
Adopt a serverless technology such as AWS Fargate, removing the need to provision, configure, or scale servers for your container environment. This passes even more security responsibility to the supplier and can free internal resources for more strategic activities.
A Final Word on Container Security
The controls above aren’t exhaustive. There’s far more you can do to secure a container environment.
For instance, you could implement a forced tunnel to direct network traffic through an IDS/IPS system. Or you could use an isolation technology to enforce a security perimeter between pods and nodes. In fact, there’s an almost infinite list of systems, controls, and tools you could implement to protect your environment. At the same time, not every control we’ve listed here may apply to your container use cases.
Ultimately, each organization must evaluate its container risk profile and design a security program that meets its operational and risk objectives while staying within budget.
Book a demo to learn how you can securely scale your cloud-first organization while achieving continuous compliance with multiple frameworks.
