LoFP LoFP / approved certificate workflows (for example cert-manager, internal pki rotation, or node bootstrap) may create or update csrs from identities not in the exclusion list if they run under a custom service account. baseline automation that legitimately approves csrs and tune exclusions for those principals.

Techniques

Sample rules

GKE Client Certificate Signing Request Created or Approved

Description

Detects creation or approval of a GKE CertificateSigningRequest (CSR) by a non-system identity. This is a breadth baseline rule for human or custom automation CSR activity on GKE. Attackers with cluster access can submit and approve CSRs to obtain long-lived client certificates that survive token revocation and RBAC changes. Use companion rules to evaluate signer choice, requested identity, and self-approval behavior.

Detection logic

data_stream.dataset:"gcp.audit" and service.name:"k8s.io" and event.outcome:"success" and
event.action:(
  "io.k8s.certificates.v1.certificatesigningrequests.create" or
  "io.k8s.certificates.v1.certificatesigningrequests.approval.update"
) and not client.user.email:(
  "system:gcp-controller-manager" or
  "system:kube-controller-manager" or
  "system:serviceaccount:kube-system:certificate-controller"
) and not (
  event.action:"io.k8s.certificates.v1.certificatesigningrequests.create" and
  client.user.email:(
    "kubelet-bootstrap" or
    "kubelet-nodepool-bootstrap" or
    system\:node\:*
  )
)

Kubernetes Client Certificate Signing Request Created or Approved

Description

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.

Detection logic

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
)