GKE Certificate Signing Request for Privileged Identity

Detects creation of a GKE CertificateSigningRequest (CSR) whose decoded subject requests a highly privileged Kubernetes identity in the Common Name (CN), such as system:masters, system:kube-controller-manager, or system:admin. This rule is scoped to identities with cluster-admin-equivalent or control-plane impersonation value. Attackers who can create and approve CSRs can use this technique to clone credentials for powerful identities and obtain durable cluster access. This signal applies to any actor, including compromised node identities that use legitimate kubelet signers but request a privileged CN.

Elastic rule (View on GitHub)

 1[metadata]
 2creation_date = "2026/07/10"
 3integration = ["gcp"]
 4maturity = "production"
 5min_stack_comments = "Requires ES|QL JSON_EXTRACT on _source to read gcp.audit.request.spec.request from flattened request bodies."
 6min_stack_version = "9.4.0"
 7updated_date = "2026/07/10"
 8
 9[rule]
10author = ["Elastic"]
11description = """
12Detects creation of a GKE CertificateSigningRequest (CSR) whose decoded subject requests a highly privileged
13Kubernetes identity in the Common Name (CN), such as system:masters, system:kube-controller-manager, or system:admin.
14This rule is scoped to identities with cluster-admin-equivalent or control-plane impersonation value. Attackers who can
15create and approve CSRs can use this technique to clone credentials for powerful identities and obtain durable cluster
16access. This signal applies to any actor, including compromised node identities that use legitimate kubelet signers
17but request a privileged CN.
18"""
19false_positives = [
20    """
21    Legitimate GKE automation does not request certificates for system:masters, system:kube-controller-manager, or
22    system:admin as the CSR subject. Node bootstrap and kubelet rotation use system:node:* identities instead. Alerts
23    should be rare; tune exclusions only for documented custom PKI workflows that intentionally mint these identities.
24    """,
25]
26from = "now-6m"
27language = "esql"
28license = "Elastic License v2"
29name = "GKE Certificate Signing Request for Privileged Identity"
30note = """## Triage and analysis
31
32### Investigating GKE Certificate Signing Request for Privileged Identity
33
34This rule uses `JSON_EXTRACT(_source, "$.gcp.audit.request.spec.request")` to read the outer base64 CSR from CSR
35create events, double-decodes it to DER in `Esql.csr_der`, and matches privileged Common Names. It is scoped to
36identities with cluster-admin-equivalent or control-plane impersonation value (`system:masters`, `system:kube-controller-manager`,
37and `system:admin`). The alert includes `Esql.csr_pem` and `Esql.csr_der` so the requested identity is visible without
38manual decoding.
39
40To validate manually from the create event:
41
42```bash
43# Full decoded PEM block
44echo "<gcp.audit.request.spec.request>" | base64 -d
45
46# Parsed CSR details (subject, key type/size, extensions, signature)
47echo "<gcp.audit.request.spec.request>" | base64 -d | openssl req -noout -text
48
49# Subject only
50echo "<gcp.audit.request.spec.request>" | base64 -d | openssl req -noout -subject

Matched privileged identities:

• system:masters (cluster-admin group)
• system:kube-controller-manager
• system:admin

Possible investigation steps

• Identify client.user.email, source.ip, and whether the actor is expected to request certificates for these identities.
• Review gcp.audit.request.spec.signerName to determine which certificate authority would sign the request.
• Check for self-approval or controller approval on the same gcp.audit.resource_name within a short window.
• Correlate with secret reads, RBAC changes, or TokenRequest activity from the same actor.

False positive analysis

• Known control-plane and kube-system identities do not legitimately create CSRs for these subjects in GKE; any match warrants review.

Related rules

• GKE Certificate Signing Request API Client Signer Requested - 1e344fba-a2f7-462b-aaec-d6c8f80d5a28
• GKE Certificate Signing Request Self-Approved - e155e658-3dcd-4d27-a4e5-1d8da6704b0e
• GKE Client Certificate Signing Request Created or Approved - ec67ab57-945a-4edb-84f8-1d7a51f46544

Response and remediation

• Deny or delete the CSR, revoke issued credentials if already signed, and tighten CSR create/approval RBAC.

""" setup = "The GCP Fleet integration with GKE audit logs enabled is required. Request body capture for CSR create events (gcp.audit.request.spec.request) typically requires RequestResponse audit level on CertificateSigningRequest resources." references = [ "https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/", "https://kubernetes.io/docs/concepts/security/rbac-good-practices/", "https://raesene.github.io/blog/2022/12/21/Kubernetes-persistence-with-Tocan-and-Teisteanas/", "https://stratus-red-team.cloud/attack-techniques/kubernetes/k8s.persistence.create-client-certificate/", "https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/", ] risk_score = 73 rule_id = "4159bec9-76ad-4cdc-a797-4a8572073bbe" severity = "high" 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", ] timestamp_override = "event.ingested" type = "esql"

