RBAC in Kubernetes: A Hands-on Lesson
Civo Academy - Role-Based Access Control (RBAC) in Kubernetes
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.
These may also be of interest
Guides for kubernetes-security
Protect your Kubernetes cluster and apps from security threats with our comprehensive tutorials. Build a strong security foundation today!
Solving the Never Ending Requirements of Authorization
Discover a better way to handle authorization challenges in software systems and learn about a more efficient and scalable solution using an authorization service called Cerbos.
Guides for kubernetes
Learn to orchestrate and manage large-scale containerized applications with our in-depth Kubernetes tutorials. Gain practical experience for success!