# 14: Role-Based Access Control (RBAC) in Kubernetes with Practical Examples

Role-Based Access Control (RBAC) is a Kubernetes mechanism to control and restrict access to resources based on user roles and permissions. In this blog, we'll explore RBAC concepts, configuration steps, and examples to clarify how it works.

---

## **What is RBAC?**

RBAC allows administrators to assign specific permissions to users or groups. This ensures users only have access to the resources they need, limiting potential security risks. Here’s a breakdown:

1. **Role**: Defines permissions for specific resources in a namespace.  
    Example: A role allowing a user to create and delete pods in the `dev` namespace.
    
2. **ClusterRole**: Similar to a Role but not namespace-specific, granting access to resources cluster-wide.
    
3. **RoleBinding**: Associates a Role with a user or group within a namespace.
    
4. **ClusterRoleBinding**: Associates a ClusterRole with a user or group across the cluster.
    

---

## **RBAC Workflow Example**

We’ll demonstrate how to create a user named **Hassan**, set up their credentials, and assign them a role with limited permissions in the `dev` namespace.

---

### **Step 1: User Creates an OpenSSL Key and CSR**

On Hassan's workstation, generate a private key and a certificate signing request (CSR).

```plaintext
# Generate a private key
openssl genrsa -out user.key 2048

# Create a CSR (replace "username" with the actual username)
openssl req -new -key user.key -out user.csr -subj "/CN=hassan"
```

---

### **Step 2: Submit CSR to the Manager**

Hassan submits the key and CSR to the manager (or CA).

```plaintext
# Transfer files to the manager
scp user.key user.csr login@manager:
```

---

### **Step 3: Manager Issues a Certificate**

The manager (Root CA) signs the CSR and sends the certificate back to Hassan.

```plaintext
# Sign the CSR with the Kubernetes Root CA
openssl x509 -req -in user.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key \
  -CAcreateserial -out user.crt -days 365

# Return the certificate to Hassan
scp user.crt login@workstation:
```

---

### **Step 4: Set Up Kubernetes Configuration on User Workstation**

Hassan creates a `.kube` directory and configures `kubectl`.

1. **Create the configuration directory:**
    
    ```plaintext
    mkdir -p ~/.kube
    ```
    
2. **Copy the necessary config file from the manager** (without root credentials).
    
3. **Install** `kubectl` on the workstation:
    
    ```plaintext
    sudo snap install kubectl --classic
    ```
    
4. **Set user credentials in the Kubernetes context:**
    
    ```plaintext
    kubectl config set-credentials hassan --client-certificate=user.crt --client-key=user.key
    kubectl config set-context hassan-context --cluster=kubernetes --namespace=dev --user=hassan
    ```
    

---

### **Step 5: Assign a Role to the User**

#### **Role Example: Allow Pod Management in the** `dev` Namespace

1. Create a YAML file defining the Role:
    
    ```plaintext
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      namespace: dev
      name: pod-manager
    rules:
    - apiGroups: [""] # "" indicates the core API group
      resources: ["pods"]
      verbs: ["create", "delete"]
    ```
    
2. Apply the Role:
    
    ```plaintext
    kubectl apply -f role.yaml
    ```
    

---

### **Step 6: Bind the Role to the User**

Create a RoleBinding to associate Hassan with the `pod-manager` Role:

```plaintext
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: bind-hassan
  namespace: dev
subjects:
- kind: User
  name: hassan
  apiGroup: ""
roleRef:
  kind: Role
  name: pod-manager
  apiGroup: ""
```

Apply the RoleBinding:

```plaintext
kubectl apply -f rolebinding.yaml
```

---

### **Step 7: Verify Permissions**

Hassan can check their permissions using:

```plaintext
# Check if Hassan can delete pods in the `test` namespace
kubectl auth can-i delete pods -n test
```

Managers can verify Hassan's permissions:

```plaintext
# Verify as Hassan
kubectl auth can-i delete pods --as hassan -n dev

# List roles in the `dev` namespace
kubectl get roles -n dev
```

---

### **Important Notes**

1. **Kubeconfig for Users**: Avoid sharing kubeconfig files with root credentials. Create a dedicated configuration for each user with minimal permissions.
    
2. **Root Access**: Assigning a user to the `cluster-admin` role grants unrestricted access. Use it cautiously.
    
3. **Advanced Environments**: In larger setups, integrate Kubernetes with services like Active Directory for streamlined authentication.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1733311223725/8c353d8f-c4f4-451a-af33-35e36a09e941.png align="center")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1733311236706/0845eb3b-2e38-44d0-bf85-d6d757515b5f.png align="center")

---

## **Conclusion**

RBAC is an essential security practice for Kubernetes clusters, ensuring users and applications only access what they need. By following the steps and examples above, you can implement RBAC effectively in your organization.