Q32: Kubernetes RBAC: Roles, ClusterRoles, ServiceAccounts, and least-privilege token protection. - DevOps & Kubernetes (50 Qs)

Access Control Architecture

Kubernetes Role-Based Access Control (RBAC) maps Subjects (Users, Groups, ServiceAccounts) to Roles (rules of API actions) via RoleBindings.

sql

+-----------------------+               +-----------------------+
|  Subject: User/App    |               |  API Permissions      |
|  - ServiceAccount: api|               |  - Resources: pods    |
+-----------------------+               |  - Verbs: get, list   |
            |                           +-----------------------+
            |                                       |
            v                                       v
+---------------------------------------------------------------+
|                       RoleBinding                             |
|           Binds Subject to Role within "production"           |
+---------------------------------------------------------------+

Scope Comparison

Object	Scope	Description
`Role`	Single Namespace	Grants permissions within a specific namespace (e.g. read configmaps in `production`).
`ClusterRole`	Cluster-Wide	Grants permissions across all namespaces or for cluster-scoped resources (e.g. Nodes, PVs, Namespaces).
`RoleBinding`	Single Namespace	Grants Role or ClusterRole permissions within that namespace only.
`ClusterRoleBinding`	Cluster-Wide	Grants ClusterRole permissions across all namespaces cluster-wide.

Production Hardening: Securing ServiceAccount Tokens

By default, Kubernetes mounts a long-lived JWT ServiceAccount token into every container at /var/run/secrets/kubernetes.io/serviceaccount/token. If an attacker breaches the container, they can steal this token to query the API server.

yaml

apiVersion: v1
kind: Pod
metadata:
  name: secured-web-app
spec:
  # Disable automatic token mounting if the app does not interact with K8s API
  automountServiceAccountToken: false
  serviceAccountName: limited-sa