A Comprehensive Guide to Container Security Architecture
Introduction: The Rise of Containers in Cloud Computing
As organizations move fast to develop and deliver business critical applications, they face significant challenges in aligning agility with security and compliance when it comes to cloud computing, and delivering secure cloud applications. Developing applications with containers has become an increasingly popular way to operationalize speed, but it must be able to do so without jeopardizing security.
Containers enable organizations to deliver much faster and to be more responsive to market trends. These business benefits are fueling the rapid growth in container adoption among enterprises. According to 451 Research, the container applications market is expected to grow to nearly $4.3 billion in 2022, at a compound annual growth rate (CAGR) of as high as 30%.
It’s clear that improving container security architecture & automation is critical to ensuring the protection and operations of a billion dollar industry. growth.
Understanding Container Security Risks: Containers Expose the Cloud to New Threats
Containers are driving new architectures and security paradigms in the cloud. There have been multiple reported incidents of DDoS attacks, kernel and orchestration exploits in containers compromising enterprise cloud assets. Container native security features are not enough to tackle these new vulnerabilities and threat vectors:
1. Sandbox Limitations – Not enough Isolation
Containers essentially have an operating system, application, and pre-configured support files, all wrapped up into a portable, read-only image. Unlike VMs, containers share the host OS kernel. As a result, they have a smaller image footprint and build much faster.
On the flip-side, containers lack true sandboxing (unlike hypervisors for VMs), and the host remains the main attack surface. If an attacker exploits any host OS vulnerability, all containers sharing the OS could be compromised.
2. Increased Attack Surface
Container runtime and orchestration platforms like Docker and Kubernetes accelerate deployment velocity. But vulnerabilities in the orchestration layer adds to the attack surface. For example, by exploiting misconfigurations in Kubernetes (e.g. over-provisioning of privileged access), an attacker could gain direct control over the entire fleet of containers.
Complexities in the container control plane coupled with the extensive use of APIs at the service-layer expose application internals. In microservice architectures, application-breakdown multiplies a small number of workloads by a factor of 10 or 100. Collectively, these expand the attack surface.
3. Container Images are Vulnerable
Mostly, containers are built from images stored in publicly available repositories like GitHub. The build images typically have dependencies on other images and libraries in the repo. Vulnerability in any of these source codes can rapidly proliferate to (potentially) thousands of other containers.
When using images from the public repo, unless the images are signed and the code is validated, an attacker can also run their malicious image. This puts both the host and the data at risk.
4. New Attack Vectors
Kubernetes pods running one or more containers use unique IP addresses for connectivity. Attackers can exploit these IP addresses as doorways to launch attacks either from external networks or internally, for example, by exploiting victims of a phishing attack or by launching a reverse shell in a server-connected pod. IP-whitelisting is inadequate to counter these attacks, especially when trusted IP addresses are used. A misconfigured container is another attack vector to explore runtime vulnerabilities. With compromised container credentials like API key or username/password, an attacker could even spoof into the database and cloud services.
5. Ephemeral Workloads
Container resources are constantly destroyed and recreated. It is common to recycle assets like servers, IP addresses, firewalls, drives, overlay networks, etc. to optimize utilization. Perimeter and IP address-based security controls are useless when resources are ephemeral. Forensic investigations are also impossible when logs disappear after the containers are spun down.
6. Rule-Based Controls Can’t Secure Containers
Rules and signature-based controls can’t keep up with rapidly changing container infrastructure. Besides, to change one firewall rule, the IT team may have to wait for days for a change control window to open up.
It is nearly impossible to secure hyper-dynamic container infrastructure using traditional network and endpoint controls. Moreover, traditional tools lack the container context to address container-specific security issues. For example, traditional scanning tools may not recognize container-specific misconfigurations and vulnerabilities.
The 5 Core Components of Container Security Architecture
Threat Detection
Lacework establishes a behavioral baseline by discovering every container in the cloud and clusters the containers based on different behaviors. Lacework continuously monitors communications, launches and other cloud runtime behaviors, and uses unsupervised machine learning to detect and alert abnormal behavior in real-time. Any connections or activity performed out of normal context and existing relationships trigger an anomaly. Detection accuracy minimizes alert-noise.
Continuous Visibility
Lacework functions at the process-level and provides deep visibility into container-related events, communication, new connections, images, etc. For the container orchestration layer, Lacework provides deeper visibility and security for Kubernetes clusters and communication among the clusters, which can be further visualized at the namespace level, and pod-level. Deep visibility exposes threats at all layers including publicly exposed and unsecured API servers and management consoles.
Figure 1 illustrates how Lacework visualizes all containers in the cloud environment by using Polygraph. This provides a global, logical view of the containers. Analysts can also drill down into each active container to view process-level details:
Figure 1: Visualization of container security interface
Advanced Traceability
With Polygraph, Lacework provides charts showing the 4W’s (Who, What, Where, When) to quickly trace back to the origin of an attack or abnormal behavior (example: an open API server). Since the events are logged at a process level, the logs continue to persist even when the containers are torn down. Attackers usually delete their trail. But in this case, the logs cannot be wiped out. This fine-grain, persistent visibility distinguishes how Lacework secures containers.
Build-Time and Run-Time Integration
Lacework coalesces build-time and runtime container security vigilance. During the pre-build stage, Lacework scans through the containers stored in the cloud to detect known vulnerabilities (CVEs), misconfigurations, malware, unnecessary code, etc. These checks are fully automated and cover the application, container runtime, and orchestration layers. On detecting genuine anomalies, Lacework generates alerts along with container-aware traceability logs. This enables DevSecOps teams to investigate and assess the risk of pushing the container to production.
Most CI/CD security solutions stop here. What’s unique about Lacework’s approach is that it integrates the findings in development to add the security context at runtime. For example, if during CI/CD Lacework detects open storage buckets or data-at-rest stored without encryption, then the container would be flagged as vulnerable if at runtime it would be open to the world.
Continuous Audit and Compliance
Lacework brings multicloud checks into one dashboard by continuously monitoring configuration changes and API activity for containers across AWS, Azure, and GCP platforms. CIS benchmark scans are performed during container image development and container deployment.
Additionally, Lacework includes supplemental checks based on industry best practices and common compliance frameworks like PCI-DSS, SOC 2, HIPAA, NIST, etc.
While most solutions only identify non-conforming compliance rules, Lacework goes a step further. It alerts behavioral anomalies even when the associated configurations meet the required standards.
Lacework’s Comprehensive Approach to Container Security Architecture
Containers require a new approach to security. Lacework was among the first cloud security vendors to highlight this need. The Lacework Cloud Security Platform has been built to resolve container-specific security challenges across the application lifecycle, and at every layer of the containerized stack.
Lacework brings multicloud checks into one dashboard by continuously monitoring configuration changes and API activity for containers across AWS, Azure, and GCP platforms. CIS benchmark scans are performed during container image development and container deployment. Additionally, Lacework includes supplemental checks based on industry best practices and common compliance frameworks like PCI-DSS, SOC 2, HIPAA, NIST, etc.
While most solutions only identify non-conforming compliance rules, Lacework goes a step further. It alerts behavioral anomalies even when the associated configurations meet the required standards.
From automated threat detection to compliance, Lacework’s comprehensive approach to container security ensures nothing is left unprotected, which point solutions can’t guarantee.
According to Gartner, by 2022 globally, 75% of enterprises are expected to run containerized applications. This is a sharp rise from 30% in 2019. This explosive growth underscores the importance of securing containers with a comprehensive solution.
Interested in learning how Lacework can secure your containers? Let’s chat!
Photo by Taweesak Jaroensin on Shutterstock
[1] https://451research.com/451-research-says-application-containers-market-will-grow-to-reach-4-3bn-by-2022