Day 32 of 100: Role-Based Access Control (RBAC) in Kubernetes for Azure Cloud

Welcome back to Day 32 of the 100-Day Kubernetes Challenge!

Today, we're diving deep into Role-Based Access Control (RBAC) in Kubernetes—one of the most critical security mechanisms to safeguard your clusters, especially when running on Azure Kubernetes Service (AKS).

By the end of this newsletter, you'll:

✅ Understand why RBAC is essential in Kubernetes.

✅ Learn how RBAC works in Azure Kubernetes Service (AKS).

✅ Explore real-world use cases to make security a priority.

✅ Follow a step-by-step implementation of RBAC in AKS.

Stick around for an introduction to tomorrow’s topic—🔹 Secrets Management using HashiCorp Vault & Azure Key Vault

🔹 What is Role-Based Access Control (RBAC) in Kubernetes?

RBAC is a security mechanism in Kubernetes that restricts access to cluster resources based on roles assigned to users, groups, or applications.

It follows the principle of least privilege, ensuring that users and applications only have the permissions they absolutely need.

Imagine this: Would you give every developer in your company unrestricted access to production Kubernetes clusters?

Of course not! That’s where RBAC comes in—it helps manage permissions effectively and prevents security risks.

Why RBAC is Essential in Kubernetes

Role-Based Access Control (RBAC) is a critical security mechanism in Kubernetes that helps manage who can do what within a cluster.

Without RBAC, unauthorized access or accidental changes could lead to security breaches, service downtime, or data leaks. Here’s why RBAC is essential in Kubernetes:

1. Security and Least Privilege Principle

RBAC allows you to enforce the least privilege principle, ensuring that users and services only have the permissions they need. Without RBAC, any user with access to the cluster could make changes they shouldn't, increasing the risk of misconfigurations or security breaches.

✅ Example: You can restrict a developer to only deploy applications but prevent them from deleting namespaces.

2. Multi-Tenancy Support

In shared Kubernetes clusters (multi-tenant environments), RBAC ensures that different teams, projects, or tenants cannot interfere with each other. It isolates access based on namespaces or resources, protecting workloads from unintended interference.

✅ Example: In a multi-team environment, Team A should not have access to Team B's deployments.

3. Compliance and Auditing

RBAC helps organizations meet compliance requirements (e.g., GDPR, HIPAA, PCI DSS) by restricting access and enabling audits. You can track who accessed or modified resources, ensuring accountability.

✅ Example: If an unauthorized user modifies a production deployment, RBAC logs can help identify and investigate the breach.

4. Fine-Grained Access Control

RBAC provides detailed permission control through Roles, RoleBindings, ClusterRoles, and ClusterRoleBindings. You can assign permissions at different levels:

• Namespace-Level (Role & RoleBinding): Grants access to specific namespaces.
• Cluster-Level (ClusterRole & ClusterRoleBinding): Grants access to the entire cluster.

✅ Example: Grant read-only access to logs for DevOps engineers while allowing admins full access to resources.

5. Integration with Identity Management Systems

RBAC integrates with Kubernetes authentication systems like OIDC (OpenID Connect), Active Directory, and LDAP. This allows organizations to centrally manage user access and permissions.

✅ Example: An enterprise can integrate RBAC with an existing IAM system to ensure only authorized employees can access the cluster.

6. Prevention of Accidental Changes

RBAC helps prevent accidental deletions, modifications, or misconfigurations by restricting permissions. For example, a junior developer shouldn’t be able to delete production resources.

✅ Example: Restrict "delete" permissions for non-admin users to avoid accidental deletions.

7. Scalability and Automation

With Kubernetes automation tools (like Helm, ArgoCD, and Terraform), RBAC ensures security policies are consistently applied across environments.

✅ Example: You can create predefined RBAC roles for CI/CD pipelines to automate deployments securely.

Real-World Scenario:

A DevOps engineer should be able to deploy applications but shouldn't be allowed to delete critical resources like databases or ingress controllers. With RBAC, you can precisely define what they can and cannot do.

🔹 Understanding RBAC in Azure Kubernetes Service (AKS)

Role-Based Access Control (RBAC) in Azure Kubernetes Service (AKS) is a crucial security feature that allows you to define and enforce access permissions for users, groups, and service accounts within a Kubernetes cluster.

1. RBAC in AKS: Key Components

AKS implements Kubernetes-native RBAC and integrates with Azure Active Directory (Azure AD) for identity and access management.

RBAC in AKS consists of two main layers:

