RX-M, a cloud-native training, consulting, and advisory firm, provides vital strategies, insights, and tactical approaches in its Cloud Native Short Takes series. In the latest take, Christian Lacsina discusses and demonstrates Kubernetes Role-based Access Control (RBAC), which allows administrators to define a set of permissions (like the ability to create pods) and assign those permissions to subjects (which are users or programs) using API resources.
Video Transcript
Hello everyone, welcome to RX-M’s latest cloud native short take, I’m Christian Lacsina and today we’ll short take how to work with Kubernetes Service Accounts and grant them permissions to perform tasks within the cluster. Most Kubernetes clusters control the ability of users to perform tasks in the cluster like listing or deleting resources with role-based access control. RBAC as it is known, allows administrators to define a set of permissions like the ability to create pods and assign those permissions to subjects which are users or programs using api resources.
My demo today will show a typical workflow that allows a containerized program running in a Kubernetes cluster to request a list of pods in its own namespace from the Kubernetes api-server. To begin, I need to provide the program with credentials that the api-server will accept. I’ll create a Service Account named pod-lister for this. Once created I can view the Service Accounts in a namespace using kubectl get. At this point I can test that this Service Account can get pods using kubectl --as switch and the Service Account’s generated username which includes the Service Account’s namespace and name. Right now my pod lister Service Account does not have the permission to list pods yet. Assigning these permissions is a two-part process. First I need to create a Role object, I’ll name it pod-listing, that declares the ability, known as “verbs”, to get and list pod resources.
Next i need to assign the Role to my subject: the pod-lister Service Account in the “default” namespace. I’ll create a Role Binding object for that and I’ll name it pod-listing-binding that takes the pod-listing Role and assigns it to the pod-lister Service Account in the default namespace. With both in place I will now try to list pods using the pod-lister Service Account again. Great! My Service Account can now list pods successfully.
Now I’ll need to assign the Service Account to a pod so its credentials are available to the containers in that pod. I can do this by providing the serviceAccountName: key in a pod specification which I have in this pod spec here. I’ll go ahead and create this pod now.
When the pod is created the Service Account’s credentials are automatically mounted in the container’s file system at /var/run/secrets/kubernetes.io. Let’s check that directory. The credential i need is stored in the token file under the Service Account directory.
Now i’ll issue a request to the Kubernetes api-server that passes this Service Account token as its identifier. And there we go! I’ve received a list of my pods in this namespace from the api-server after sending a request from a pod.
You can learn more about RBAC and other topics by building your own custom Kubernetes course here on RX-M.com with the custom course builder.
That’s our cloud native short take on working with Service Accounts and granting them permissions to perform tasks in the cluster.