IMPORTANT: No additional bug fixes or documentation updates will be released for this version. For the latest information, see the current release documentation.
« Container workload protection Container workload protection policies »
Elastic Docs ›Elastic Security Solution [8.8] ›Cloud native security ›Container workload protection

Get started with CWP

edit

Get started with CWP

edit

This page describes how to set up Container Workload Protection (CWP) for various use cases.

Initial setup

edit

First, you’ll need to deploy Elastic’s Defend for Containers integration to the Kubernetes clusters you wish to monitor.

  1. Go to Manage > Container Workload Security > Add D4C Integration.
  2. Name the integration. The default name, which you can change, is cloud_defend-1.
  3. Optional — make any desired changes to the integration’s policy by adjusting the Selectors and Responses sections. (For more information, refer to the Defend for Containers policy guide). You can also change these later.
  4. Under Where to add this integration, select an existing or new agent policy.
  5. Click Save & Continue, then Add Elastic Agent to your hosts.
  6. On the Elastic Agent policy page, click Add agent to open the Add agent flyout.
  7. In the flyout, go to step 3 (Install Elastic Agent on your host) and select the Kubernetes tab.
  8. Download or copy the manifest (elastic-agent-managed-kubernetes.yml).

  9. Open the manifest using your favorite editor, and uncomment the #capabilities section:

    #capabilities:
#  add:
#    - BPF # (since Linux 5.8) allows loading of BPF programs, create most map types, load BTF, iterate programs and maps.
#    - PERFMON # (since Linux 5.8) allows attaching of BPF programs used for performance metrics and observability operations.
#    - SYS_RESOURCE # Allow use of special resources or raising of resource limits. Used by 'Defend for Containers' to modify 'rlimit_memlock'
  10. From the directory where you saved the manifest, run the command kubectl apply -f elastic-agent-managed-kubernetes.yml.
  11. Wait for the Confirm agent enrollment dialogue to show that data has started flowing from your newly-installed agent, then click Close.

Get started with threat detection

edit

One of the default D4C policies sends process telemetry events (fork and exec) to Elasticsearch.

In order to detect threats using this data, you’ll need active detection rules. Elastic has prebuilt detection rules designed for this data. (You can also create your own custom rules.)

To install and enable Elastic’s prebuilt rules:

  1. Go to Security > Manage > Rules, and click Load Elastic prebuilt rules and timeline templates (this may take a few minutes).
  2. Once the rules have loaded, you will see the Rules management page. Use the Tags selector to search for container. Select the Container Workload Protection tag.
  3. Select all the rules with the tag, and then click Bulk actions > Enable.

Get started with drift detection and prevention

edit

Elastic Security defines container drift as creating a new executable or modifying an existing executable within a container. Blocking drift restricts the number of attack vectors available to bad actors by prohibiting them from using external tools.

One of the default D4C policies creates alerts in Elastic Security when container drift is detected. Before you enable blocking, we strongly recommend that you observe a production workload using the default policy to ensure that the workload does not create or modify executables as part of its normal operation.

To enable blocking:

  1. Add a new selector called blockDrift.
  2. Go to Security > Manage > Container Workload Protection > Your integration name.
  3. Under Selectors, click Add selector > File Selector. By default, it selects the operations createExecutable and modifyExecutable.
  4. Name the selector, for example: blockDrift.
  5. Scroll down to the Responses section and click Add response > File Response.
  6. Under Match selectors, add the name of your new selector, for example: blockDrift.
  7. Select the Alert and Block actions.
  8. Click Save integration.

Policy validation

edit

To ensure the stability of your production workloads, you should test policy changes before implementing them in production workloads. We also recommend you test policy changes on a simulated environment with workloads similar to production. This approach allows you to test that policy changes prevent undesirable behavior without disrupting your production workloads.

« Container workload protection Container workload protection policies »