Enforcing Role-Based Access Control (RBAC) in Kubernetes

1. What is Role-Based Access Control (RBAC)?

RBAC is a security mechanism that allows you to control who can access Kubernetes resources and what actions they can perform.

Why Use RBAC?

🛑 Restrict access to sensitive resources
🔒 Limit permissions to only what’s necessary (Principle of Least Privilege)
✅ Prevent unauthorized actions like deleting pods or changing configurations
📜 Improve auditing and compliance (GDPR, HIPAA, PCI DSS)

RBAC uses four key components: Roles, RoleBindings, ClusterRoles, and ClusterRoleBindings.

2. Understanding Kubernetes RBAC Components

2.1 Roles vs ClusterRoles

Feature	Role	ClusterRole
Scope	Namespace-specific	Applies to entire cluster
Use Case	Assign permissions within a single namespace	Assign global permissions
Example	Dev team only modifies resources in `dev` namespace	Admins can manage all namespaces

Example Role (Namespace-specific):

1
2
3
4
5
6
7
8
9
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: dev-team-role
rules:
- apiGroups: [""]
  resources: ["pods", "services"]
  verbs: ["get", "list", "create", "delete"]

Example ClusterRole (Cluster-wide access):

1
2
3
4
5
6
7
8
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-admin-role
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["*"]

2.2 RoleBindings vs ClusterRoleBindings

Feature	RoleBinding	ClusterRoleBinding
Scope	Namespace-specific	Applies to all namespaces
Use Case	Grants role permissions to users in a specific namespace	Grants global permissions
Example	Bind “dev-team-role” to users in the `dev` namespace	Allow “cluster-admin-role” for system-wide access

Example RoleBinding (Namespace-specific):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-team-binding
  namespace: dev
subjects:
- kind: User
  name: developer-user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: dev-team-role
  apiGroup: rbac.authorization.k8s.io

Example ClusterRoleBinding (Cluster-wide access):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-binding
subjects:
- kind: User
  name: admin-user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin-role
  apiGroup: rbac.authorization.k8s.io

3. Enforcing RBAC in Kubernetes

Step 1: Enable RBAC in Kubernetes

Most Kubernetes distributions have RBAC enabled by default, but verify it:

1
kubectl api-versions | grep rbac.authorization.k8s.io

If not enabled, start Kubernetes API server with:

1
kube-apiserver --authorization-mode=RBAC

Step 2: Create a Custom Role for Developers

1
2
3
4
5
6
7
8
9
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: developer-role
rules:
- apiGroups: [""]
  resources: ["pods", "services", "deployments"]
  verbs: ["get", "list", "create", "update"]

Apply it:

1
kubectl apply -f developer-role.yaml

Step 3: Bind Role to a Developer User

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-role-binding
  namespace: dev
subjects:
- kind: User
  name: dev-user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer-role
  apiGroup: rbac.authorization.k8s.io

Apply it:

1
kubectl apply -f developer-role-binding.yaml

Now, dev-user can only access resources in the dev namespace.

4. Best Practices for RBAC in Kubernetes

✅ Follow the Principle of Least Privilege (PoLP) - Users should only have the permissions they need.
✅ Use Namespace-Specific Roles instead of ClusterRoles where possible.
✅ Monitor RBAC Policies Regularly using kubectl auth can-i:

1
kubectl auth can-i create pods --as=dev-user

✅ Use Service Accounts for Applications instead of granting direct user access:

1
2
3
4
5
apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-sa
  namespace: dev

Bind a Role to a Service Account:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: app-binding
  namespace: dev
subjects:
- kind: ServiceAccount
  name: app-sa
roleRef:
  kind: Role
  name: developer-role
  apiGroup: rbac.authorization.k8s.io

5. Auditing and Debugging RBAC Issues

Check Role Assignments

List Roles:

1
kubectl get roles --all-namespaces

Check permissions:

1
kubectl auth can-i list pods --as=dev-user

Check RoleBindings:

1
kubectl get rolebinding --namespace dev

Enable Kubernetes Audit Logs

Modify audit-policy.yaml:

1
2
3
4
5
6
7
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["pods", "secrets"]

Apply it:

1
kubectl apply -f audit-policy.yaml

Now, all access to Pods and Secrets will be logged.

Final Thoughts

RBAC is a powerful tool for controlling Kubernetes access.

Key Takeaways

✅ RBAC prevents unauthorized access to Kubernetes resources
✅ Use Roles and RoleBindings for namespace control
✅ Use ClusterRoles only when necessary
✅ Audit and monitor RBAC permissions regularly

By enforcing RBAC best practices, you enhance security, limit access, and protect your Kubernetes cluster. 🚀