VOOZH about

URL: https://dzone.com/articles/using-rbac-with-service-accounts-in-kubernetes

⇱ Using RBAC with Service Accounts in Kubernetes


Related

  1. DZone
  2. Software Design and Architecture
  3. Cloud Architecture
  4. Using RBAC with Service Accounts in Kubernetes

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.

By Sep. 04, 20 · Tutorial
Likes
Comment
Save
23.3K Views

Join the DZone community and get the full member experience.

Join For Free

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 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: . 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 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.

Kubernetes

Opinions expressed by DZone contributors are their own.

Related

  • Zero-Downtime Deployments for Java Apps on Kubernetes
  • Self-Hosted Inference Doesn’t Have to Be a Nightmare: How to Use GPUStack
  • Smart Deployment Strategies for Modern Applications
  • How We Diagnosed a Hidden Scheduler Failure in a Docker Swarm Cluster Serving 2 Million Users

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

Let's be friends: