GKE User Exec into Pod
Detects the first occurrence of a non-system GKE identity establishing an exec session into a pod. kubectl exec enables interactive command execution inside workloads and is a common post-compromise technique to access secrets and expand access.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2026/06/30"
3integration = ["gcp"]
4maturity = "production"
5updated_date = "2026/06/30"
6
7[rule]
8author = ["Elastic"]
9description = """
10Detects the first occurrence of a non-system GKE identity establishing an exec session into a pod. kubectl exec enables
11interactive command execution inside workloads and is a common post-compromise technique to access secrets and expand
12access.
13"""
14false_positives = [
15 """
16 Administrators routinely exec into pods for troubleshooting. Baseline expected users and target pods, then exclude
17 known break-glass identities.
18 """,
19]
20from = "now-6m"
21index = ["logs-gcp.audit-*"]
22language = "kuery"
23license = "Elastic License v2"
24name = "GKE User Exec into Pod"
25note = """## Triage and analysis
26
27### Investigating GKE User Exec into Pod
28
29This new-terms rule alerts on the first exec into a given pod by a user identity in the lookback window.
30
31### Investigation steps
32
33- Review `user.email`, `orchestrator.resource.name`, `source.ip`, and `user_agent.original`.
34- Determine whether the target pod holds sensitive data or cluster credentials.
35- Correlate with secret access or RBAC changes from the same identity.
36
37### False positives
38
39- Approved admin debugging; exclude stable operator identities after review.
40
41## Setup
42
43The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule."""
44references = [
45 "https://kubernetes.io/docs/tasks/debug/debug-application/get-shell-running-container/",
46]
47risk_score = 47
48rule_id = "c040c962-1c60-4259-8ea3-601a40d4ab9f"
49severity = "medium"
50tags = [
51 "Domain: Cloud",
52 "Domain: Kubernetes",
53 "Data Source: GCP",
54 "Data Source: Google Cloud Platform",
55 "Use Case: Threat Detection",
56 "Tactic: Execution",
57 "Resources: Investigation Guide",
58]
59timestamp_override = "event.ingested"
60type = "new_terms"
61
62query = '''
63data_stream.dataset:gcp.audit and event.action:("io.k8s.core.v1.pods.exec.create" or "io.k8s.core.v1.pods.exec.get") and
64not user.email:system\:*
65'''
66
67[rule.new_terms]
68field = "new_terms_fields"
69value = ["user.email", "orchestrator.resource.name"]
70
71[[rule.new_terms.history_window_start]]
72field = "history_window_start"
73value = "now-7d"
74
75[[rule.threat]]
76framework = "MITRE ATT&CK"
77
78[[rule.threat.technique]]
79id = "T1609"
80name = "Container Administration Command"
81reference = "https://attack.mitre.org/techniques/T1609/"
82
83[rule.threat.tactic]
84id = "TA0002"
85name = "Execution"
86reference = "https://attack.mitre.org/tactics/TA0002/"
Triage and analysis
Investigating GKE User Exec into Pod
This new-terms rule alerts on the first exec into a given pod by a user identity in the lookback window.
Investigation steps
- Review
user.email,orchestrator.resource.name,source.ip, anduser_agent.original. - Determine whether the target pod holds sensitive data or cluster credentials.
- Correlate with secret access or RBAC changes from the same identity.
False positives
- Approved admin debugging; exclude stable operator identities after review.
Setup
The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule.
References
Related rules
- GKE Container Created with Excessive Linux Capabilities
- GKE Pod Created With HostIPC
- GKE Pod Created With HostNetwork
- GKE Pod Created With HostPID
- GKE Pod Created with a Sensitive hostPath Volume