This detection rule flags GKE pod creation events in the kube-system namespace that attach a built-in kube-controller-manager service account to the pod. These accounts are admin-equivalent and are not normally mounted to arbitrary pods; if an attacker can create pods in kube-system, they may abuse the attached token to escalate privileges across the cluster. The rule analyzes GCP audit logs (data_stream.dataset:gcp.audit) for pod creation where event.action is io.k8s.core.v1.pods.create and gcp.audit.request.spec.serviceAccountName matches a set of built-in controller accounts (e.g., attachdetach-controller, certificate-controller, cloud-provider, clusterrole-aggregation-controller, cronjob-controller, daemon-set-controller, deployment-controller, disruption-controller, endpoint-controller, and others). It also inspects related fields such as client.user.email and container images. The event’s success (event.outcome: success) and the namespace kube-system are key signals. This aligns with MITRE ATT&CK techniques T1078 (Default Accounts) and T1610 (Deploy Container) under Privilege Escalation and Execution, respectively. Investigations should review who created the pod (client.user.email), the requested serviceAccountName, and the container images, and determine whether the operation is consistent with documented platform automation. False positives are expected to be rare; if there is a documented automation baseline, an allowlist may be appropriate. Remediation includes deleting the suspicious pod, revoking the service account token, and tightening pod-create permissions in kube-system; enforce least privilege RBAC and rotate/restrict credentials as needed. Setup prerequisite: enable the GCP Fleet integration with GKE audit logs. References point to Kubernetes RBAC guidance and privilege-escalation discussions. Risk score is 47 and severity is medium.