Response Actions

Execute containment and data-gathering actions directly from Sysdig Secure to stop threats in progress, collect forensic evidence, and undo changes — all from the same interface where you investigate

Security investigations are only as valuable as the actions they produce. Discovering that a container is exfiltrating data is critical — but if acting on that discovery requires switching to a separate tool, searching for the right host or pod name, and manually running commands, the attacker has time to complete the operation before you can stop it.

Response Actions in Sysdig Secure let you execute containment and evidence-collection actions directly from the investigation interface, on the exact resource you are already looking at. You can kill a process, isolate a workload’s network, capture a volume snapshot for forensics, download container logs, or quarantine a file — without leaving Sysdig and without needing shell access to the target host or cluster.

Value

Why Use Response Actions

Speed matters during an active incident. The longer a compromised workload runs, the more damage it can cause — data exfiltrated, lateral movement completed, persistence mechanisms installed. Response Actions reduce the time from detection to containment from minutes (opening a terminal, SSHing to the right host, running the right command) to seconds (selecting the action in Sysdig and confirming).

Context is preserved. Because Response Actions run from within the investigation context — the same Resource 360 panel or Threats view where you identified the problem — you don’t lose your place or have to reconstruct which resource you were looking at.

Evidence is collected before containment destroys it. The ordering matters: Sysdig lets you take a volume snapshot or download logs before killing a container. Actions taken from the same interface make it natural to follow the forensically correct order of operations.

Undo is built in. For destructive or disruptive actions, Sysdig provides paired undo actions. You can pause a container to stop a process, investigate, and then unpause it — all from the same response history entry.

Example (end-to-end): A runtime policy fires at 2:17 AM because a container in your payments namespace is running curl to an unknown external IP. You open the event in Sysdig, confirm it is not an expected behavior, and take these actions in sequence — all from the Sysdig UI, in under 5 minutes:

1. Get Logs — Download the container’s stdout/stderr to confirm the extent of the outbound activity.
2. Kubernetes Volume Snapshot — Create a point-in-time backup of the attached persistent volumes before any data is lost.
3. Isolate Network — Apply a Kubernetes network policy that blocks all traffic to and from the workload, stopping the exfiltration.
4. Acquire File — Download the binary that initiated the curl call for malware analysis.

You now have forensic evidence and a contained threat, and your on-call team wakes up to a complete incident record rather than an empty audit trail.

Prerequisites

Prerequisites

Response Actions require components to be running and configured in your environment. The specific requirements depend on which actions you want to use.

Sysdig Agent

The Sysdig agent must be deployed on any host where you want to run host-level or container-level response actions. Response actions on the agent are enabled by default when the agent supports them.

Verify the agent configuration includes:

features:
  respond:
    response_actions:
      enabled: true

Cluster Shield (Kubernetes Actions)

For Kubernetes workload actions — including network isolation, pod deletion, volume snapshots, and workload-level operations — Cluster Shield must be deployed with the responder component enabled.

cluster_shield:
  features:
    respond:
      response_actions:
        enabled: true

The Cluster Shield responder component requires approximately 128 MB of memory. Verify your cluster has capacity before enabling it.

Host Shield (Host Actions)

For host-level actions on Linux, Windows, or AIX systems, Host Shield must be deployed with the responder component enabled. The Host Shield responder requires approximately 150 MB of memory.

Permissions

Two permission scopes control access to response actions:

Permission	Controls
containment-response-actions.exec	Execute containment actions (kill, pause, isolate, quarantine)
containment-response-actions.read	View containment action history
data-gathering-response-actions.exec	Execute data-gathering actions (logs, snapshots, file acquisition)
data-gathering-response-actions.read	View data-gathering action history

Your Sysdig administrator assigns these permissions to teams or roles. A security analyst might have exec permissions for data gathering but only read for containment, while a security engineer has exec for both.

AWS Credentials (Cloud Actions)

Cloud-level actions (IAM quarantine, cloud volume snapshot, make resource private, fetch CloudTrail logs) require that Sysdig has a connected AWS account with the appropriate IAM permissions for the target account and region.

Actions

Action Categories

Sysdig Secure provides 26 response actions in two categories.

Containment Actions

