{{announcement.body}}
{{announcement.title}}

Using RBAC with Service Accounts in Kubernetes

DZone 's Guide to

Using RBAC with Service Accounts in Kubernetes

This article will help you to manage granular level access on resources in your Kubernetes cluster with service accounts.

· Cloud Zone ·
Free Resource

Kubernetes doesn’t maintain a database or profiles of users and passwords. Instead, it expects it to be managed outside of the cluster.  The role of RBAC is to authorize the requests. We will be creating a pod read-only user (Service account) which can get, list, watch any pod in selected namespaces.

What is RBAC?

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

RBAC authorization uses the rbac.authorization.k8s.io API group to drive authorization decisions, allowing you to dynamically configure policies through the Kubernetes API.

The RBAC API declares four kinds of Kubernetes objects: Role, ClusterRole, RoleBinding, and ClusterRoleBinding. You can describe objects, or amend them, using tools such as kubectl, just like any other Kubernetes object.

What is a Service Account?

In Kubernetes, 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. By default, applications will authenticate as the default service account in the namespace they are running in. This means, for example, that an application running in the test namespace will use the default service account of the test namespace.

Verify RBAC is Enabled :

Shell
 




xxxxxxxxxx
1


 
1
$ kubectl api-versions
2
verify following api version is present in below output
3
rbac.authorization.k8s.io/v1
4
rbac.authorization.k8s.io/v1beta1



Create a read-only Service Account that has access to limited default namespace only.  

  • Create a service account 
Shell
 




xxxxxxxxxx
1


 
1
$ kubectl create serviceaccount udef-pod-reader -n default
2
serviceaccount/udef-pod-reader created



  • Create a role with get, list, and watch perm on default namespace
Shell
 




xxxxxxxxxx
1
12


 
1
$ cat default-pod-role.yaml
2
kind: Role
3
apiVersion: rbac.authorization.k8s.io/v1beta1
4
metadata:
5
   name: udefreadonly
6
   namespace: default
7
rules:
8
 - apiGroups: [""]
9
   resources: ["pods"]
10
   verbs: ["get", "list", "watch"]
11
 
12
$ kubectl apply -f default-pod-role.yaml



  • Create role binding to bind the above role with the service account.
Shell
 




xxxxxxxxxx
1
16


1
$ cat default-pod-binding.yaml
2
kind: RoleBinding
3
apiVersion: rbac.authorization.k8s.io/v1beta1
4
metadata:
5
   name: udefreadonlybinding
6
   namespace: default
7
subjects:
8
 - kind: ServiceAccount
9
   name: udef-pod-reader
10
   namespace: default
11
roleRef:
12
   kind: Role
13
   name: udefreadonly
14
   apiGroup: rbac.authorization.k8s.io
15
 
16
$ kubectl apply -f default-pod-binding.yaml


 

  • Get the token for the service account from secrets 
Shell
 




xxxxxxxxxx
1


 
1
$ TOKEN=$(kubectl describe secrets "$(kubectl describe serviceaccount udef-pod-reader -n default| grep -i Tokens | awk '{print $2}')" -n default | grep token: | awk '{print $2}')
2
 
          



  • Set the token in config credentials, I am using the test-user as the username. It can be different in your case, you can set it any name you want.
Shell
 




xxxxxxxxxx
1


 
1
$ kubectl config set-credentials test-user --token=$TOKEN


 

  • Set the context in Kube config, check your cluster name to specify in --cluster option
Shell
 




xxxxxxxxxx
1


 
1
$ kubectl config set-context udefpodreader --cluster=NAME_OF_YOUR_CLUSTER --user=test-user



  • Set the current context to use the new podreader context
Java
 




xxxxxxxxxx
1


 
1
$ kubectl config use-context udefpodreader



  • Check if you now have access to pods in the default namespace.
Shell
 




xxxxxxxxxx
1


1
$ kubectl get pods
2
NAME READY STATUS RESTARTS AGE
3
p-pod 1/1 Running 0 100d



  • Check if you now have access to other namespaces.
Shell
 




x


1
$ kubectl get pods -n kube-system
2
Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:default:udef-pod-reader" cannot list resource "pods" in API group "" in the namespace "kube-system"


 

  • Check if you have access to all namespaces 
Shell
 




xxxxxxxxxx
1


 
1
$ kubectl get pods --all-namespaces
2
Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:default:udef-pod-reader" cannot list resource "pods" in API group "" at the cluster scope
3
 
          



  • Other ways to verify
Shell
 




x


1
$ kubectl auth can-i get pods --all-namespaces
2
no
3
 
          
4
$ kubectl auth can-i get pods -n default
5
yes
6
 
          
7
$ kubectl auth can-i create pods
8
no
9
 
          
10
$ kubectl auth can-i delete pods
11
no



Conclusion

This article provides details about Roles and Role Bindings, it will also help you to use RBAC using Service Accounts in Kubernetes, in case you do not have an authentication process setup.  You will be able to restrict your users to particular namespaces using service accounts.

Topics:
devops, kubernetes, rbac

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}