This lab explores role-based access controls in Kubernetes, covering API server configuration, roles, permissions, and creating roles and bindings for users.
In this lab, we explore role-based access controls (RBAC) in Kubernetes. The tutorial covers inspecting the API server configuration, reviewing roles and permissions, and creating the necessary roles and bindings for a development user. Follow along to gain hands-on experience with securing your Kubernetes cluster.──────────────────────────────
Start by inspecting the kube-apiserver manifest to identify the configured authorization modes. In the manifest snippet below, note the use of “Node,RBAC” for the authorization mode:
From the output, the kube-proxy role is limited to performing the “get” action on ConfigMap resources only. It cannot delete or update ConfigMaps.──────────────────────────────
Test the permissions for the “dev-user” by listing pods in the default namespace:
root@controlplane ~ ⮀ k get pods --as dev-userError from server (Forbidden): pods is forbidden: User "dev-user" cannot list resource "pods" in API group "" in the namespace "default"
This error confirms that the “dev-user” currently lacks permission to list pods in the default namespace.──────────────────────────────
Before proceeding, review how to create a role in Kubernetes. The following command creates a role named “developer” granting list, create, and delete permissions on pods. Notice that the correct flag is —resource (singular):
root@controlplane ~ ➜ k create role developer --verb=list,create,delete --resource=podsrole.rbac.authorization.k8s.io/developer created
Next, assign the “developer” role to “dev-user” by creating a role binding:
root@controlplane ~ ⟩ k create rolebinding dev-user-binding --role=developer --user=dev-userrolebinding.rbac.authorization.k8s.io/dev-user-binding created
Verify the role binding:
root@controlplane ~ ⟩ k describe rolebinding dev-user-bindingName: dev-user-bindingLabels: <none>Annotations: <none>Role: Kind: Role Name: developerSubjects: Kind Name ---- ---- User dev-user
Suppose the dev-user tries to retrieve details of a pod named “dark-blue-app” in the blue namespace:
k --as dev-user get pod dark-blue-app -n blue
The error received is:
Error from server (Forbidden): pods "dark-blue-app" is forbidden: User "dev-user" cannot get resource "pods" in API group "" in the namespace "blue"
Upon inspection, the blue namespace has an existing “developer” role and the “dev-user-binding” role binding:
root@controlplane ~ ✗ k get roles -n blueNAME CREATED ATdeveloper 2022-04-17T23:25:04Zroot@controlplane ~ ✗ k get rolebindings -n blueNAME ROLE AGEdev-user-binding Role/developer 24m
Currently, the “developer” role in the blue namespace grants permission only for the pod “dark-blue-app.” To provide the dev-user with the ability to manage that pod and to create new deployments, update the role to include rules for handling deployments in the “apps” API group. Below is an example of the updated role:
Save the changes, then test the configuration by creating a deployment as the dev-user:
root@controlplane ~ ⟫ k --as dev-user create deployment nginx --image=nginx -n bluedeployment.apps/nginx created
The successful creation of the deployment confirms that the necessary permissions have been granted.
Always verify RBAC changes by testing user permissions in the designated namespace to ensure that the intended access is provided while maintaining security.
