Saiyam Pathak avatar
By Saiyam Pathak
Field CTO

Description

In the Kubernetes realm, Role-Based Access Control (RBAC) emerges as a vital tool for ensuring precise access to cluster resources. This lesson provides a hands-on demonstration of RBAC, guiding you through its intricacies, from creating roles to verifying access.


Introduction to RBAC

As seen in our previous lesson. RBAC in Kubernetes is a structured method to manage access. It enables administrators to specify what actions a user or service account can execute on specific cluster resources.

Setting the Stage: Namespace and Service Account

To commence, we'll establish a namespace named demo using the command:

kubectl create namespace demo

Subsequently, a service account named sam is crafted within this namespace:

kubectl create sa sam -n demo

To confirm its creation, execute:

kubectl get serviceaccount -n demo

Delineating Cluster Roles

Cluster roles are pivotal in RBAC. They define the permissions granted to users or service accounts. To create a cluster role that permits specific actions on resources, use:

kubectl create clusterrole cr --verb=get,list,watch,delete --resource=secrets,pods,deployments

Here, the verbs (get, list, watch, delete) represent permissible actions on the resources (secrets, pods, deployments).

Binding Roles: The ClusterRoleBinding

To associate the service account with the cluster role, a ClusterRoleBinding is essential. This binding links the sam service account in the demo namespace to the cr cluster role:

kubectl create rolebinding super --serviceaccount=demo:sam -n demo --clusterrole=cr

Demonstrating RBAC in Action

With the foundational elements in place, let`s deploy resources in the demo namespace:

kubectl run demo --image=nginx --serviceaccount=sam -n demo kubectl create deployment test --image=nginx -n demo

To validate these creations:

kubectl get pods -n demo kubectl get deploy -n demo

Now, to experience RBAC's effectiveness, we'll extract the token of the `sam` service account and set the credentials:

TOKEN=$(kubectl describe secrets "$(kubectl describe serviceaccount sam -n demo| grep -i Tokens | awk `{print $2}`)" -n demo | grep token: | awk `{print $2}`) kubectl config set-credentials test-user --token=$TOKEN

Switching the context to utilize this token:

kubectl config set-context demo --cluster=kubernetes --user=test-user kubectl config use-context demo

Executing kubectl get pods will return forbidden due to the restrictions set by RBAC. However, kubectl get pods -n demo will display the pods in the demo namespace.

To further demonstrate the restrictions, if we try to access the services in the demo namespace:

kubectl get svc -n demo

The response will be forbidden. This behavior confirms that the service account sam can only perform actions as defined by the role we created and bound to it. In essence, we`ve successfully set up the namespace, service account, ClusterRole, and associated them using RoleBinding. We`ve also configured the credentials and context. When we utilize this context, it vividly showcases RBAC in action, ensuring precise access control in Kubernetes.

Conclusion

Through this lesson, we've navigated the RBAC landscape in Kubernetes, from crafting roles to witnessing their enforcement. Grasping RBAC is pivotal for a secure Kubernetes environment.

Civo course complete badge

You've successfully completed our course on Kubernetes configuration and security

We hope you enjoyed learning and encourage you to check out our other courses to further expand your knowledge on Kubernetes