Container workload protection

edit

Elastic Container Workload Protection (CWP) provides cloud-native runtime protections for containerized environments by identifying and optionally blocking unexpected system behavior in Kubernetes containers.

Use cases

edit

Threat detection & threat hunting

edit

CWP sends system events from your containers to Elasticsearch. Elastic Security’s prebuilt security rules include many designed to detect malicious behaviors in container runtimes. These can help you detect behaviors that should never occur in containers, such as reverse shell executions, privilege escalation, container escape attempts, and more.

Drift detection & prevention

edit

Cloud-native containers should be immutable, meaning that their file systems should not change during normal operations. By leveraging this principle, security teams can detect unusual system behavior with a high degree of accuracy — without relying on more resource-intensive techniques like memory scanning or attack signature detection. Elastic’s Drift Detection mechanism has a low rate of false positives, so you can deploy it in most environments without worrying about creating excessive alerts.

Workload protection policies

edit

CWP uses a powerful policy language to restrict container workloads to a set of allowlisted capabilities chosen by you. When employed with Drift and Threat Detection, this can provide multiple layers of defense.

Support matrix:

edit
EKS 1.24-1.26 (AL2022) GKE 1.24-1.26 (COS)

Process event exports

Network event exports

File event exports

File blocking

Process blocking

Coming Soon

Coming Soon

Network blocking

Drift prevention

Mount point awareness

How CWP works

edit

CWP uses a lightweight integration, Defend for Containers (D4C). When you set up the D4C integration, it gets deployed by Elastic Agent. Specifically, the Elastic Agent gets installed as a DaemonSet on your Kubernetes clusters, where it enables D4C to use eBPF Linux Security Modules LSM and tracepoint probes to record system events. Events are evaluated against LSM hook points, enabling Elastic Agent to evaluate system activity against your policy before allowing it to proceed.

Your D4C integration policy determines which system behaviors (for example, process execution or file creation or deletion) will result in which actions. Selectors and responses define each policy. Selectors define the conditions which cause the associated responses to run. Responses are associated with one or more selectors, and specify one or more actions (such as log, alert, or block) that will occur when the conditions defined in an associated selector are met.

The default D4C policy sends data about all running processes to your Elasticsearch cluster. This data is used by Elastic Security’s prebuilt detection rules to detect malicious behavior in container workloads.

To learn more about D4C policies, including how to create your own, refer to the D4C policies guide.