1. Kubernetes RBAC - Defines permissions within the Kubernetes cluster.
2. Azure RBAC for Kubernetes Authorization - Extends Kubernetes RBAC by integrating with Azure Active Directory (AAD).

2. Kubernetes RBAC in AKS

AKS supports the native Kubernetes RBAC model, which consists of the following objects:

Kubernetes Object Description Role Defines permissions within a specific namespace. ClusterRole Defines permissions cluster-wide. RoleBinding Binds a Role to a user, group, or service account in a namespace.

ClusterRoleBinding Binds a ClusterRole to a user, group, or service account cluster-wide.

✅ Example of a Role and RoleBinding in AKS

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev-team
  name: dev-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "create"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-role-binding
  namespace: dev-team
subjects:
- kind: User
  name: dev-user@example.com  # Azure AD user or group
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: dev-role
  apiGroup: rbac.authorization.k8s.io
        

Explanation:

• The Role grants "get," "list," and "create" permissions on pods within the dev-team namespace.
• The RoleBinding assigns this Role to the user dev-user@example.com.

3. Azure RBAC for Kubernetes Authorization

In addition to Kubernetes RBAC, AKS integrates with Azure RBAC, allowing you to control who can access the Kubernetes API server using Azure AD identities.

How Azure RBAC for AKS Works

1. Users authenticate using Azure AD instead of traditional Kubernetes authentication methods.
2. Azure RBAC assigns users roles that determine their level of access to the Kubernetes API server.
3. Azure RBAC decisions are enforced before Kubernetes RBAC applies.

Built-in Azure RBAC Roles for AKS

Azure provides predefined roles for Kubernetes RBAC:

Azure RBAC Role Description Azure Kubernetes Service Cluster Admin Role Grants full access to the AKS cluster (like a Kubernetes cluster-admin).

Azure Kubernetes Service Admin Role Allows full access to Kubernetes namespaces but not cluster-wide.

Azure Kubernetes Service RBAC Writer Role Grants write access to Kubernetes resources within assigned namespaces.

Azure Kubernetes Service RBAC Reader Role Allows read-only access to Kubernetes resources.

✅ Example: Assign Azure RBAC to a User

az role assignment create \
  --role "Azure Kubernetes Service RBAC Reader" \
  --assignee user@example.com \
  --scope /subscriptions/{subscription-id}/resourceGroups/{resource-group}/providers/Microsoft.ContainerService/managedClusters/{aks-cluster}
        

Explanation:

• This assigns the RBAC Reader Role to user@example.com at the AKS cluster level.

4. Enabling Azure RBAC in AKS

To use Azure RBAC for Kubernetes authorization in AKS, follow these steps:

Step 1: Enable Azure AD Integration

If you haven’t already integrated Azure AD with AKS, enable it during cluster creation:

az aks create --resource-group myResourceGroup \
  --name myAKSCluster \
  --enable-aad
        

Step 2: Enable Azure RBAC for Kubernetes

Enable Azure RBAC to manage Kubernetes access using Azure AD:

az aks update --resource-group myResourceGroup \
  --name myAKSCluster \
  --enable-azure-rbac
        

Step 3: Assign Azure RBAC Roles

Use Azure RBAC roles to grant users access instead of Kubernetes RBAC directly.

az role assignment create \
  --assignee user@example.com \
  --role "Azure Kubernetes Service RBAC Writer" \
  --scope /subscriptions/{subscription-id}/resourceGroups/{resource-group}/providers/Microsoft.ContainerService/managedClusters/{aks-cluster}
        

5. Combining Kubernetes RBAC and Azure RBAC

• Azure RBAC controls API access → Determines who can make Kubernetes API requests.
• Kubernetes RBAC controls resource access → Determines what actions users can perform inside Kubernetes.

✅ Example Workflow

1. Azure RBAC checks if the user is authorized to access the AKS API server.
2. If authorized, Kubernetes RBAC determines the user’s permissions within the cluster.

Step Azure RBAC Kubernetes RBAC

- 1 User logs in via Azure AD.

- 2 Azure RBAC checks user permissions.

- 3 If permitted, request reaches the Kubernetes API.

- 4 Kubernetes RBAC determines if the user can perform actions like kubectl get pods. ✅

6. Verifying and Troubleshooting RBAC in AKS

Check Role Bindings for a User

To see what roles are assigned to a user:

kubectl get rolebinding --all-namespaces | grep user@example.com
        

Check Kubernetes API Access

