Hello, readers! In this article, we will be focusing on Kubernetes RBAC, in detail.
So, let us begin! 🙂
Table of Contents
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:
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.
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.
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.
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!! 🙂