GKE Suspicious Assignment of Controller Service Account

IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

GKE Suspicious Assignment of Controller Service Account

Detects a request to attach a built-in kube-controller-manager service account to a pod running in the kube-system namespace on GKE. These service accounts are admin-equivalent and are not normally assigned to arbitrary pods. An attacker who can create pods in kube-system can abuse these tokens for cluster-wide privilege escalation.

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: Google Cloud Platform
Use Case: Threat Detection
Tactic: Execution
Tactic: Privilege Escalation
Resources: Investigation Guide

Version: 1

Rule authors:

Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating GKE Suspicious Assignment of Controller Service Account

This rule flags pod create events in kube-system that assign a built-in kube-controller-manager service account.

Possible investigation steps

Review client.user.email, gcp.audit.request.spec.serviceAccountName, and container images.
Determine whether the pod aligns with expected platform operations.
Assess permissions of the assigned service account and hunt for follow-on secret or RBAC activity.

False positive analysis

Built-in controller service accounts should not be mounted on user-created pods. Allowlist known automation by actor if a documented exception exists.

Response and remediation

Delete suspicious pods, revoke the service account token, and restrict pod create permissions in kube-system.

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.core.v1.pods.create" and gcp.audit.request.metadata.namespace:"kube-system" and
gcp.audit.request.spec.serviceAccountName:(
  attachdetach-controller or certificate-controller or cloud-provider or
  clusterrole-aggregation-controller or cronjob-controller or daemon-set-controller or deployment-controller or
  disruption-controller or endpoint-controller or expand-controller or generic-garbage-collector or
  horizontal-pod-autoscaler or job-controller or namespace-controller or node-controller or
  persistent-volume-binder or pod-garbage-collector or pv-protection-controller or pvc-protection-controller or
  replicaset-controller or replication-controller or resourcequota-controller or root-ca-cert-publisher or
  route-controller or service-account-controller or service-controller or statefulset-controller or ttl-controller
)

Framework: MITRE ATT&CK^TM

Tactic:
- Name: Privilege Escalation
- ID: TA0004
- Reference URL: https://attack.mitre.org/tactics/TA0004/
Technique:
- Name: Valid Accounts
- ID: T1078
- Reference URL: https://attack.mitre.org/techniques/T1078/
Sub-technique:
- Name: Default Accounts
- ID: T1078.001
- Reference URL: https://attack.mitre.org/techniques/T1078/001/
Tactic:
- Name: Execution
- ID: TA0002
- Reference URL: https://attack.mitre.org/tactics/TA0002/
Technique:
- Name: Deploy Container
- ID: T1610
- Reference URL: https://attack.mitre.org/techniques/T1610/

« GKE Service Account Token Created via TokenRequest API GKE Suspicious Self-Subject Review via Service Account »