Kubernetes RBAC controls access to the Kubernetes API. Implementing least-privilege RBAC for production clusters requires systematic analysis of what each workload and human operator actually needs.
The default service account problem
Every pod in Kubernetes runs with a service account. The default service account in each namespace has no permissions by default in recent Kubernetes versions, but legacy configurations and some cluster setups grant broad permissions to the default service account. Applications that do not need Kubernetes API access should use a dedicated service account with no RBAC permissions (or automountServiceAccountToken: false to prevent the token from being mounted at all).
Namespace-scoped vs cluster-scoped roles
Roles (namespace-scoped) and ClusterRoles (cluster-scoped) differ in scope. Application RBAC should use namespace-scoped Roles: the permissions for a service account should apply only within its namespace. ClusterRoles are appropriate for: cluster-wide resources (nodes, persistent volumes, storage classes), and operators that need cluster-wide visibility (Prometheus, cert-manager). Granting ClusterRole to namespace-level workloads is a common over-permissioning pattern.
The principle of least privilege in practice
The practical RBAC implementation workflow: identify every service account in the cluster, determine what Kubernetes API operations each service actually performs (using audit logs or the kubectl auth can-i tool), create Roles with exactly those permissions, and remove unused ClusterRole bindings. The kubectl auth reconcile command helps synchronise desired RBAC state. Regular RBAC audits using rbac-audit or Rakkess identify over-privileged accounts.
Human operator access patterns
Human operator access should be time-limited and scoped by role. The common operator roles: read-only (get, list, watch on namespaced resources for debugging), developer (deploy to specific namespaces, no cross-namespace access), platform admin (full cluster access with MFA requirement). Use Azure AD / OIDC integration so that Kubernetes RBAC leverages corporate identity management. Avoid long-lived kubeconfig files with cluster-admin credentials on developer machines.