27: RBAC

27: RBAC

Objective

Understand the Kubernetes Role-Based Access Control (RBAC) model. Create ServiceAccounts, Roles, and RoleBindings within your namespace. Test permissions using kubectl auth can-i to verify access controls.

Important: In this training cluster, RBAC is disabled (--disable-rbac) for simplified access. This means all kubectl auth can-i checks will return yes regardless of Role configuration. This exercise is educational and conceptual — you will learn how RBAC works so you can apply it in production environments where RBAC is always enabled. The ServiceAccount, Role, and RoleBinding resources you create are namespaced and safe to create within your student-XX namespace.

Theory

What is RBAC?

Role-Based Access Control (RBAC) is the standard authorization mechanism in Kubernetes. It controls who (subjects) can perform what actions (verbs) on which resources within the cluster.

RBAC is built on four key resources:

Subjects

RBAC permissions are granted to subjects — the entities that perform actions:

Verbs

RBAC rules use verbs to specify allowed actions:

Azure RBAC Integration with AKS

AKS supports integration with Azure Active Directory (Entra ID) for authentication:

• AKS with Azure AD: Users authenticate with their Azure AD credentials instead of client certificates
• Azure RBAC for Kubernetes: Azure AD groups can be mapped directly to Kubernetes RBAC roles
• Enable with: az aks create --enable-aad or az aks update --enable-aad (cluster administrator operation)
• Admin access: az aks get-credentials --admin bypasses Azure AD and uses a cluster admin certificate
• Regular access: az aks get-credentials (without --admin) uses Azure AD authentication

Note: The az aks commands above are cluster-level operations performed by administrators. In this training, the instructor manages cluster-level configuration.

In production, always use Azure AD integration and avoid --admin credentials.

Mermaid Diagram: RBAC Model

flowchart LR
    subgraph Subjects
        SA[ServiceAccount<br>app-sa-XX]
        U[User]
        G[Group]
    end

    subgraph RBAC Resources
        R[Role<br>pod-reader-XX<br>verbs: get, list<br>resources: pods]
        RB[RoleBinding<br>links Role to Subject]
    end

    subgraph Namespace student-XX
        P1[Pod A]
        P2[Pod B]
        P3[Pod C]
    end

    SA --> RB
    U --> RB
    G --> RB
    RB --> R
    R -->|Grants access to| P1
    R -->|Grants access to| P2
    R -->|Grants access to| P3

Practical Tasks

All tasks should be performed in your namespace student-XX. Replace XX with your student number throughout.

As noted above, RBAC is disabled in this training cluster — the tasks below are conceptual.

Task 1: Create a ServiceAccount

Create a ServiceAccount that will represent an application identity:

kubectl create serviceaccount app-sa-XX

Verify the ServiceAccount was created:

kubectl get serviceaccount app-sa-XX

List all ServiceAccounts in your namespace:

kubectl get serviceaccounts

Every namespace has a default ServiceAccount that is automatically assigned to Pods unless specified otherwise.

Task 2: Create a Role

Create a Role that grants read-only access to Pods (only get and list verbs).

Create a file pod-reader-role.yaml:

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

Apply it:

kubectl apply -f pod-reader-role.yaml

Verify the Role:

kubectl get role pod-reader-XX
kubectl describe role pod-reader-XX

Task 3: Create a RoleBinding

Create a RoleBinding that links the pod-reader-XX Role to the app-sa-XX ServiceAccount.

Create a file pod-reader-binding.yaml:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-reader-binding-XX
subjects:
- kind: ServiceAccount
  name: app-sa-XX
  namespace: student-XX
roleRef:
  kind: Role
  name: pod-reader-XX
  apiGroup: rbac.authorization.k8s.io

Apply it:

kubectl apply -f pod-reader-binding.yaml

Verify the RoleBinding:

kubectl get rolebinding pod-reader-binding-XX
kubectl describe rolebinding pod-reader-binding-XX

Task 4: Test Permissions

Use kubectl auth can-i to verify what the ServiceAccount can and cannot do. The --as flag impersonates the specified identity.

Test allowed actions (should return yes):

kubectl auth can-i get pods --as=system:serviceaccount:student-XX:app-sa-XX
kubectl auth can-i list pods --as=system:serviceaccount:student-XX:app-sa-XX

Test denied actions (should return no):

kubectl auth can-i delete pods --as=system:serviceaccount:student-XX:app-sa-XX
kubectl auth can-i create pods --as=system:serviceaccount:student-XX:app-sa-XX
kubectl auth can-i list deployments --as=system:serviceaccount:student-XX:app-sa-XX
kubectl auth can-i get secrets --as=system:serviceaccount:student-XX:app-sa-XX

As noted above, RBAC is disabled in this training cluster, so all can-i checks will return yes. In production, the denied actions above would correctly return no.

Cleanup

kubectl delete rolebinding pod-reader-binding-XX
kubectl delete role pod-reader-XX
kubectl delete serviceaccount app-sa-XX

Common Problems

Best Practices

• Principle of least privilege — grant only the minimum permissions needed. Start with restrictive roles and expand as necessary
• Use Roles (not ClusterRoles) where possible — namespace-scoped roles limit the blast radius of misconfiguration
• Avoid cluster-admin in production — reserve cluster-admin for break-glass scenarios only
• Use Groups over individual Users — manage permissions via Azure AD / Entra ID groups rather than individual user bindings
• Use Entra ID + Azure RBAC for AKS — integrate Azure AD authentication and use Azure RBAC for Kubernetes authorization in production
• Audit RBAC regularly — use kubectl auth can-i --list --as=<user> to review effective permissions
• Never use --admin credentials in production — az aks get-credentials --admin bypasses all RBAC checks
• Assign ServiceAccounts explicitly — do not rely on the default ServiceAccount; create dedicated ServiceAccounts for each application

Summary

In this exercise you learned:

• Kubernetes RBAC uses four resources: Role, ClusterRole, RoleBinding, and ClusterRoleBinding
• Subjects (Users, Groups, ServiceAccounts) are granted permissions through bindings
• Roles define which verbs (get, list, create, delete, etc.) are allowed on which resources
• kubectl auth can-i is used to test and verify permissions
• AKS integrates with Azure AD (Entra ID) for authentication and supports Azure RBAC for Kubernetes authorization
• In production, always enable RBAC and use Entra ID groups for access management