Use kubectl auth can-i to verify access:

kubectl auth can-i create pods --namespace dev-team
        

List Azure RBAC Role Assignments

az role assignment list --assignee user@example.com
        

7. Best Practices for RBAC in AKS

✔ Use Azure RBAC for cluster-wide permissions instead of manually assigning Kubernetes roles.

✔ Follow the least privilege principle – Only grant necessary permissions.

✔ Organize permissions by team or environment (e.g., separate roles for dev, test, and production).

✔ Use groups instead of individual user assignments for better scalability.

✔ Monitor and audit access logs using Azure Monitor and Kubernetes logs.

🔹 Step-by-Step Implementation of RBAC in Azure Kubernetes Service (AKS)

Let’s walk through a practical example:

1️⃣ Create an AKS Cluster with Azure AD Integration

Ensure your AKS cluster is integrated with Azure Active Directory to enable Azure-based authentication.

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --enable-aad \
    --enable-azure-rbac

        

2️⃣ Create a Kubernetes Role

Let’s create a Kubernetes Role that allows users to view pods but prevents them from modifying or deleting anything.

📌 Role Definition (role.yaml)

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

        

What’s happening here?

✔ We created a role named pod-viewer

✔ It applies to the default namespace

✔ The user can list and view pods but not modify or delete them

3️⃣ Bind the Role to a User (RoleBinding)

Now, we need to assign this role to a specific user or group.

RoleBinding Definition (rolebinding.yaml)

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-viewer-binding
  namespace: default
subjects:
  - kind: User
    name: dev-user@example.com  # Replace with actual AAD user
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-viewer
  apiGroup: rbac.authorization.k8s.io

        

4️⃣ Apply the RBAC Policies

Now, let’s apply our RBAC configuration using kubectl:

kubectl apply -f role.yaml
kubectl apply -f rolebinding.yaml

        

✅ Done!

The user dev-user@example.com can now view pods in the default namespace but cannot modify or delete them.

Configuring RBAC in Azure Kubernetes Service (AKS) for a multi-team environment.

This setup ensures team-based access control, least privilege principle, and secure management of the cluster.

Scenario

We have an AKS cluster with three teams:

• Dev Team → Can deploy and manage applications in the dev namespace.
• QA Team → Can only view resources in the qa namespace.
• Ops Team → Has full access to the cluster for maintenance and troubleshooting.

We'll achieve this by:

1. Creating namespaces (dev, qa, ops).
2. Defining Kubernetes RBAC roles for each team.
3. Binding users to roles using RoleBinding and ClusterRoleBinding.
4. Using Azure RBAC for API server access control.

1️⃣ Create Namespaces

Each team gets its own namespace to manage resources separately.

apiVersion: v1
kind: Namespace
metadata:
  name: dev

---
apiVersion: v1
kind: Namespace
metadata:
  name: qa

---
apiVersion: v1
kind: Namespace
metadata:
  name: ops
        

Apply the namespaces:

kubectl apply -f namespaces.yaml
        

2️⃣ Configure Kubernetes RBAC for Each Team

Dev Team - Full Control Over Dev Namespace

Create a Role for the dev namespace that allows the Dev team to deploy and manage applications.

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

Bind this Role to Dev Team Users

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-team-rolebinding
  namespace: dev
subjects:
- kind: Group
  name: dev-team@example.com  # Azure AD group
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: dev-team-role
  apiGroup: rbac.authorization.k8s.io
        

QA Team - Read-Only Access in QA Namespace

Create a Role for the qa namespace that grants read-only access.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: qa
  name: qa-team-role
rules:
- apiGroups: [""]
  resources: ["pods", "services", "deployments"]
  verbs: ["get", "list"]
        

Bind this Role to QA Team Users

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: qa-team-rolebinding
  namespace: qa
subjects:
- kind: Group
  name: qa-team@example.com  # Azure AD group
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: qa-team-role
  apiGroup: rbac.authorization.k8s.io
        

Ops Team - Full Cluster Access

For the Ops team, we use a ClusterRole with admin privileges.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: ops-team-role
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["*"]
        

Bind this Role to Ops Team Users

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: ops-team-rolebinding
subjects:
- kind: Group
  name: ops-team@example.com  # Azure AD group
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: ops-team-role
  apiGroup: rbac.authorization.k8s.io
        

3️⃣ Configure Azure RBAC for API Access

Before Kubernetes RBAC applies, we need to grant Azure users access to the Kubernetes API.

Dev Team - Kubernetes Writer Role

