Container workload protection

[beta] This functionality is in beta and is subject to change. The design and code is less mature than official GA features and is being provided as-is with no warranties. Beta features are not subject to the support SLA of official GA features.

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

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

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.

CWP for Kubernetes uses a flexible 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.

CWP for Kubernetes 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 is 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.