Canarys | IT Services

Blogs

Kubernetes RBAC (Role Based Access Control)

Share

The Kubernetes RBAC (role bases access control) system helps us in defining set of rules in controlling the access among users across resources. Kubernetes cluster by default has two name spaces, “default” and “kube-system”. Creation of additional namespaces is also possible for organizing and separation of work based on our purpose which I have already explained in previous blog on namespaces (“refer that for more details”).

Access granting can be done either at cluster level or within in a namespace, to grant access at cluster level we need cluster roles. For a particular namespace we can use regular role. How to create a role in K8S, we do that by creating role object. Create a role definition file with apiVersion set to rabc.authorization.k8s.io/v1 and set kind to role.in this case we named the role as shanmukha, as we are creating role for Shanmukha and then specify the rules. Each rule has three sections api groups, resources, and verbs, for core api groups we can leave apiVersion as blank, for any other specify the group name. will specify to what resources we have access and actions that they can do, set under verbs, we can add multiple rules as well for a single role. Role definition YAML looks like below

Role.definition.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
 name: shanmukha
rules:
- apiGroups: [""]
  resources: ["Pods"]
  verbs: ["list" "get" "create" "watch"]
- apiGroups: [""]
  resources: ["configMap"]
  verbs: ["create']
then create a role by kubectl create -f role.defintion.yaml

Next step will be to link the user to the role, for this we create another object called ROLE BINDING, we will name it as shanmukha-aksuser-binding.yaml , kind set to RoleBinding, it has two sections subjects and roleRef. Subjects; where we will define user details, roleRef will provide details of role what we have created, role binding YML looks as below

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata: 
 name: shanmukha-aksuser-binding
subjects:
- kind: User
  name: shanmukha
  apiGroup: rbac.authorization.k8s.io
roleRef:
 kind: Role
 name: shanmukha
 apiGroup: rbac.authorization.k8s.io
create the role binding using  #kubectl create -f shanmukha.aksuser.binding.yml

As I mentioned already, the roles and role binding falls under the scope of namespaces, if you want to specify the namespaces for roles and role binding add namespaces under metadata

some kube controls are:

kubectl get roles
kubectl get rolebindings
kubectl describe role shanmukha
kubectl describe rolebinding  shanmukha-aksuser-binding

what if you being an user and you want to check weather you got access to particular resources or not, for that execute

kubectl auth can-i create deployments
kubectl auth can-i  watch pods

if you want to test it rather authenticating it, in that case execute

kubectl auth can-i create deployments  --as dev-user

you can also provide namespace as well

kubectl auth can-i create deployments  --as dev-user –namespace 

if you want to give access to specific pods in resources, for example assume you have pods A B C D rather than giving access to giving entire resource we can restrict the access levels to particular pods like

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
 name: shanmukha
rules:
- apiGroups: [""]
  resources: ["Pods"]
  verbs: ["list" "get" "create" "watch"]
  resourceNames: ["A" "B" "c"]

permissions are purely additive { there are no “deny” rules} for more info refer Kubernetes.io

you can test the manifest file of rbac objects, for what would be the displaying changes that would be made

kubectl auth reconcile -f < yaml file> --dry-run=client

Leave a Reply

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

Reach Us

With Canarys,
Let’s Plan. Grow. Strive. Succeed.