Kubernetes Role-Based Access Control (RBAC) is the backbone of cluster security. When configured correctly, RBAC ensures that users, service accounts, and groups receive only the permissions they need to perform their tasks. This guide walks you through implementing robust RBAC policies using Claude Code, with practical examples and real-world patterns.

Understanding RBAC in Kubernetes

Kubernetes RBAC operates through four primary resources: Role, ClusterRole, RoleBinding, and ClusterRoleBinding. A Role defines a set of permissions within a specific namespace, while a ClusterRole applies across the entire cluster. RoleBinding connects those permissions to users or groups, and ClusterRoleBinding does the same at the cluster scope.

The fundamental principle follows the principle of least privilege. Grant only what is necessary, and audit regularly. Many security incidents result from overly permissive bindings left behind from testing or debugging sessions.

Setting Up Your Environment

Before implementing RBAC policies, ensure you have access to a Kubernetes cluster and the appropriate tools. Claude Code can assist using its bash tool to interact with kubectl:

# Check your current context and permissions
kubectl auth can-i --list
kubectl auth can-i create pods --namespace=default

This verification step confirms what your current identity can do within the cluster. If you are cluster administrator, you will see extensive permissions. Regular developers should see more limited access.

Creating Roles for Application Teams

Suppose you have a development team that needs to manage deployments within a specific namespace but should not modify cluster-wide resources or other namespaces. Define a Role accordingly:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: team-frontend
  name: frontend-developer
rules:
- apiGroups: ["apps", ""]
  resources: ["deployments", "pods", "services", "configmaps"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

This Role grants full CRUD operations on essential resources within the team-frontend namespace. The developer cannot access secrets (unless explicitly added to the rules), cannot modify RoleBindings, and cannot interact with resources outside their namespace.

Apply this Role using kubectl:

kubectl apply -f role-frontend-developer.yaml

Binding Roles to Users

The Role alone does nothing until you bind it to a user or group. Create a RoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: frontend-developer-binding
  namespace: team-frontend
subjects:
- kind: User
  name: alice@example.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: frontend-developer
  apiGroup: rbac.authorization.k8s.io

Alice now has developer-level access exclusively within the team-frontend namespace. This isolation prevents accidental or malicious modifications to other team environments.

Using ClusterRole for Cross-Namespace or Cluster-Wide Access

Some permissions need to span multiple namespaces or apply cluster-wide. ClusterRole serves this purpose. For instance, a monitoring service needs read access to pods across all namespaces:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

A ClusterRoleBinding connects this to the service account used by your monitoring tool:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: monitoring-pod-reader
subjects:
- kind: ServiceAccount
  name: prometheus
  namespace: monitoring
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Automating RBAC Documentation

Managing RBAC policies becomes complex as your cluster grows. Tools like the supermemory skill can help you maintain searchable documentation of all roles and bindings in your organization. Documenting who has access to what, and why, is critical for compliance and security audits.

Claude Code can generate documentation from your existing policies:

# Export all RBAC resources
kubectl get roles,clusterroles,rolebindings,clusterrolebindings -A -o yaml > rbac-backup.yaml

Regular backups ensure you can restore policies after accidental deletion or reconstruct access during incident response.

Common RBAC Pitfalls

The default service account in each namespace is automatically mounted to pods and has edit permissions within that namespace. This behavior often goes unnoticed and represents a significant attack vector. Always explicitly set automountServiceAccountToken: false for pods that do not need Kubernetes API access:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-sa
  namespace: production
automountServiceAccountToken: false

Another frequent mistake is granting cluster-admin permissions too liberally. The cluster-admin ClusterRole bypasses all RBAC checks. Reserve it for emergency recovery only, and audit cluster-admin bindings quarterly.

Auditing and Monitoring RBAC Changes

Kubernetes does not log RBAC authorization decisions by default. Enable audit logging to track who attempted what actions:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: RequestResponse
  resources:
  - group: rbac.authorization.k8s.io
    resources: ["roles", "clusterroles", "rolebindings", "clusterrolebindings"]

This configuration records every change to RBAC objects, providing an audit trail essential for security investigations. Store these logs in a secure, centralized location.

Integrating RBAC with CI/CD Pipelines

When deploying applications through CI/CD, service accounts represent the pipeline identity. Create dedicated service accounts for each pipeline and scope their permissions tightly:

kubectl create serviceaccount cicd-pipeline -n ci-cd

Then grant only the permissions necessary for deployment. If your pipeline only creates deployments and services, do not grant access to secrets or configmaps unless specifically required.

This practice limits the blast radius if a pipeline credential is compromised. Attackers gaining access to a narrowly scoped service account cannot easily escalate to more sensitive resources.

Testing RBAC Policies

Before applying RBAC changes to production, test them in a development cluster. The tdd skill provides a framework for writing tests that verify permission boundaries:

def test_developer_cannot_delete_pods():
    # Simulate developer attempting to delete a pod
    result = kubectl auth can-i delete pods --namespace=team-frontend
    assert result == "yes"  # Developers should be able to manage pods
    
def test_developer_cannot_access_other_namespace():
    result = kubectl auth can-i get pods --namespace=team-backend
    assert result == "no"  # Should be denied

Automated tests catch permission misconfigurations before they reach production.

Best Practices Summary

• Define Roles for namespace-scoped permissions and ClusterRoles for cluster-wide needs
• Prefer RoleBinding over ClusterRoleBinding when possible
• Audit service account usage and disable automatic token mounting
• Enable audit logging for RBAC changes
• Document all bindings and review them quarterly
• Use the principle of least privilege at every level

Implementing RBAC properly requires upfront effort, but the security benefits justify the investment. A well-configured RBAC policy protects your cluster from both external attackers and internal misconfigurations.

Related Reading

• Claude Code for Beginners: Complete Getting Started Guide
• Best Claude Skills for Developers in 2026
• Claude Skills Guides Hub

Built by theluckystrike — More at zovo.one