Skip to main content

Command Palette

Search for a command to run...

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

Updated
3 min read
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).

# 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).

# 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.

# 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:

     mkdir -p ~/.kube
    
  2. Copy the necessary config file from the manager (without root credentials).

  3. Install kubectl on the workstation:

     sudo snap install kubectl --classic
    
  4. Set user credentials in the Kubernetes context:

     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:

     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:

     kubectl apply -f role.yaml
    

Step 6: Bind the Role to the User

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

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:

kubectl apply -f rolebinding.yaml

Step 7: Verify Permissions

Hassan can check their permissions using:

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

Managers can verify Hassan's permissions:

# 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.


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.

More from this blog

DevOps Journey with M Hassan

174 posts

I am writing these blogs because I recently completed a comprehensive DevOps course where I gained in-depth knowledge of the topics mentioned. As I progressed through the course, I realized the importance of having a concise and accessible resource to revise and reinforce my understanding of each topic. Therefore, I decided to create cheat sheets in the form of blog posts. These cheat sheets will not only serve as a handy reference for myself but also benefit others who are also interested in mastering DevOps concepts. By documenting each topic and providing concise explanations, I aim to create a valuable resource that simplifies complex concepts and facilitates hands-on practice. This way, I can solidify my own understanding while helping others on their DevOps journey.