pixelpiloten "articles and tutorials into all things Docker containers, Kubernetes,
CI/CD and automating infrastructure"
Go back to blogposts
Sunday, 21 July 2019

RBAC - Controlling user access in Kubernetes - Part 1

RBAC - Controlling user access in Kubernetes - Part 1

This will be a series of blogposts as I dive into RBAC in Kubernetes. I’m going to try to take this in as small chunks as possible as I am to learning this as I write these blogposts, and please forgive any factual errors that will occur because of this.

What is RBAC?

The kubernetes documentation describes RBAC as:

“Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within an enterprise.”

So what this means is that you can create Users and Roles that that will have access to different parts in your Kubernetes cluster. When you install Kubernetes with Minikube for example you will get the equivelent of “root access” on that cluster. Which means that this user has the permissions to EVERYTHING in your cluster, and this is a bad idea if you want to give access other people than yourself to the cluster. Maybe you want to give a user access to only a specific Namespace where that user can list the Pods, describe Pods, but NOT exec into the containers. And thats where RBAC comes into play.

Role vs. ClusterRole

Do you want a Role limited to a specific Namespace or the whole cluster?

Role

A Role is tied to a Namespace, and what ever rules you attach to that role will be, well the rules for that User in that Specified namespace.

So for instance in this example I am creating a Role that can list and describe pods in the “pixelpiloten-blog” Namespace, but only that. This Role cannot check any logs or Exec into any containers or access any other resources than Pods within this Namespace and outside it.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role # Defines Role or ClusterRole
metadata:
  namespace: pixelpiloten-blog # Name of the Namespace this Role should be attached to.
  name: pixelpiloten-blog # Name of this Role.
rules:
- apiGroups: [""]
  resources: ["pods"] # What kind of recources should this Role be able to work with.
  verbs: ["get", "watch", "list"] # What things should this Role be able to do with the resources mentioned above.

ClusterRole

A ClusterRole is a Role that is cluster wide, which means the Rules we attach to it will be across all Namespaces. The rules you can attach to a ClusterRole are the same as the Rules you can attach to a regular Role but you can also give it access to Nodes for example.

In this example I’m creating a ClusterRole that can access all Kubernetes Secrets in all namespaces, and it looks exactly like the Role definition above except we skip the Namespace section.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole # Defines Role or ClusterRole
metadata:
  name: pixelpiloten-all-pod-secrets # Name of this Role.
rules:
- apiGroups: [""]
  resources: ["secrets"] # What kind of recources should this Role be able to work with.
  verbs: ["get", "watch", "list"] # What things should this Role be able to do with the resources mentioned above.

In conclusion

So, thats it. First peak into RBAC in Kubernetes. We’ve learned to create a Role and a ClusterRole and we’ve learned to attach permissions (see Rules) to them. In my next blogpost I’ll go through how to bind a User to a Role.