RBAC — Kubernetes

Role Based Access Control

Role-based access control (RBAC) is an access control method used to restrict access to certain resources in a computer system or network to only authorized users.

It is based on the roles that users have within an organization, and the permissions that are associated with those roles.

Kubernetes RBAC API Objects

The RBAC API declares four kinds of kubernetes object.

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

RBAC Kubernetes ← Refer

A namespace is a group of related elements that each have a unique name or identifier.

Namespaces provide a method for preventing name conflicts in large projects.

kubectl create ns test
kubectl get ns 

Service accounts are used to provide an identity for pods. Pods that want to interact with the API server will authenticate with a particular service account.

Create a serviceaccount.yml file

apiVersion: v1
kind: ServiceAccount
metadata:
  name: foo
  namespace: test

Apply the file

kubectl apply -f serviceaccount.yml

The Service account created namespace called foo.

Permission asset assigned to the service account → Just created Service account only does not have permission.

How to check permission give

kubectl auth can-i --as system:serviceaccount:test:foo get pods -n test

No → Does not have rules associated. So created a role.yaml

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: test
  name: testadmin
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]

Created a role.yml

kubectl apply -f role.yml 

Again try the cmd

kubectl auth can-i --as system:serviceaccount:test:foo get pods -n test

Still show the same pop up

Just created a rule but did not bind it with the service account

ClusterRoles → Roles define the actions a user can perform within a cluster or namespace.

RoleBinding → grants permissions within a specific namespace whereas a ClusterRoleBinding grants that access cluster-wide

Created a rolebinding.yml

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: testadminbinding
  namespace: test
subjects:
- kind: ServiceAccount
  name: foo
  apiGroup: ""
roleRef:
  kind: Role
  name: testadmin
  apiGroup: ""

kubectl apply -f rolebinding.yml

Let’s try the same cmd

kubectl auth can-i --as system:serviceaccount:test:foo get pods -n test

kubectl auth can-i --as system:serviceaccount:test:foo create pods -n test
kubectl auth can-i --as system:serviceaccount:test:foo create deploy -n test

If you get create, delete access in specific namespace. Check the another namespace the access given or not

kubectl auth can-i --as system:serviceaccount:test:foo create pods -n kube-system

Access given only role binding only not cluster role binding. Create a clusterrolebinding.yml file given access to the cluster

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: testadminclusterbinding
subjects:
- kind: ServiceAccount
  name: foo
  apiGroup: ""
  namespace: test
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: ""

Lets create a apply cmd

kubectl apply -f clusterrolebinding.yml

Now check the cmd

kubectl auth can-i --as system:serviceaccount:test:foo create pods -n kube-system

kubectl auth can-i --as system:serviceaccount:test:foo delete deploy -n kube-system
kubectl auth can-i --as system:serviceaccount:test:foo delete deploy -n default

Assigned with cluster role & cluster role binding it can do everything (R,W,X) specific cluster.