Understanding Kubernetes RBAC

Filed Under: Random
Kubernetes RBAC

Hello, readers! In this article, we will be focusing on Kubernetes RBAC, in detail.

So, let us begin! 馃檪


What is Kubernetes RBAC?

Kubernetes provides us with various resources to build up and manage the cluster. Post which, we can have multiple applications aboard and orchestrate them.

But, have you ever thought that if multiple applications get hosted on the cluster then how are we going to segregate the boundaries in terms of access and permissions? So that, nobody gets to view or manipulate someone else’s deployments or data?

Here we goooo….

Kubernetes provides us with RBAC [Role-Based-Access-Control] API that enables us to grant necessary and limited access and permissions in terms of roles to the individual users as well as entire group.

Under the RBAC API, kubernetes provides us with the below four objects:

  1. Role
  2. RoleBinding
  3. ClusterRole
  4. ClusterRoleBinding

Let us have a look at each one of them in the upcoming sections.


1. Kubernetes Role

Kubernetes Role is a set of permissions (always being additive) for a particular namespace. That is, we can define some set of access rules or permissions and frame them as a role that is applicable only at a namespace level.

Let us now try to create a Kubernetes role through the YAML structure: pod-role.yaml

In the below YAML structure, we have rbac.authorization.k8s.io API group and have granted the permission to view the list of Pods from the namespace ‘demo’.

We can apply the rule/permission on the various resources such as pods, deployments, etc.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: demo
  name: list-pod
rules:
- apiGroups: [""] 
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

We can view the role applied to the namespace using the below command:

kubectl get role -n demo

2. Kubernetes RoleBinding

With roles being assigned, now is the time to grant those roles to the users. Kubernetes RoleBinding helps us assign the designed roles to the users.

Let us have at the below YAML structure:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: watch-pod
  namespace: demo
subjects:
- kind: User
  name: Joe # "name" is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role 
  name: list-pod
  apiGroup: rbac.authorization.k8s.io

As seen above, we refer the role to which we want the users or groups to be accountable for. For the same, we refer the name of the Role created in the rolebinding yaml structure. In the above YAML, we have provided a Role to List Pods in the namespace ‘demo’ to the user ‘Joe’ through RoleBinding.

In simple words, RoleBinding assigns and decides the subjects(the individual) to whom the set of permissions (Role) would be granted.


3. Kubernetes ClusterRole

As seen above, Role is a set of permissions that is totally applicable on the Namespace level. That is, it is only restricted for a Namespace. The individual to whom we grant the role does not have any access on the Cluster Level.
For the same, Kubernetes ClusterRole comes into picture.

ClusterRole is a set of permissions that is applicable on the Cluster level. That is, it sets permissions and access limitations on the cluster level objects such as secrets, Persistent volumes, etc.

ClusterRole.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: list-secret
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

In this example, we have provided cluster level roles. That is, it defines a role to list or get the list of secrets for all namespaces within the cluster.


4. Kubernetes ClusterRoleBinding

In order to bind the ClusterRole to a user or a group, we make use of ClusterRoleBinding. It binds or wraps a set of roles at cluster level to a user or a group. With this, the defined user would have the clusterrole set over the entire cluster.

ClusterRoleBinding.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: get-secret
subjects:
- kind: Group
  name: Orchestrator # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: list-secret
  apiGroup: rbac.authorization.k8s.io

In the above YAML, we have given the Orchestrator group cluster listing secret role over the entire cluster through ClusterRoleBinding.


Conclusion

By this, we have come to the end of this topic. Feel free to comment below, in case you come across any question.

For more such posts related to Kubernetes, Stay tuned with us!

Till then, Happy Learning!! 馃檪

Leave a Reply

Your email address will not be published. Required fields are marked *

close
Generic selectors
Exact matches only
Search in title
Search in content