GKE Ephemeral Container Added to Pod

IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

GKE Ephemeral Container Added to Pod

Detects allowed updates or patches to the pods/ephemeralcontainers subresource on GKE by a non-system identity. Ephemeral containers are commonly used for debugging (kubectl debug) but can also be abused to inject tooling into a running pod, access mounted secrets, and execute commands in the target pod context. Attackers with sufficient RBAC may use ephemeral containers to escalate privileges, move laterally, or establish persistence without deploying a new workload.

Rule type: query

Rule indices:

logs-gcp.audit-*

Severity: medium

Risk score: 47

Runs every: 5m

Searches indices from: now-6m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/

Tags:

Domain: Cloud
Domain: Kubernetes
Data Source: GCP
Data Source: Google Cloud Platform
Use Case: Threat Detection
Tactic: Privilege Escalation
Tactic: Execution
Resources: Investigation Guide

Version: 1

Rule authors:

Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating GKE Ephemeral Container Added to Pod

Ephemeral containers allow adding a container to an existing pod for troubleshooting. When abused, they can gain interactive access to a workload, read sensitive files, and run tools that were not present in the original image.

Possible investigation steps

Review client.user.email, source.ip, and user_agent.original and confirm the identity is authorized to use ephemeral containers.
Inspect gcp.audit.resource_name to identify the targeted pod and owning workload.
If request bodies are captured, review the ephemeral container image, command, and securityContext for privilege indicators.
Correlate with follow-on audit activity such as pod exec, secret reads, TokenRequest, or RBAC modifications.

False positive analysis

Approved on-call debugging with kubectl debug may match. Allowlist known admin identities after review.

Response and remediation

If unauthorized, remove excessive RBAC that grants update or patch on pods/ephemeralcontainers and rotate exposed credentials.
Quarantine or redeploy impacted workloads and hunt for additional compromised pods or identities.

Setup

edit

The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule.

Rule query

edit

data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and
event.action:(
  "io.k8s.core.v1.pods.ephemeralcontainers.update" or
  "io.k8s.core.v1.pods.ephemeralcontainers.patch"
) and not client.user.email:(
  system\:node\:* or
  system\:serviceaccount\:kube-system\:*
)

Framework: MITRE ATT&CK^TM

Tactic:
- Name: Privilege Escalation
- ID: TA0004
- Reference URL: https://attack.mitre.org/tactics/TA0004/
Technique:
- Name: Escape to Host
- ID: T1611
- Reference URL: https://attack.mitre.org/techniques/T1611/
Tactic:
- Name: Execution
- ID: TA0002
- Reference URL: https://attack.mitre.org/tactics/TA0002/
Technique:
- Name: Container Administration Command
- ID: T1609
- Reference URL: https://attack.mitre.org/techniques/T1609/

« GKE Creation or Modification of Sensitive Role GKE Exposed Service Created With Type NodePort »