elastic / elastic/integrations

[Integration Name]: Defend for Containers. No guidance when integration is added to an existing deployed agent policy

Open
#18,066 1 comment 0 reactions 0 assignees View on GitHub
Integration:cloud_defend needs:triage Team:security-siem-conduit
Dominant language
Handlebars
Stars
333
Forks
647
Avg merge
2d 17h
Merged PRs (30d)
225

Description

### Integration Name

Defend for Containers (BETA) [cloud_defend]

### Dataset Name

cloud_defend

### Integration Version

1.4.0

### Agent Version

9.2.7

### OS Version and Architecture

Kubernetes (kubeadm) nodes running Linux (amd64) with containerd runtime.

### User Goal

Add the Defend for Containers (cloud_defend) integration to an already-deployed Fleet-managed Elastic Agent on Kubernetes.

### Existing Features

When a user adds the Defend for Containers (cloud_defend) integration to an already-deployed Fleet-managed Elastic Agent on Kubernetes, the agent fails.

### What did you see?

```
Failed
input not supported - ensure you have installed the correct flavor: https://www.elastic.co/docs/reference/fleet/install-elastic-agents#elastic-agent-installation-flavors
```

### Anything else?

There is no guidance anywhere in this flow telling the user that they need to:

1. Switch the container image from `elastic-agent` to `elastic-agent-complete`
2. Add `BPF`, `PERFMON`, and `SYS_RESOURCE` capabilities to the container securityContext
3. Redeploy the DaemonSet with these changes

### The documentation gap

The existing docs ([Get started with CWP for Kubernetes](https://www.elastic.co/guide/en/security/current/d4c-get-started.html)) assume the user adds Defend for Containers to their agent policy **before** generating and deploying the Kubernetes manifest. In that flow, the downloaded manifest already includes the necessary (commented-out) capabilities block and presumably uses the correct image.

However, it is very common for users to:

1. Create an agent policy in Fleet
2. Download and deploy the Kubernetes manifest
3. Later add Defend for Containers to the same policy

In this case:

- The Fleet UI / integration setup wizard does not warn that the deployed manifest needs updating
- The agent error message links to a generic "installation flavors" page that does not explain the specific manifest changes required
- There is no single doc page that lists the exact changes needed to retrofit an existing Kubernetes deployment for Defend for Containers

### Suggested improvements

- **Fleet UI**: When adding Defend for Containers to a policy that has Kubernetes-enrolled agents, show a banner or post-install step listing the required manifest changes (image flavor, securityContext capabilities).
- **Error message**: Make the "input not supported" error more specific, e.g., "Defend for Containers requires the elastic-agent-complete image and BPF/PERFMON/SYS_RESOURCE capabilities. See [link] for Kubernetes manifest changes."
- **Documentation**: Add a section to the [CWP getting started guide](https://www.elastic.co/guide/en/security/current/d4c-get-started.html) covering the "adding to an existing deployment" scenario, with the specific image and securityContext changes required.

Contributor guide

Open the contributing guide

Research direction

Start with the CWP getting started guide at d4c-get-started.html and review the existing Kubernetes manifest instructions. Document the existing-deployment scenario, including the image, securityContext capabilities, and DaemonSet redeployment steps described in the issue. Consider how the Fleet UI and error message suggestions fit the same guidance, and verify that the finished documentation covers all three required changes.

Written by the indexing model from the issue text.

Assessment

Tech stack
kubernetes, linux
Domain
devops, documentation, infrastructure
Issue type
Documentation
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.