Allow the Dev Team to manage resources in their namespace:

az role assignment create \
  --role "Azure Kubernetes Service RBAC Writer" \
  --assignee dev-team@example.com \
  --scope /subscriptions/{subscription-id}/resourceGroups/{resource-group}/providers/Microsoft.ContainerService/managedClusters/{aks-cluster}
        

QA Team - Kubernetes Reader Role

Allow the QA Team to only view resources:

az role assignment create \
  --role "Azure Kubernetes Service RBAC Reader" \
  --assignee qa-team@example.com \
  --scope /subscriptions/{subscription-id}/resourceGroups/{resource-group}/providers/Microsoft.ContainerService/managedClusters/{aks-cluster}
        

Ops Team - Full Admin Access

az role assignment create \
  --role "Azure Kubernetes Service Cluster Admin Role" \
  --assignee ops-team@example.com \
  --scope /subscriptions/{subscription-id}/resourceGroups/{resource-group}/providers/Microsoft.ContainerService/managedClusters/{aks-cluster}
        

4️⃣ Verify RBAC Configuration

Check Role Bindings

kubectl get rolebinding --all-namespaces
kubectl get clusterrolebinding
        

Test Dev Team Access

Switch to a Dev Team user and check access:

kubectl auth can-i create pods --namespace dev
kubectl auth can-i delete pods --namespace dev
kubectl auth can-i delete pods --namespace qa  # Should return "no"
        

Test QA Team Access

kubectl auth can-i get pods --namespace qa
kubectl auth can-i delete pods --namespace qa  # Should return "no"
        

Summary

✅ Namespaces for isolation: dev, qa, ops

✅ Kubernetes RBAC for in-cluster access control:

• Dev Team: Full control over dev namespace
• QA Team: Read-only access to qa namespace
• Ops Team: Full cluster-wide access

✅ Azure RBAC for API authentication and management:

• Dev Team: Azure Kubernetes Service RBAC Writer
• QA Team: Azure Kubernetes Service RBAC Reader
• Ops Team: Azure Kubernetes Service Cluster Admin Role

This setup ensures security, least privilege, and access control for a multi-team AKS environment.

🔹 Azure Kubernetes RBAC vs Kubernetes RBAC: When to Use What?

When to Use Azure RBAC?

✅ To control who can access the AKS API server

✅ When managing AKS at scale across multiple clusters

✅ To enforce organization-wide security policies using Azure AD

✅ When you need centralized identity management for your AKS clusters

✅ To integrate AKS access with Azure Privileged Identity Management (PIM)

When to Use Kubernetes RBAC?

✅ Fine-Grained Access Control – Restrict actions like creating, deleting, or modifying resources.

✅ Namespace-Level Access Control – Assign teams specific access to their namespaces.

✅ Least Privilege Enforcement – Grant only the necessary permissions to users.

✅ Control Service Accounts & Automation – Limit access for CI/CD pipelines, bots, and applications.

✅ Secure Custom Controllers & Operators – Ensure Kubernetes controllers have the right access.

✅ Restrict API Access Inside the Cluster – Control kubectl commands and API calls.

Tip: Always use Azure RBAC for managing cluster-level access and Kubernetes RBAC for resource-level access.

🔹 Key Takeaways

✅ RBAC is crucial for securing Kubernetes clusters.

✅ AKS integrates with Azure AD for authentication.

✅ Azure RBAC controls cluster access, while Kubernetes RBAC controls resource permissions.

✅ Use Role and RoleBinding for namespace-level access.

Pro Tip: If you need to manage permissions across multiple namespaces, use ClusterRole and ClusterRoleBinding instead of Role and RoleBinding.

🔹 What’s Next?

🔥 Tomorrow’s topic: Secrets Management with HashiCorp Vault & Azure Key Vault!

🔹 How do you securely store database credentials, API keys, and certificates in Kubernetes? 🔹 What’s the difference between Kubernetes Secrets, HashiCorp Vault, and Azure Key Vault? 🔹 How do you integrate Vault & Azure Key Vault with AKS for ultimate security?

💡 Hint: If you’re hardcoding secrets in your YAML files—you're doing it wrong! 😱

Follow Shruthi Chikkela for daily Kubernetes insights and pro tips. Let’s keep this challenge going strong!

Stay secure and keep learning! See you tomorrow for Secrets Management in Kubernetes!

🔹 #100DaysOfKubernetes #Azure #AKS #RBAC #DevOps #CloudSecurity #Learnwithshruthi