« GKE Certificate Signing Request Self-Approved GKE Exposed Service Created With Type NodePort »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.28

GKE 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.

GKE Client Certificate Signing Request Created or Approved

edit

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.

Rule type: query

Rule indices:

  • logs-gcp.audit-*

Severity: medium

Risk score: 47

Runs every: 5m

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

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Cloud
  • Domain: Kubernetes
  • Data Source: GCP
  • Data Source: GCP Audit Logs
  • Data Source: Google Cloud Platform
  • 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 GKE Client Certificate Signing Request Created or Approved

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

Extracting the Certificate Common Name

For create events, gcp.audit.request.spec.request may hold the base64-encoded PEM certificate signing request. On GKE this is base64 of the full PEM CSR. Decode and inspect the subject for high-risk Common Names such as system:masters, system:kube-controller-manager, and system:admin. The companion rule "GKE Certificate Signing Request Privileged Identity Requested" decodes the CSR body and matches those identities automatically.

*Full decoded PEM block*

echo "<gcp.audit.request.spec.request>" | base64 -d


*Parsed CSR details (subject, key type/size, extensions, signature)*

echo "<gcp.audit.request.spec.request>" | base64 -d | openssl req -noout -text


*Subject only*

echo "<gcp.audit.request.spec.request>" | base64 -d | openssl req -noout -subject

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 the CSR in a short window (approval.update, update, or patch), which matches self-approval abuse.
  • Review gcp.audit.resource_name and subsequent authentication or API activity from unusual networks.
  • Correlate with RBAC changes, secret access, or TokenRequest activity that preceded CSR activity.

False positive analysis

  • Admins testing CSR workflows with kubectl are common in lab clusters. Baseline expected operators and tune exclusions.
  • cert-manager or custom PKI automation outside the exclusion list may create or approve CSRs during normal rotation.

Related rules

  • GKE Certificate Signing Request API Client Signer Requested - 1e344fba-a2f7-462b-aaec-d6c8f80d5a28
  • GKE Certificate Signing Request Privileged Identity Requested - 4159bec9-76ad-4cdc-a797-4a8572073bbe
  • GKE Certificate Signing Request Self-Approved - e155e658-3dcd-4d27-a4e5-1d8da6704b0e

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.

Setup

edit

The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule.

Rule query

edit
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\:*
  )
)

Framework: MITRE ATT&CKTM

« GKE Certificate Signing Request Self-Approved GKE Exposed Service Created With Type NodePort »