query = ''' from logs-gcp.audit-* metadata _id, _index, _version, _source | where data_stream.dataset == "gcp.audit" and service.name == "k8s.io" and event.outcome == "success" and event.action == "io.k8s.certificates.v1.certificatesigningrequests.create" | eval Esql.csr_request = json_extract(_source, "$.gcp.audit.request.spec.request") | where Esql.csr_request is not null | eval Esql.csr_pem = from_base64(Esql.csr_request) | eval Esql.csr_body_b64 = replace( replace( replace( replace(Esql.csr_pem, "-----BEGIN CERTIFICATE REQUEST-----", ""), "-----END CERTIFICATE REQUEST-----", ""), "\r", ""), "\n", "") | eval Esql.csr_der = from_base64(Esql.csr_body_b64) | where Esql.csr_der like "system:masters" or Esql.csr_der like "system:kube-controller-manager" or Esql.csr_der like "system:admin" | keep _id, _index, _version, @timestamp, client.user.email, gcp.audit.resource_name, source.ip, user_agent.original, Esql., event., gcp.audit.request, gcp.audit.response, data_stream.namespace '''

[[rule.threat]] framework = "MITRE ATT&CK"

[[rule.threat.technique]] id = "T1098" name = "Account Manipulation" reference = "https://attack.mitre.org/techniques/T1098/"

[[rule.threat.technique.subtechnique]] id = "T1098.006" name = "Additional Container Cluster Roles" reference = "https://attack.mitre.org/techniques/T1098/006/"

[rule.threat.tactic] id = "TA0004" name = "Privilege Escalation" reference = "https://attack.mitre.org/tactics/TA0004/"

[[rule.threat]] framework = "MITRE ATT&CK"

[[rule.threat.technique]] id = "T1098" name = "Account Manipulation" reference = "https://attack.mitre.org/techniques/T1098/"

[[rule.threat.technique.subtechnique]] id = "T1098.006" name = "Additional Container Cluster Roles" reference = "https://attack.mitre.org/techniques/T1098/006/"

[rule.threat.tactic] id = "TA0003" name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/"

[rule.investigation_fields] field_names = [ "@timestamp", "client.user.email", "source.ip", "user_agent.original", "event.action", "event.outcome", "gcp.audit.resource_name", "Esql.csr_request", "Esql.csr_pem", "Esql.csr_der", "data_stream.namespace", ]

Triage and analysis

Investigating GKE Certificate Signing Request for Privileged Identity

This rule uses JSON_EXTRACT(_source, "$.gcp.audit.request.spec.request") to read the outer base64 CSR from CSR create events, double-decodes it to DER in Esql.csr_der, and matches privileged Common Names. It is scoped to identities with cluster-admin-equivalent or control-plane impersonation value (system:masters, system:kube-controller-manager, and system:admin). The alert includes Esql.csr_pem and Esql.csr_der so the requested identity is visible without manual decoding.

To validate manually from the create event:

1# Full decoded PEM block
2echo "<gcp.audit.request.spec.request>" | base64 -d
3
4# Parsed CSR details (subject, key type/size, extensions, signature)
5echo "<gcp.audit.request.spec.request>" | base64 -d | openssl req -noout -text
6
7# Subject only
8echo "<gcp.audit.request.spec.request>" | base64 -d | openssl req -noout -subject

Matched privileged identities:

• system:masters (cluster-admin group)
• system:kube-controller-manager
• system:admin

Possible investigation steps

• Identify client.user.email, source.ip, and whether the actor is expected to request certificates for these identities.
• Review gcp.audit.request.spec.signerName to determine which certificate authority would sign the request.
• Check for self-approval or controller approval on the same gcp.audit.resource_name within a short window.
• Correlate with secret reads, RBAC changes, or TokenRequest activity from the same actor.

False positive analysis

• Known control-plane and kube-system identities do not legitimately create CSRs for these subjects in GKE; any match warrants review.

Related rules

• GKE Certificate Signing Request API Client Signer Requested - 1e344fba-a2f7-462b-aaec-d6c8f80d5a28
• GKE Certificate Signing Request Self-Approved - e155e658-3dcd-4d27-a4e5-1d8da6704b0e
• GKE Client Certificate Signing Request Created or Approved - ec67ab57-945a-4edb-84f8-1d7a51f46544

Response and remediation

• Deny or delete the CSR, revoke issued credentials if already signed, and tighten CSR create/approval RBAC.