Using RBAC with Service Accounts in Kubernetes

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 :

xxxxxxxxxx

$ kubectl api-versions

verify following api version is present in below output

rbac.authorization.k8s.io/v1

rbac.authorization.k8s.io/v1beta1

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

• Create a service account 

xxxxxxxxxx

$ kubectl create serviceaccount udef-pod-reader -n default

serviceaccount/udef-pod-reader created

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

xxxxxxxxxx

$ cat default-pod-role.yaml

kind: Role

apiVersion: rbac.authorization.k8s.io/v1beta1

metadata:

   name: udefreadonly

   namespace: default

rules:

 - apiGroups: [""]

   resources: ["pods"]

   verbs: ["get", "list", "watch"]

$ kubectl apply -f default-pod-role.yaml

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

xxxxxxxxxx

$ cat default-pod-binding.yaml

kind: RoleBinding

apiVersion: rbac.authorization.k8s.io/v1beta1

metadata:

   name: udefreadonlybinding

   namespace: default

subjects:

 - kind: ServiceAccount

   name: udef-pod-reader

   namespace: default

roleRef:

   kind: Role

   name: udefreadonly

   apiGroup: rbac.authorization.k8s.io

$ kubectl apply -f default-pod-binding.yaml

• Get the token for the service account from secrets 

xxxxxxxxxx

$ 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}')

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

xxxxxxxxxx

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

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

xxxxxxxxxx

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

• Set the current context to use the new podreader context

xxxxxxxxxx

$ kubectl config use-context udefpodreader

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

xxxxxxxxxx

$ kubectl get pods

NAME READY STATUS RESTARTS AGE

p-pod 1/1 Running 0 100d

• Check if you now have access to other namespaces.

x

$ kubectl get pods -n kube-system

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 

xxxxxxxxxx

$ kubectl get pods --all-namespaces

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

• Other ways to verify

x

$ kubectl auth can-i get pods --all-namespaces

no

$ kubectl auth can-i get pods -n default

yes

$ kubectl auth can-i create pods

no

$ kubectl auth can-i delete pods

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.