Containment actions stop or limit the activity of a compromised resource. Most containment actions have a paired undo action so you can reverse the change after investigation.

Action	What It Does	Undo Action
Kill Process	Sends SIGKILL to a process, terminating it immediately	None — process termination is permanent
Kill Container	Sends SIGKILL to the container runtime, terminating the container immediately	None — use with caution in production
Stop Container	Sends SIGTERM to the container, allowing a graceful shutdown	Start Container
Start Container	Starts a previously stopped container	None (undo for Stop Container)
Pause Container	Freezes the container runtime, suspending all processes while preserving state	Unpause Container
Unpause Container	Resumes a paused container, restoring all suspended processes	None (undo for Pause Container)
Delete Pod	Terminates the pod. If the pod is managed by a Deployment or ReplicaSet, Kubernetes creates a replacement	None — the replacement pod starts clean
Isolate Network	Applies a Kubernetes NetworkPolicy that blocks all ingress and egress traffic to and from the workload	Delete Network Policy
Delete Network Policy	Removes the isolation NetworkPolicy, restoring normal traffic	None (undo for Isolate Network)
File Quarantine	Moves a file to a sandbox directory, making it non-executable	File Unquarantine
File Unquarantine	Restores a quarantined file to its original location	None (undo for File Quarantine)
IAM Quarantine	Restricts an AWS IAM user or role by attaching a deny-all policy, preventing further API calls	IAM Unquarantine
IAM Unquarantine	Removes the deny-all policy from the IAM user or role, restoring their permissions	None (undo for IAM Quarantine)
Make Cloud Resource Private	Restricts network access to an AWS resource (S3 bucket or RDS instance), removing public access	Undo Make Cloud Resource Private
Undo Make Cloud Resource Private	Restores the previous public access settings for the AWS resource	None (undo for Make Cloud Resource Private)

Data-Gathering Actions

Data-gathering actions collect forensic evidence without disrupting the running workload. Run these before containment actions when possible, so evidence is preserved before the workload is stopped.

Action	What It Collects	Notes
Get Logs	The stdout and stderr logs from a container or workload	Downloads as a plain text file. Supports collecting from all containers in a pod or only previous container logs.
Acquire File	A specific file from the container’s filesystem	Downloads the file directly to your browser. Optionally upload to an S3 bucket.
Fetch Cloud Logs	AWS CloudTrail API call logs for a user, role, or service account	Requires a time range and the identity (user ARN, assumed role, or IAM identity type).
Kubernetes Volume Snapshot	A point-in-time backup of one or more Kubernetes persistent volume claims (PVCs)	Requires Kubernetes VolumeSnapshot support in the cluster. Multiple PVCs are processed independently — a failure on one does not stop the others.
Kubernetes Delete Volume Snapshot	Deletes a previously created Kubernetes volume snapshot	Not reversible.
Cloud Volume Snapshot	Creates EBS snapshots of all volumes attached to an EC2 instance	Requires AWS IAM permissions for snapshot creation.
Undo Cloud Volume Snapshot	Deletes the EBS snapshots created by Cloud Volume Snapshot	Not reversible — verify you no longer need the snapshots before running.
Rollout Restart	Restarts all pods in a workload to refresh the runtime environment	Useful when a compromised image or configuration needs to be flushed without a deployment change.

Running & Inputs

Running a Response Action

From the Threats View

1. Open Sysdig Secure and navigate to Threats > Activity.
2. Select an event to open the event detail drawer.
3. Select the Respond tab.
4. Select an action from the list. Actions your account does not have permission to execute are grayed out.
5. Review the pre-populated fields. Some actions require additional inputs (for example, Isolate Network requires you to specify direction, protocol, CIDR, and port).
6. Select Execute.

From Resource 360

1. Open the Resource 360 panel for a resource.
2. Select the Response tab.
3. Select an action and follow the same steps as above.

From the Response History

For resources where you have previously taken actions, you can re-execute or undo a past action from the response history:

1. Open the Resource 360 panel.
2. Select the Response tab > View Response History.
3. Select a past action and choose Undo if an undo action is available, or select Re-execute to run the same action again.

Inputs Required Per Action Type

