Beyond the build: Why runtime security is critical for container protection


Containers and microservices have changed the game: They allow organizations to ship apps faster and make better use of hardware. They encourage modular software design. And containers help teams embrace the cloud-native paradigms of scalability, mobility, and resilience. It’s safe to say that containers have shaken things up. 

Why is it hard to protect containers?

Securing containers isn’t easy, and most companies are failing to protect their containerized applications. The Cloud Native Computing Foundation reported that more than half of its surveyed organizations suffered a security incident involving containers in the last 12 months.* The Cloud Security Alliance said that containers continue to be a “prime target for attackers because organizations lack sufficient security control mechanisms.” And the Enterprise Strategy Group recently stated that organizations’ reliance on containers is “outpacing their ability to secure them.”

Shifting left isn’t enough

If you listen to most security vendors, they’ll tell you that the key to container security is in shifting left. And we would agree that this is important. At Elastic, we understand that shifting left is a critical component of building a cloud security program, and we believe the Elastic Stack is the perfect place to centralize these initiatives.

But in modern cloud security architectures, you need to balance your shift-left efforts by maintaining a tight grip on what’s happening to the right of all of the proactive measures you’ve taken. You need to detect misconfigurations and vulnerabilities that slipped through the cracks. You need to detect and stop malicious behavior on your workloads. You’ve got to protect your runtime. 

Security doesn’t stop at any given point in time, and that means that a shift toward implementing security earlier in the process doesn’t preclude protecting runtime environments. Organizations could do everything by the book. They could employ secure coding practices on Tuesday, and build lean, distroless containers on Wednesday. On Thursday they might remove every known vulnerability and then deploy the image to production on Friday. But when a new vulnerability is discovered on Saturday morning, their systems could be compromised before supper. If your container security program stops at runtime, this is the risk position you’re in today. 

Runtime protection is essential

To prevent this, you’ve got to implement container runtime security. Usually, this means locking down security capabilities, implementing network policies, and restricting permitted system calls using seccomp policies. But this takes time and know-how. Application developers are rarely aware of the fine-grained details of how their apps talk on the network or how they function at an operating system level. DevOps and platform security are responsible for securing Kubernetes but rarely have time to write individual policies for each container or deployment. And in containerized environments, the responsibility for implementing security is no longer in the hands of the traditional security operations teams. 

The result is that organizations tend to lean harder on shifting left rather than shielding right. And hackers are making hay.

Simplifying container security with Elastic

To solve this problem, Elastic is taking a novel approach. In addition to our Cloud Workload Protection and Posture Management features (both recently made generally available as of 8.5), we’re excited to announce the release of our newest Container Workload Protection features — releasing in beta in the forthcoming 8.8 version. 

We chose to build CWP using an agent-based approach because we believe that real-time events are absolutely necessary in order to provide teams with the assurance that they can discover and respond to security threats instantly. Waiting hours or days to complete an API crawl or side scan just isn’t a realistic option for most security teams. But because we know almost no one loves agents, we wanted to make our agent as lightweight as possible and easy to deploy and manage. It is installed as a Kubernetes Daemonset using either Elastic Agent/Fleet architecture or the daemonset can be deployed in standalone mode for those that prefer to manage their agents using an Infrastructure-as-Code/Gitops model. 

From a feature perspective, we wanted our beta release to make it easier for teams to protect container runtimes by providing the tools needed to visualize, secure, and lock down their infrastructure. The solution consists of the following components:

Lightweight data collection using eBPF. Our lightweight, eBPF-powered agent deploys quickly and easily into managed Kubernetes clusters such as Amazon EKS, Google GKE, and Azure AKS, and streams high-fidelity file and process data to Elastic Security for SIEM. Our agent was built to work well with the powerful Elastic Agent architecture, but it can also be deployed in standalone mode for customers who favor declarative, Infrastructure-as-Code deployments.

Built on the powerful Elastic Security solution. CWP provides organizations with immediate security by leveraging the power of the mighty Elastic Security for SIEM. Our SIEM ships with a full complement of rules that help your teams stay vigilant for common security threats such as reverse shells, container escapes, and privilege escalation — so you can respond quickly to security events.

security container drift
Simple YAML policies define how container drift is detected and optionally, blocked.

Detect and stop drift with powerful pre-execution blocking. Our Container Workload Protection ships with drift protection policies that can detect and even prevent drift from ever taking place in your container environments. Containers are typically built as immutable infrastructure, meaning that changes inside of containers are not expected during normal operations. Elastic leverages this principle to enable teams to write simple and powerful policies that can detect changes to container file systems without relying on more resource-intensive techniques like memory scanning or endpoint attack signatures.

Policies can be configured to raise alerts for later investigation and remediation or even block unrecognized changes from ever taking place. This is incredibly powerful as it allows teams to make their container runtimes hostile to attackers — effectively eliminating attackers’ abilities to use containers to establish a foothold for later lateral movement, privilege escalation, or other remote code execution.

edit defend for containers integration
The solution features an easy-to-use policy editor to help construct YAML and automatically deploy policies to Kubernetes clusters.

Visibility into container workloads for auditing and compliance. Elastic ships with amazing features that help organizations achieve x-ray vision inside their containers. Our investigative tools like Session Viewer, the Kubernetes dashboard, and Process Analyzer help security analysts understand who-did-what-and-when across their entire fleet of workloads — VMs or containers. This is particularly helpful for organizations that are subject to audit and compliance frameworks (such as PCI-DSS v3, NIST 800-190, HIPAA, FIPS-140) and also provides a terminal-like view of how attackers interact with your environment from a forensic standpoint.

security kubernetes
Security analysts can triage alerts and review system activity using the “terminal-like” experience of Session Viewer.

Try it for yourself

These new container workload protection features join Elastic’s existing cloud security features at an exciting time. In addition to our already available VM workload and Kubernetes posture features, Elastic Security will also be unveiling a beta release of cloud security posture management (CSPM) for AWS features and an early preview of vulnerability management features in 8.8 as well. Please read here to learn more about how to use these features to find and squash misconfigurations and vulnerabilities in your cloud runtime environments. 

One last thing — if you’re excited and passionate about container workload security and would like to get involved in our beta programs or learn more directly from our product team, please reach out to us at! We’d love to hear from you.

* Cloud Native Computing Foundation. (2021). 2021 CNCF Survey