Kubernetes Cluster - RBAC Examples

Creating Service Account

Run the following command to add a new service account called king:

$ kubectl create serviceaccount king
serviceaccount/king created

Find the name of the secret that stores the service account’s token:

$ kubectl describe serviceaccount king
Name:               king
Namespace:          default
Labels:             <none>
Annotations:        <none>
Image pull secrets:  <none>
Mountable secrets:   king-token-zkiwb
Tokens:             king-token-zkiwb
Events:             <none>

The secret’s name is king-token-zkiwmb. Retrieve the token’s value from the secret using the following command:

$ TOKEN=$(kubectl describe secret king-token-zkiwb | grep token: | awk '{print $2}')
$ echo $TOKEN
eyjygfDDi...

With the token extracted, you can add your user as a new kubectl context:

$ kubectl config set-credentials king --token=$TOKEN
User "king" set.

$ kubectl config set-context king --cluster=kubernetes --user=king
Context "king" created.

If your current cluster connection is not called kubernetes, you should change the value of the --cluster flag.

Now you can switch to your king context to run kubectl commands as your new service account user. Run the current-context command first to check the name of your currently selected context you’ll be switching back to it in a moment.

$ kubectl config current-context
default
$ kubectl config use-context king
Switched to context "king".

Try to retrieve the pods in your cluster:

$ kubectl get pods
Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:default:king" cannot list resource "pods" in API group "" in the namespace "default"

Kubernetes has issued a Forbidden error. The king service account has been recognized, but because no roles have been created or assigned, it lacks permission to run the get pods command.

Creating a Role

Switch back to your original context before continuing, so you regain your administrative privileges:

$ kubectl config use-context default
Switched to context "default".

Kubernetes role objects are created in the standard way. You write a YAML file that defines the role’s rules, then use kubectl to add it to your cluster.

To keep things simple, you’ll use the “Developer” role example from earlier:

role.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: Developer
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["create", "get", "list"]

Users who are assigned this role will be able to run the create pod, get pod, get pods, and describe pod commands. They won’t be able to update or delete pods, or perform actions that target other resource types.

Use kubectl to add the role to your cluster:

$ kubectl apply -f role.yaml
role.rbac.authorization.k8s.io/Developer created
Creating a RoleBinding

A role on its own has no effect on your cluster’s access control. It needs to be bound to users with a RoleBinding. Create this object now to grant your king service account the permissions associated with your Developer role:

role-binding.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: default
  name: DeveloperRoleBinding
subjects:
  - kind: ServiceAccount
    name: king
    apiGroup: ""
roleRef:
  kind: Role
  name: Developer
  apiGroup: ""

The subjects field lists the objects that will be granted the permissions included in the role. In this example, you’re adding a single ServiceAccount subject to represent your king user. You can target a User or Group instead by adjusting the subject’s Kind accordingly.

The roleRef field identifies the role that will be bound to the subjects. The kind can be either Role or ClusterRole, depending on the type of role you’ve created. In this example, the Developer role is a regular role.

Add the RoleBinding to your cluster using kubectl:

$ kubectl apply -f role-binding.yaml
rolebinding.rbac.authorization.k8s.io/DeveloperRoleBinding created

Testing Your RBAC Policy

The RoleBinding should have granted your king service account the permissions included in the Developer role. Verify this by switching back to your king context:

$ kubectl config use-context king
Switched to context "king".

Repeat the get pods command:

$ kubectl get pods
No resources found in default namespace.

This time the command succeeds. The get pods operation is permitted by the Developer role, which is now assigned to the king service account you’re authenticated as.

Create a new pod:

$ kubectl run nginx --image=nginx
pod/nginx created

This operation is permitted, too. Now, try to delete the superfluous pod:

$ kubectl delete pod nginx
Error from server (Forbidden): pods "nginx" is forbidden: User "system:serviceaccount:default:king" cannot delete resource "pods" in API group "" in the namespace "default"

Kubernetes rejects the operation because the king service account doesn’t have a role that provides a suitable permission. This kingnstrates how you can use Role and RoleBinding objects to restrict how users interact with your cluster.