[D4C] cloud_defend. Removed kubernetesPodId. Update docs. - #6112

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

🤖 GitHub comments

🌐 Coverage report

Karl, I think the readme should also act as the source of truth for our feature compatibility matrix:

<style type="text/css"></style>

I also think we could replace the overview section with this text which I think does a better job of really describing the integration:

How Container Workload Protection Works
CWP is powered by a lightweight integration (Defend for Containers) that is bundled and configured by the Elastic Agent. The agent is installed as a daemonset on supported Kubernetes clusters and the integration uses eBPF LSM and tracepoint probes to produce system events. Events are evaluated against eBPF LSM hook points, enabling a configured policy to be evaluated before system activity is allowed to proceed.

The policy determines which system behaviors (for example, process executions, file creations or deletions, etc) will result in an action. Actions are simple: logging the behavior to Elasticsearch, creating an alert in Elasticsearch, or blocking the behavior.

Threat Detection
The system ships with a default policy configured featuring two selectors and responses. The first selector is designed to stream process telemetry events to the user’s Elasticsearch cluster. The policy uses the selector allProcesses which specifies fork and exec operations. This selector is mapped to the allProcesses response, which specifies a log action.

The resulting telemetry data is transformed into an ECS document and streamed back to the user’s Elasticsearch cluster, where the Elastic Security SIEM evaluates the data to detect malicious behavior.

Drift Detection & Prevention
The second selector is written to detect the modification of existing executables or the creation of new executables within a container (This is how Elastic detects “container drift”). The policy selector is named executableChanges and is mapped to a response section called executableChanges which specifies an alert action.

This policy is configured with an alert response, meaning that when drift conditions are detected, the matching event(s) are collected and written as an alert to the user’s Elasticsearch cluster. A prebuilt rule “escalation rule” in the SIEM watches for these alert documents and raises an alert in the SIEM when drift is detected. This policy can also be modified to block drift operations by changing the response action to block.

Policies
Users that want to use the full strength of CWP will benefit to understand the system’s policy syntax, which enables fine-grained policies to be constructed. Policies can be built to precisely match expected container behaviors– disallowing any unexpected behaviors– and thereby substantially hardening the security posture of container workloads.

Policies are composed of selectors and responses. A given policy must contain at least one selector and one response. Currently, the system supports two types of selectors and responses, file and process. Selectors tell the service what system operations to match and have a number of conditions that can be grouped together (using a logical AND operation) to provide precise control. Responses instruct the system on what actions to take when system operations match selectors.

@learhy I think your suggestions here are great, but they are outside the scope of the PR. I will transpose them into a new issue and we get them in the queue.

My bad, I've created the new issue linked above for my own clerical reasons :)

Thanks for the comments @learhy I can make the change in this PR. This just avoids version churn as we're already at 1.0.5

@norrietaylor @learhy Did we want to add anything about having to uncomment "capabilities" in the yaml?

Package cloud_defend - 1.0.6 containing this change is available at https://epr.elastic.co/search?package=cloud_defend

Pinging @elastic/sec-linux-platform (Team:Security-Linux Platform)