Kubernetes Client Certificate Signing Request Created or Approved

  1[metadata]
  2creation_date = "2026/05/05"
  3integration = ["kubernetes"]
  4maturity = "production"
  5updated_date = "2026/05/05"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects creation or approval of a Kubernetes CertificateSigningRequest (CSR) by a non-system identity. Attackers who
 11have gained cluster access can submit a CSR with a privileged Common Name such as system:kube-controller-manager or
 12system:masters, then approve it themselves to obtain a long-lived client certificate. Unlike service account tokens
 13which expire in hours, client certificates persist until they expire or the cluster CA is rotated, providing durable
 14access that survives pod termination, token revocation, and RBAC changes. On non-EKS clusters, the signed certificate
 15allows the attacker to authenticate as the privileged identity from anywhere without needing cluster network access,
 16making it one of the most persistent backdoor mechanisms available in Kubernetes.
 17"""
 18false_positives = [
 19    """
 20    Approved certificate workflows (for example cert-manager, internal PKI rotation, or node bootstrap) may create or
 21    update CSRs from identities not in the exclusion list if they run under a custom service account. Baseline
 22    automation that legitimately approves CSRs and tune exclusions for those principals.
 23    """,
 24]
 25from = "now-9m"
 26index = ["logs-kubernetes.audit_logs-*"]
 27language = "kuery"
 28license = "Elastic License v2"
 29name = "Kubernetes Client Certificate Signing Request Created or Approved"
 30note = """## Triage and analysis
 31
 32### Investigating Kubernetes Client Certificate Signing Request Created or Approved
 33
 34Identify the actor (`user.name`, groups), client (`user_agent.original`), and `source.ip`. Confirm whether the
 35principal is expected to create or approve CSRs. Review `kubernetes.audit.requestURI` and, when audit level captures
 36request bodies, the CSR `spec` (requested signer, usages, and requested identity / Common Name).
 37
 38### Extracting the Certificate Common Name
 39
 40For create events, "kubernetes.audit.requestObject.spec.request" holds the base64-encoded PEM certificate signing request.
 41Decode that value to PEM, then inspect the CSR subject (for example with OpenSSL’s CSR subject view) to read the
 42requested Common Name (CN). 
 43
 44Known base64 substrings that often appear inside the encoded request for high-risk identities:
 45
 46- `c3lzdGVtOm1hc3Rlcn` — `system:masters`
 47- `c3lzdGVtOmt1YmUtY29udHJvbGxlci1tYW5hZ2Vy` — `system:kube-controller-manager`
 48- `c3lzdGVtOmFkbWlu` — `system:admin`
 49
 50Priority CNs that usually indicate privilege escalation intent:
 51
 52- `system:masters` (cluster-admin group)
 53- `system:kube-controller-manager` (broad control-plane–style access, including secrets and token minting)
 54- `system:kube-scheduler` (scheduling across the cluster)
 55- `system:kube-proxy` (node/network–adjacent access)
 56- Any CN that matches an existing ClusterRoleBinding subject name
 57
 58### Possible investigation steps
 59
 60- Compare the CSR name and extracted CN against approved PKI or bootstrap processes.
 61- Determine whether the same identity both created and approved or patched the CSR in a short window, which matches
 62  self-approval abuse.
 63- Review `kubernetes.audit.objectRef` and subsequent authentication or API activity from unusual networks.
 64- Correlate with RBAC changes, secret access, or TokenRequest activity that preceded CSR activity.
 65
 66### Response and remediation
 67
 68- If malicious, deny further approval, delete or deny the CSR per incident policy, revoke or rotate cluster signing
 69  trust if the CA or signer was abused, and invalidate issued credentials.
 70- Remove excessive RBAC that allows `certificatesigningrequests` create/update/patch or approval for untrusted
 71  identities; enforce signer restrictions and approved issuers where supported.
 72"""
 73references = [
 74    "https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/",
 75    "https://attack.mitre.org/techniques/T1098/",
 76]
 77risk_score = 73
 78rule_id = "0f5941c6-3db9-4d2f-91df-06c7c292ba45"
 79severity = "high"
 80tags = [
 81    "Data Source: Kubernetes",
 82    "Domain: Kubernetes",
 83    "Use Case: Threat Detection",
 84    "Tactic: Persistence",
 85    "Tactic: Privilege Escalation",
 86    "Resources: Investigation Guide",
 87]
 88timestamp_override = "event.ingested"
 89type = "query"
 90query = '''
 91data_stream.dataset:"kubernetes.audit_logs" and 
 92kubernetes.audit.objectRef.resource:"certificatesigningrequests" and
 93kubernetes.audit.verb:("create" or "update" or "patch") and
 94kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and
 95not user.name:(
 96  system\:kube-controller-manager or
 97  system\:kube-scheduler or
 98  system\:node\:* or
 99  system\:serviceaccount\:kube-system\:* or
100  eks\:* or aksService
101)
102'''
103
104[[rule.threat]]
105framework = "MITRE ATT&CK"
106
107[[rule.threat.technique]]
108id = "T1098"
109name = "Account Manipulation"
110reference = "https://attack.mitre.org/techniques/T1098/"
111
112[[rule.threat.technique.subtechnique]]
113id = "T1098.006"
114name = "Additional Container Cluster Roles"
115reference = "https://attack.mitre.org/techniques/T1098/006/"
116
117[rule.threat.tactic]
118id = "TA0003"
119name = "Persistence"
120reference = "https://attack.mitre.org/tactics/TA0003/"
121
122[[rule.threat]]
123framework = "MITRE ATT&CK"
124
125[[rule.threat.technique]]
126id = "T1098"
127name = "Account Manipulation"
128reference = "https://attack.mitre.org/techniques/T1098/"
129
130[[rule.threat.technique.subtechnique]]
131id = "T1098.006"
132name = "Additional Container Cluster Roles"
133reference = "https://attack.mitre.org/techniques/T1098/006/"
134
135[rule.threat.tactic]
136id = "TA0004"
137name = "Privilege Escalation"
138reference = "https://attack.mitre.org/tactics/TA0004/"