Kubelet Certificate File Access Detected via Defend for Containers

  1[metadata]
  2creation_date = "2026/02/02"
  3integration = ["cloud_defend"]
  4maturity = "production"
  5min_stack_comments = "Defend for Containers integration was re-introduced in 9.3.0"
  6min_stack_version = "9.3.0"
  7updated_date = "2026/02/09"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12This rule detects the access of the Kubelet certificate file inside a container. The Kubelet certificate file is
 13used to authenticate the container to the Kubernetes API server, and may be used by an adversary to gain access
 14to the Kubernetes API server or other resources within the cluster. These files are a common target for adversaries
 15to gain access to the cluster. There is a current limitation in the defend for containers file sensor that prevents
 16file open events from being logged for file open events without write intent. 
 17"""
 18from = "now-6m"
 19index = ["logs-cloud_defend.file*", "logs-cloud_defend.process*"]
 20interval = "5m"
 21language = "eql"
 22license = "Elastic License v2"
 23name = "Kubelet Certificate File Access Detected via Defend for Containers"
 24note = """ ## Triage and analysis
 25
 26> **Disclaimer**:
 27> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
 28
 29### Investigating Kubelet Certificate File Access Detected via Defend for Containers
 30
 31This detection flags an interactive process inside a Linux container opening files under `/var/lib/kubelet/pki/`, which includes the kubelet client certificate and key used to authenticate to the Kubernetes API. Attackers who obtain these credentials can impersonate the node, enumerate cluster resources, and pivot to secrets or workloads. A common pattern is an operator exec’ing into a compromised pod, locating the kubelet cert/key pair, copying it out, then using it to query the API server from outside the container.
 32
 33### Possible investigation steps
 34
 35- Identify the pod/namespace/node and owning controller for the container, then confirm whether it should ever have access to host kubelet PKI (e.g., privileged DaemonSet, hostPath mount, node-agent tooling) or if this is an unexpected breakout indicator.
 36- Review the interactive session context (exec/attach/ssh), including who initiated it and the command history/TTY telemetry around the alert time, to determine whether this was routine debugging or suspicious enumeration.
 37- Inspect the container filesystem and recent file operations for evidence of credential harvesting (reads of kubelet client cert/key pairs, copies to temporary paths, archive creation, or outbound transfer tooling) and preserve artifacts for forensics.
 38- Correlate immediately after the access event for Kubernetes API activity using node credentials (unusual discovery, secret access, or cluster-wide queries) originating from the same workload identity, node, or egress address.
 39- Validate whether kubelet credentials were reused by reviewing API server audit logs for unexpected node identity actions, and rotate kubelet client certs/keys and isolate the workload if misuse is suspected.
 40
 41### False positive analysis
 42
 43- A cluster operator or SRE may exec into a privileged pod (e.g., a DaemonSet with hostPath access to `/var/lib/kubelet`) for node troubleshooting and use interactive shell commands to inspect or validate kubelet PKI files during incident response or routine maintenance.
 44- A legitimate containerized node-management or diagnostic workflow that runs interactively (e.g., invoked manually for verification) may open files under `/var/lib/kubelet/pki/` as part of validating kubelet certificate presence/permissions after upgrades, certificate rotation, or node reconfiguration.
 45
 46### Response and remediation
 47
 48- Immediately isolate the affected workload by scaling the pod/controller to zero or cordoning and draining the node if a privileged pod has host access to `/var/lib/kubelet/pki/`, and preserve the container filesystem and process list for forensics before teardown.  
 49- Remove the execution path that enabled access by deleting or patching the pod/DaemonSet to drop `privileged`, `hostPID/hostNetwork`, and any `hostPath` mounts that expose `/var/lib/kubelet` and redeploy only from a known-good image and manifest.  
 50- Rotate and reissue kubelet client certificates/keys on the impacted node(s) (or replace the node from autoscaling/immutable infrastructure) and verify the old credentials can no longer authenticate to the Kubernetes API server.  
 51- Review Kubernetes API server audit logs for activity using the node identity around the access time (cluster-wide discovery, secret reads, token reviews, exec into other pods) and revoke/rotate any exposed service account tokens or secrets accessed during the window.  
 52- Escalate to the Kubernetes platform/on-call security team immediately if the files include a kubelet client key, if the pod was privileged or had host mounts, or if API audit logs show node credential use from unexpected sources or unusual resource enumeration.  
 53- Harden the cluster by enforcing policies that block hostPath access to `/var/lib/kubelet` and privileged pods (Pod Security Admission/Gatekeeper/Kyverno), limiting interactive exec/attach via RBAC, and monitoring for subsequent access attempts to kubelet PKI paths and related credential exfiltration tooling.
 54"""
 55references = [
 56    "https://heilancoos.github.io/research/2025/12/16/kubernetes.html#kubelet-api",
 57    "https://www.cyberark.com/resources/threat-research-blog/using-kubelet-client-to-attack-the-kubernetes-cluster",
 58    "https://www.aquasec.com/blog/kubernetes-exposed-exploiting-the-kubelet-api/"
 59]
 60risk_score = 21
 61rule_id = "42de0740-8ed8-4b8b-995c-635b56a8bbf4"
 62severity = "low"
 63tags = [
 64    "Data Source: Elastic Defend for Containers",
 65    "Domain: Container",
 66    "OS: Linux",
 67    "Use Case: Threat Detection",
 68    "Tactic: Discovery",
 69    "Resources: Investigation Guide",
 70]
 71timestamp_override = "event.ingested"
 72type = "eql"
 73query = '''
 74any where host.os.type == "linux" and process.interactive == true and container.id like "*" and (
 75  (event.category == "file" and event.type == "change" and event.action == "open" and file.path like "/var/lib/kubelet/pki/*") or
 76  (event.category == "process" and event.type == "start" and event.action == "exec" and
 77  (
 78    process.name in ("cat", "head", "tail", "more", "less", "sed", "awk") or
 79    process.args in (
 80      "cat", "/bin/cat", "/usr/bin/cat", "/usr/local/bin/cat",
 81      "head", "/bin/head", "/usr/bin/head", "/usr/local/bin/head",
 82      "tail", "/bin/tail", "/usr/bin/tail", "/usr/local/bin/tail",
 83      "more", "/bin/more", "/usr/bin/more", "/usr/local/bin/more",
 84      "less", "/bin/less", "/usr/bin/less", "/usr/local/bin/less",
 85      "sed", "/bin/sed", "/usr/bin/sed", "/usr/local/bin/sed",
 86      "awk", "/bin/awk", "/usr/bin/awk", "/usr/local/bin/awk"
 87    )
 88  ) and process.args like "*/var/lib/kubelet/pki/*")
 89)
 90'''
 91
 92[[rule.threat]]
 93framework = "MITRE ATT&CK"
 94
 95[[rule.threat.technique]]
 96id = "T1613"
 97name = "Container and Resource Discovery"
 98reference = "https://attack.mitre.org/techniques/T1613/"
 99
100[rule.threat.tactic]
101id = "TA0007"
102name = "Discovery"
103reference = "https://attack.mitre.org/tactics/TA0007/"