Authorization bypass due to impersonate permissions on ServiceAccounts or Nodes in Kubernetes

Critical Risk infrastructure-security
kubernetesrbacauthorization-bypassimpersonationprivilege-escalationservice-accountscluster-security

What it is

Kubernetes RBAC configurations that grant impersonation permissions to ServiceAccounts or Node identities create severe authorization bypass vulnerabilities. Attackers who compromise these identities can impersonate other users, including cluster administrators, enabling unauthorized cluster operations and access to sensitive resources without proper authentication or audit trails.

# VULNERABLE: ServiceAccount with impersonation
apiVersion: v1
kind: ServiceAccount
metadata:
  name: automation-sa
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: vulnerable-automation-role
rules:
# VULNERABLE: Broad impersonation permissions
- apiGroups: [""]
  resources: ["users", "groups", "serviceaccounts"]
  verbs: ["impersonate"]
- apiGroups: ["authentication.k8s.io"]
  resources: ["userextras/*"]
  verbs: ["impersonate"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: vulnerable-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: vulnerable-automation-role
subjects:
- kind: ServiceAccount
  name: automation-sa
  namespace: kube-system
# SECURE: ServiceAccount without impersonation
apiVersion: v1
kind: ServiceAccount
metadata:
  name: automation-sa
  namespace: automation
automountServiceAccountToken: false
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secure-automation-role
rules:
# SECURE: Direct permissions only, no impersonation
- apiGroups: ["apps"]
  resources: ["deployments", "replicasets"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]
- apiGroups: [""]
  resources: ["pods", "services", "configmaps"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]
- apiGroups: [""]
  resources: ["events"]
  verbs: ["create"]
# SECURE: No impersonate verb granted
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: secure-automation-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: secure-automation-role
subjects:
- kind: ServiceAccount
  name: automation-sa
  namespace: automation

💡 Why This Fix Works

The vulnerable configuration grants the impersonate verb on users, groups, and serviceaccounts resources to a ServiceAccount, allowing it to assume any identity in the cluster including cluster administrators. The secure version removes all impersonation permissions and replaces them with direct, least-privilege permissions for the specific operations the ServiceAccount needs to perform, preventing authorization bypass and privilege escalation attacks.

Why it happens

Kubernetes ServiceAccounts granted the 'impersonate' verb on users, groups, or serviceaccounts resources through RBAC ClusterRoles or Roles. This allows compromised pods to impersonate any identity including cluster administrators, bypassing authentication and authorization controls.

Root causes

ServiceAccount Impersonation Permissions

Kubernetes ServiceAccounts granted the 'impersonate' verb on users, groups, or serviceaccounts resources through RBAC ClusterRoles or Roles. This allows compromised pods to impersonate any identity including cluster administrators, bypassing authentication and authorization controls.

Node Identity Impersonation

Node identities (system:nodes group members) configured with impersonation permissions. Compromised nodes can then impersonate any user or service account to access resources beyond their intended scope, enabling lateral movement and privilege escalation.

Overprivileged ClusterRoles

RBAC ClusterRoles with overly broad impersonate verb permissions across multiple resource types. These excessive permissions violate least-privilege principles and create pathways for authorization bypass through identity spoofing.

Legacy Authorization Patterns

Legacy RBAC configurations from older Kubernetes versions or migrated workloads that used impersonation as a workaround for inadequate RBAC granularity. These patterns persist without security review or refactoring to direct permissions.

Insufficient Permission Auditing

Organizations lack continuous auditing and review of RBAC permissions including dangerous verbs like 'impersonate'. Without regular permission scans, overprivileged roles persist undetected, and impersonation grants accumulate over time.

Fixes

1

Remove ServiceAccount Impersonation

Audit all ClusterRoles and Roles bound to ServiceAccounts and remove the 'impersonate' verb from rules. ServiceAccounts should never require impersonation - grant direct permissions for specific resources and operations instead.

2

Eliminate Node Impersonation Permissions

Remove impersonation permissions from all Node identity roles and ClusterRoles. Nodes should authenticate using their own identity (system:node:nodename) and should never impersonate other principals for legitimate operations.

3

Grant Direct Least-Privilege Permissions

Replace impersonation-based access with direct RBAC permissions scoped to specific resources using resourceNames, namespaces, and appropriate verbs. This provides equivalent access while maintaining proper authentication and audit trails.

4

Restrict to Human Administrators Only

If impersonation is required for debugging or administrative workflows, restrict it to highly privileged human administrator identities only. Use tightly scoped RBAC with resourceNames specifying exactly which identities can be impersonated and implement MFA requirements.

5

Implement Audit Monitoring

Deploy Kubernetes audit policies to log all impersonation attempts with detailed request information. Configure alerts for any impersonation events, especially those involving ServiceAccounts or Nodes, to detect potential abuse or misconfigurations.

Detect This Vulnerability in Your Code

Sourcery automatically identifies authorization bypass due to impersonate permissions on serviceaccounts or nodes in kubernetes and many other security issues in your codebase.