Hardening Kubernetes RBAC: Securing Service Account Tokens

By default, every Kubernetes pod is associated with a ServiceAccount. When launched, Kubernetes automatically mounts the account's authentication token inside the container filesystem.

---

The Exploit Path

If an application running in a pod is compromised via Remote Code Execution (RCE) or Local File Inclusion (LFI), the attacker can read the token file:

cat /var/run/secrets/kubernetes.io/serviceaccount/token

If the default service account has wide RBAC roles (such as read/write permissions on secrets or namespaces), the attacker can control the entire cluster plane using this token.

---

Cluster Hardening Safeguards

1. Disable Automounting

If the pod doesn't need to communicate with the Kubernetes API server, disable token automounting inside the Pod spec:

apiversion: v1
kind: Pod
metadata:
  name: web-app
spec:
  automountServiceAccountToken: false
  containers:
  - name: web
    image: web:latest

2. Follow Least-Privilege RBAC

Never bind cluster-admin permissions to default service accounts. Define granular, namespace-bound Roles rather than cluster-wide ClusterRoles.