Kubernetes RBAC: Secure Your Cluster with Proper Access Controls

A Role defines permissions within a single namespace: which API groups, resources, and verbs (get, list, watch, create, update, delete) are allowed. A ClusterRole is cluster-wide and can grant access across all namespaces or to cluster-scoped resources like nodes and PersistentVolumes. RoleBindings bind a Role to a user, group, or service account within a namespace. ClusterRoleBindings bind a ClusterRole cluster-wide. You can bind a ClusterRole with a RoleBinding to reuse the same role definition across namespaces without granting cluster-wide access.

Create a developer Role that allows managing Deployments, Services, ConfigMaps, Ingresses, and pods within a team's namespace, but denies access to Secrets (use External Secrets or sealed secrets instead), RBAC resources, and system namespaces. Create a separate read-only Role for production namespaces so developers can view logs and pod status without modifying resources. For CI/CD service accounts, create tightly scoped Roles that allow only `update` on Deployments (to change image tags) and `get` on ConfigMaps, nothing else.

Every pod runs with a service account. The default service account in each namespace has no RBAC permissions (in clusters with RBAC enabled), but it still gets an auto-mounted API token. Disable auto-mounting with `automountServiceAccountToken: false` on the ServiceAccount or pod spec, and only mount tokens on pods that need API access. Create dedicated service accounts for controllers, operators, and CI/CD jobs with precisely scoped permissions. Never reuse service accounts across unrelated workloads.

Enable the Kubernetes audit log to record API requests, including who made them, what they did, and whether it was allowed or denied. Audit logs are essential for security investigations and compliance. On managed clusters, audit logs are usually available in the cloud provider's logging service (CloudTrail for EKS, Cloud Audit Logs for GKE). To troubleshoot RBAC denials, use `kubectl auth can-i [email protected] get pods -n production` to check if a specific user has a specific permission. The `kubectl auth whoami` command (Kubernetes 1.28+) shows the current identity and groups.