DevOps Dictionary

Kubernetes RBAC, or Role-Based Access Control, is the Kubernetes authorization model that controls which users, groups, and service accounts can perform actions on cluster resources. It answers questions like “Can this service account list pods in this namespace?” or “Can this engineer delete deployments in production?”

What Kubernetes RBAC does

Kubernetes RBAC limits access to the Kubernetes API. Every action in Kubernetes, such as creating a pod, reading a secret, updating a deployment, or deleting a namespace, goes through the API server. RBAC decides whether the authenticated identity has permission to make that request.

Teams use RBAC to reduce risk in shared clusters. For example, a CI/CD service account might be allowed to update deployments in the staging namespace, while only senior platform engineers can modify cluster-wide networking resources.

How Kubernetes RBAC works

RBAC uses a few core Kubernetes objects:

• Role: Defines permissions within a single namespace.
• ClusterRole: Defines permissions across the whole cluster, or for cluster-scoped resources such as nodes and namespaces.
• RoleBinding: Assigns a Role or ClusterRole to a user, group, or service account within one namespace.
• ClusterRoleBinding: Assigns a ClusterRole across the whole cluster.
• Subject: The identity receiving permissions, such as a user, group, or service account.

Permissions are written as rules. A rule usually includes:

• API groups: For example, apps, batch, or the core API group.
• Resources: For example, pods, deployments, secrets, or jobs.
• Verbs: Actions such as get, list, watch, create, update, patch, and delete.

For example, a Role can allow a service account to get, list, and watch pods in the dev namespace, without allowing it to delete pods or read secrets.

Authentication versus authorization

Kubernetes RBAC handles authorization, not authentication. Authentication confirms who is making the request. Authorization decides what that identity can do.

In a managed Kubernetes cluster, authentication may come from a cloud identity system, client certificates, OIDC, or another identity provider. After Kubernetes identifies the caller, RBAC checks the matching Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings.

Common use cases

• Namespace isolation: Give each team access only to its own namespaces, such as payments, analytics, or frontend.
• CI/CD deployments: Allow a pipeline service account to update Deployments and Services, while blocking access to Secrets or cluster-level resources.
• Production access control: Let engineers view production workloads, but require a smaller group to restart, scale, or delete them.
• Controller permissions: Grant operators, controllers, and agents only the API permissions they need to function.
• Compliance and audits: Keep access definitions in Git so reviewers can see who can access sensitive resources.

Simple real-world example

Assume your startup runs a shared Kubernetes cluster with separate namespaces for dev, staging, and prod. You want the backend team to manage workloads in staging, but you do not want them to delete production resources or read production secrets.

You could create a Role in the staging namespace that allows updates to Deployments, Services, ConfigMaps, and Jobs. Then you bind that Role to the backend team’s group. The same group gets no RoleBinding in prod, or gets a read-only Role there.

This setup gives developers enough access to ship and debug staging services, while reducing the chance of accidental production changes.

RBAC and service accounts

Service accounts are one of the most common RBAC subjects. Pods use service accounts when they talk to the Kubernetes API. Controllers, deployment tools, monitoring agents, and operators often need service accounts with specific permissions.

For example, a deployment automation tool may need permission to patch Deployments, create Jobs, and read rollout status. It probably does not need permission to read every Secret in the cluster. Keeping those permissions narrow reduces blast radius if a token leaks.

RBAC in infrastructure workflows

Many teams manage RBAC manifests through GitOps or infrastructure as code. Terraform, Helm, Kustomize, Argo CD, Flux, and similar tools can apply Roles and RoleBindings consistently across environments.

If you manage Kubernetes objects with Terraform, RBAC should be part of the same review process as namespaces, deployments, and service accounts. This keeps access changes visible in pull requests. For a related workflow, see this guide on how to deploy Kubernetes resources using Terraform.

RBAC also matters when Kubernetes controllers create or manage cloud resources. Tools such as Crossplane often need carefully scoped permissions inside the cluster, along with cloud-side IAM permissions. This matters when you deploy AWS resources using Crossplane on Kubernetes.

Benefits of Kubernetes RBAC

• Least-privilege access: You can grant only the actions a person, pipeline, or controller needs.
• Namespace-level control: Teams can work independently without receiving broad cluster access.
• Safer automation: CI/CD systems and operators can run with limited API permissions.
• Auditability: RBAC objects can live in Git and go through code review.
• Compatibility: RBAC is built into Kubernetes and works across self-managed and managed clusters.

Tradeoffs and limitations

• RBAC can become hard to track: Large clusters may have many Roles, ClusterRoles, and bindings. Naming conventions and Git-based management help.
• It does not secure network traffic: RBAC controls Kubernetes API access. Use NetworkPolicies or a service mesh for pod-to-pod traffic rules.
• It does not replace cloud IAM: In AWS, GCP, or Azure, you still need cloud identity permissions for cloud resources outside the cluster.
• Broad ClusterRoleBindings are risky: Binding cluster-admin to users or service accounts gives full control over the cluster.
• Some permissions are sensitive in practice: Access to create pods can be powerful, especially if workloads can mount service account tokens or host paths.

Best practices

• Start with read-only access: Add write permissions only when a role needs them.
• Prefer namespace-scoped Roles: Use ClusterRoles only when the resource or use case requires cluster-wide access.
• Avoid defaulting to cluster-admin: Reserve it for a small set of break-glass or platform administration identities.
• Separate humans and automation: Give CI pipelines, controllers, and users their own identities and bindings.
• Review access during cluster upgrades: API versions, controllers, and operational workflows can change. Include RBAC in your Kubernetes upgrade checklist.
• Use kubectl auth can-i: Test effective permissions before and after changes.

Useful kubectl checks

You can inspect RBAC behavior with commands such as:

• kubectl auth can-i create deployments -n staging
• kubectl auth can-i get secrets -n prod
• kubectl auth can-i list pods --as system:serviceaccount:staging:deploy-bot -n staging
• kubectl get rolebindings -n staging
• kubectl get clusterrolebindings

These checks are useful when debugging failed deployments, locked-down service accounts, or permission errors from controllers.

Kubernetes RBAC versus nearby concepts

• RBAC versus ABAC: RBAC grants permissions through roles and bindings. Attribute-Based Access Control, or ABAC, uses policies based on request attributes. Kubernetes supports RBAC as the standard approach for most clusters.
• RBAC versus IAM: RBAC controls access to Kubernetes API resources. Cloud IAM controls access to cloud resources such as S3 buckets, IAM roles, load balancers, and databases.
• RBAC versus NetworkPolicy: RBAC controls API actions. NetworkPolicy controls network traffic between pods, namespaces, and IP ranges.
• RBAC versus Pod Security Admission: RBAC controls who can create or modify resources. Pod Security Admission checks whether pod specs meet security rules.

Summary

Kubernetes RBAC is the built-in way to control access to the Kubernetes API. It maps users, groups, and service accounts to allowed actions on resources. Good RBAC design helps teams ship safely in shared clusters, protects sensitive resources, and keeps automation scoped to the permissions it needs.