« Kubernetes Anonymous User Create/Update/Patch Pods Request Kubernetes Cluster-Admin Role Binding Created »
Elastic Docs ›Elastic Security [8.19] ›Detections and alerts ›Prebuilt rule reference

Kubernetes Client Certificate Signing Request Created or Approved

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

Kubernetes Client Certificate Signing Request Created or Approved

edit

Detects creation or approval of a Kubernetes CertificateSigningRequest (CSR) by a non-system identity. Attackers who have gained cluster access can submit a CSR with a privileged Common Name such as system:kube-controller-manager or system:masters, then approve it themselves to obtain a long-lived client certificate. Unlike service account tokens which expire in hours, client certificates persist until they expire or the cluster CA is rotated, providing durable access that survives pod termination, token revocation, and RBAC changes. On non-EKS clusters, the signed certificate allows the attacker to authenticate as the privileged identity from anywhere without needing cluster network access, making it one of the most persistent backdoor mechanisms available in Kubernetes.

Rule type: query

Rule indices:

  • logs-kubernetes.audit_logs-*

Severity: high

Risk score: 73

Runs every: 5m

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

Maximum alerts per execution: 100

References:

Tags:

  • Data Source: Kubernetes
  • Domain: Kubernetes
  • Use Case: Threat Detection
  • Tactic: Persistence
  • Tactic: Privilege Escalation
  • Resources: Investigation Guide

Version: 1

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Kubernetes Client Certificate Signing Request Created or Approved

Identify the actor (user.name, groups), client (user_agent.original), and source.ip. Confirm whether the principal is expected to create or approve CSRs. Review kubernetes.audit.requestURI and, when audit level captures request bodies, the CSR spec (requested signer, usages, and requested identity / Common Name).

Extracting the Certificate Common Name

For create events, "kubernetes.audit.requestObject.spec.request" holds the base64-encoded PEM certificate signing request. Decode that value to PEM, then inspect the CSR subject (for example with OpenSSL’s CSR subject view) to read the requested Common Name (CN).

Known base64 substrings that often appear inside the encoded request for high-risk identities:

  • c3lzdGVtOm1hc3Rlcn — system:masters
  • c3lzdGVtOmt1YmUtY29udHJvbGxlci1tYW5hZ2Vy — system:kube-controller-manager
  • c3lzdGVtOmFkbWlu — system:admin

Priority CNs that usually indicate privilege escalation intent:

  • system:masters (cluster-admin group)
  • system:kube-controller-manager (broad control-plane–style access, including secrets and token minting)
  • system:kube-scheduler (scheduling across the cluster)
  • system:kube-proxy (node/network–adjacent access)
  • Any CN that matches an existing ClusterRoleBinding subject name

Possible investigation steps

  • Compare the CSR name and extracted CN against approved PKI or bootstrap processes.
  • Determine whether the same identity both created and approved or patched the CSR in a short window, which matches self-approval abuse.
  • Review kubernetes.audit.objectRef and subsequent authentication or API activity from unusual networks.
  • Correlate with RBAC changes, secret access, or TokenRequest activity that preceded CSR activity.

Response and remediation

  • If malicious, deny further approval, delete or deny the CSR per incident policy, revoke or rotate cluster signing trust if the CA or signer was abused, and invalidate issued credentials.
  • Remove excessive RBAC that allows certificatesigningrequests create/update/patch or approval for untrusted identities; enforce signer restrictions and approved issuers where supported.

Rule query

edit
data_stream.dataset:"kubernetes.audit_logs" and
kubernetes.audit.objectRef.resource:"certificatesigningrequests" and
kubernetes.audit.verb:("create" or "update" or "patch") and
kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and
not user.name:(
  system\:kube-controller-manager or
  system\:kube-scheduler or
  system\:node\:* or
  system\:serviceaccount\:kube-system\:* or
  eks\:* or aksService
)

Framework: MITRE ATT&CKTM

« Kubernetes Anonymous User Create/Update/Patch Pods Request Kubernetes Cluster-Admin Role Binding Created »