Different actions require different context. Sysdig pre-populates fields from the event or resource context where possible.

Action Type	Required Inputs
Process actions (Kill Process)	process.id, container.id, start time
Container actions (Kill, Stop, Pause)	container.id or container.name
File actions (Acquire File, Quarantine)	path.absolute; optionally destinationPath or s3.bucket
Pod actions (Delete Pod)	Kubernetes cluster, namespace, pod name
Workload actions (Isolate Network, Rollout Restart)	Kubernetes cluster, namespace, workload name and type
Network Isolate	Workload fields + network.direction (INGRESS or EGRESS), network.protocol, network.cidr, network.port
PVC actions (Volume Snapshot)	kubernetes.persistentvolume.claim.name
Cloud actions (IAM, EBS, CloudTrail)	AWS account ID, region, resource identifier
Fetch Cloud Logs	ct.user, ct.user.arn, ct.user.identitytype, fromTimestamp, toTimestamp

For Network Isolate, direction is specified as INGRESS or EGRESS — not inbound or outbound. Use the exact values shown in the Sysdig UI.

Status

Action Status

After you execute a response action, Sysdig polls for its status every 5 seconds. The action moves through the following states:

Status	Meaning
Created	The action request has been submitted
Enqueued	The responder has received the request and queued it
Running	The action is actively executing
Completed	The action finished successfully
Error	The action failed. The error detail explains the cause

If an action enters an Error state, review the error detail before retrying. Common causes include insufficient agent permissions, the target container or process no longer existing, or missing Kubernetes VolumeSnapshot support.

---

Response History

Every response action — whether it succeeds or fails — is recorded in the Response History. You can access history in two ways:

• Per-resource: Open Resource 360 for a resource and select Response > View Response History. The history panel shows all actions taken on that specific resource.
• Fleet-wide: Navigate to Threats > Response History for a searchable list of all actions across your environment.

The history includes who triggered each action, when, the action status, and any error details. For actions with undo pairs, the undo action is available directly from the history entry.

Scenarios

Recommended Sequences for Common Scenarios

Container Compromise

Run in this order to preserve evidence before containment:

1. Get Logs — Capture stdout/stderr before the container is stopped.
2. Acquire File — Download suspicious binaries or configuration files.
3. Kubernetes Volume Snapshot — Back up persistent data.
4. Kill Container or Pause Container — Stop the threat. Use Pause if you want to keep state for further investigation; use Kill for immediate termination.

AWS Credential Compromise

1. Fetch Cloud Logs — Retrieve CloudTrail logs to understand what the compromised identity has done.
2. IAM Quarantine — Apply a deny-all policy to the IAM user or role to prevent further API calls while you investigate.
3. IAM Unquarantine — Restore permissions after the identity is secured (password rotated, access keys revoked, MFA re-enrolled).

Network Exfiltration

1. Get Logs — Capture current network activity logs.
2. Kubernetes Volume Snapshot — Preserve data before isolation.
3. Isolate Network — Block all traffic to and from the workload.
4. Delete Network Policy — Restore normal traffic after the workload is cleaned up and redeployed.

Suspicious File Detected

1. Acquire File — Download the file for offline analysis.
2. File Quarantine — Move the file to the sandbox directory, making it non-executable.
3. File Unquarantine — Restore the file if analysis confirms it is benign.

Platform Support

Action Category	Linux	Windows	AIX	Kubernetes
Process actions	Yes	Yes	Yes	Yes (via host)
Container actions	Yes	Yes	—	Yes (via host)
File actions	Yes	Yes	Yes	Yes (via host)
Pod/workload actions	—	—	—	Yes (via cluster-shield)
Network Isolate	—	—	—	Yes (via cluster-shield)
Volume Snapshot (Kubernetes)	—	—	—	Yes (via cluster-shield)
Cloud actions (AWS)	—	—	—	Requires connected AWS account

---

Next Steps

• Configure Automations to trigger response actions automatically when a system health condition or alert fires, reducing the need for manual intervention.
• Set Up Cluster Shield to enable Kubernetes-level response actions in your clusters.
• Configure Permissions to assign containment and data-gathering execution rights to the appropriate teams.
• View Response History to audit all actions taken across your environment.