Securing Critical Infrastructure in Restricted K8s Environments

The enterprise-grade Cloud Native Application Protection Platform (CNAPP), ThreatStryker, provides industry-leading runtime protection capabilities for cloud-native workloads. As described in our earlier blog article, the platform uses various techniques to build the runtime context of these workloads. This runtime context is then used to identify any malicious behavior and is also mapped to common MITRE tactics and techniques.

The ThreatStryker CNAPP can detect a wide variety of potentially malicious events across network, files, and process subsystems. This is done using the eBPF-based agents that are deployed within the infrastructure. Unlike conventional agents, eBPF-based agents are lightweight, do not need any restart of existing services or systems, and do not need any insertion of kernel modules. These agents can be used to obtain runtime context; a malicious payload within the network traffic that can be used to exploit the vulnerability; and generate actionable alerts. In the absence of eBPF, we can perform the same level of analysis, albeit a bit slowly but protection policies need to be handled differently. 

Unlike many other platforms and solutions, the advantage of using an agent to obtain runtime insights is that the CNAPP can now protect the workloads against these types of malicious attacks. The protection can be in the form of blocking the senders of these malicious payloads or performing a quarantine of the affected workloads.

But what happens if you do not have access to eBPF? Or even iptables for that matter? How about no access to underlying CNIs and even K8s ingress controller? A case in point could be AWS Fargate or any restricted/locked down K8s environments. 

We recently helped a large customer of ours secure their critical infrastructure by integrating with AWS WAF (Web Application Firewall). They had 40K requests per second, 50K compute instances on AWS, and locked down K8s with no access to CNIs or ingress controller. In this case, the deeper detections and intent mapping happen at the agent level but the blocking of malicious IPs is handled at the perimeter level so future attempts are thwarted in-line.

In the rest of this blog article, we will outline the steps needed for the ThreatStryker platform to dynamically protect the workloads, by using the available API frameworks to interface with cloud-native firewalls like AWS WAF.

The first step is to provide the ThreatStryker platform with the necessary permissions. We will use the policy AWSWAFFullAccess to give us the relevant permissions to control the WAF.

Then we will add the appropriate role to the EC2 instance that has the ThreatStryker platform installed on it.

Now that we have completed the configuration within AWS, we will look at the necessary steps for the ThreatStryker platform. Firstly, we will enable the use of WAF within the platform.

‍

Once we have enabled WAF, we will copy the relevant ARN’s for WAF into the ThreatStryker platform.

Now, whenever the ThreatStryker platform identifies a sender of a malicious payload that needs to be blocked, it will update the AWS WAF with the relevant rules.

We can see that the ThreatStryker platform can interface with cloud-native firewalls which helps to respond against attempts to send malicious and well-crafted payloads that can exploit vulnerabilities within the infrastructure. This will help a large number of users keep their infrastructure secure as they begin their journey to remediate vulnerabilities found in various libraries.

Shortly, we will roll out updates to the ThreatStryker CNAPP to support firewalls within other public and private cloud providers. Join the Deefence community for updates. 

Find out more about how Deepfence is protecting enterprise cloud infrastructure and applications by requesting a free trial or a 15-minute demo. ThreatStryker is also available via the AWS Marketplace.