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…
Description
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.
Detection logic
Its licence does not clear it for publishing here
Sunturai publishes a detection's own text where the licence it arrived under has been reviewed and permits it, and Elastic License 2.0 has not. The query as its source wrote it, its canonical form and the hash that pins this revision are in the workspace record.
Detection requirements
- Platform
- ContainersESXiIaaSIdentity ProviderLinuxmacOSNetwork DevicesOffice SuiteSaaSWindows
The rule states no platform. This is derived from the ATT&CK technique it maps to.
Known benign triggers
- Legitimate GKE automation does not request certificates for system:masters, system:kube-controller-manager, or system:admin as the CSR subject. Node bootstrap and kubelet rotation use system:node:* identities instead. Alerts should be rare; tune exclusions only for documented custom PKI workflows that intentionally mint these identities.
MITRE ATT&CK mappings
0 exclusive techniques.This is coverage no other published rule has; it is not this rule's total technique count.
References
| Reference | Cited by |
|---|---|
| kubernetes.io/docs/concepts/security/rbac-good-practices/ | 4 |
| kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/ | 6 |
| raesene.github.io/blog/2022/12/21/Kubernetes-persistence-with-Tocan-and-Teisteanas/ | 4 |
| rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/ | Only this detection cites it |
| stratus-red-team.cloud/attack-techniques/kubernetes/k8s.persistence.create-client-certificate/ | 4 |
From the source
- At source
- Open at source
- Upstream identifier
- 4159bec9-76ad-4cdc-a797-4a8572073bbe
- Tagged by the source as
- Data Source: GCPData Source: GCP Audit LogsData Source: Google Cloud PlatformDomain: CloudDomain: ContainersDomain: KubernetesNoise: UnknownPerformance: NormalPlatform: GCPPlatform: KubernetesResources: Investigation GuideRule Type: ES|QLTactic: PersistenceTactic: Privilege EscalationUse Case: Threat Detection
Licence
- Published under
- Elastic License 2.0Read the licence
- Attribution
- Required
Authorship
- Written by
- Published
- Sep 20, 2026
- Version
- 3