« GKE Pod Created with a Sensitive hostPath Volume GKE Pod Exec Potential Reverse Shell »
Elastic Docs ›Elastic Security [8.19] ›Detections and alerts ›Prebuilt rule reference

GKE Pod Exec Cloud Instance Metadata Access

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

GKE Pod Exec Cloud Instance Metadata Access

edit

Detects successful GKE pod exec sessions whose command references Google Cloud instance metadata endpoints, including metadata.google.internal, computeMetadata/v1, or the link-local metadata IP 169.254.169.254. Workloads that reach the GKE metadata service from an exec session are often attempting to harvest short-lived credentials or instance attributes from the node or workload identity boundary. That behavior is high risk because it can expose cloud credentials to code running inside a container. GKE records the command in gcp.audit.labels.command.gke.io/command when an explicit command is passed to exec.

Rule type: query

Rule indices:

  • logs-gcp.audit-*

Severity: high

Risk score: 73

Runs every: 5m

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

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Cloud
  • Domain: Kubernetes
  • Data Source: GCP
  • Data Source: GCP Audit Logs
  • Data Source: Google Cloud Platform
  • Use Case: Threat Detection
  • Tactic: Credential Access
  • Tactic: Execution
  • Resources: Investigation Guide

Version: 1

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating GKE Pod Exec Cloud Instance Metadata Access

This alert fires when a successful pods/exec API call includes a command targeting GKE/GCP instance metadata. Review gcp.audit.labels.command.gke.io/command for the full command string.

Possible investigation steps

  • Confirm the actor (client.user.email), source IP, and user agent that performed exec.
  • Map gcp.audit.resource_name to the target pod/namespace and determine whether the workload should ever call metadata.
  • Correlate with GCP audit logs for token issuance or IAM activity around the same time from the node or workload identity.
  • Hunt adjacent activity from the same identity: secret reads, additional execs, or RBAC changes.

False positive analysis

  • Approved platform tooling or bootstrap scripts may query metadata during startup; baseline those images and identities.
  • Break-glass egress/metadata connectivity tests can match; document and allowlist those principals.

Response and remediation

  • If unauthorized, terminate the session, isolate the workload, revoke or rotate instance and workload credentials that could have been read, and tighten pods/exec RBAC plus network policies that deny link-local metadata from pods.

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.type:start and
event.action:("io.k8s.core.v1.pods.exec.create" or "io.k8s.core.v1.pods.exec.get") and
gcp.audit.labels.command.gke.io/command:(
  *169.254.169.254* or *metadata.google.internal* or *computeMetadata/v1*
)

Framework: MITRE ATT&CKTM

« GKE Pod Created with a Sensitive hostPath Volume GKE Pod Exec Potential Reverse Shell »