> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Lab Role Based Access Controls > Hands on lab demonstrating how to inspect, create, and troubleshoot Kubernetes RBAC Roles and RoleBindings to grant and adjust dev user permissions across namespaces and API groups. This lab walks through inspecting and managing Role-Based Access Control (RBAC) on a Kubernetes cluster. You will: * Confirm the API server's authorization modes. * Inspect existing Roles and RoleBindings. * Create Roles and RoleBindings for a user (`dev-user`). * Troubleshoot permission failures and extend Roles to cover additional API groups. Relevant links and references: * [Kubernetes RBAC docs](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) * [Kubernetes API concepts](https://kubernetes.io/docs/concepts/overview/kubernetes-api/) *** ## 1) Identify the API server authorization modes Check the static manifest used by kube-apiserver: ```bash theme={null} cat /etc/kubernetes/manifests/kube-apiserver.yaml ``` Relevant excerpt showing the flag: ```yaml theme={null} spec: containers: - command: - kube-apiserver ... - --authorization-mode=Node,RBAC ... image: k8s.gcr.io/kube-apiserver:v1.23.0 ``` You can also confirm from the running process: ```bash theme={null} ps -aux | grep kube-apiserver ``` Example output fragment: ```bash theme={null} root@controlplane ~ # ps -aux | grep kube-apiserver root 3630 0.0 0.1 1118196 316984 ? Ssl 22:55 2:07 kube-apiserver --advertise-address=10.48.174.6 --allow-privileged=true --authorization-mode=Node,RBAC ... ``` Conclusion: the API server uses `Node,RBAC` authorization modes. *** ## 2) Count Roles (default namespace and cluster-wide) Check Roles in the default namespace: ```bash theme={null} kubectl get roles # or explicitly: kubectl get roles -n default ``` Check all namespaces and count: ```bash theme={null} kubectl get roles -A --no-headers | wc -l # Output: # 12 ``` Summary: * Default namespace: no Roles shown. * All namespaces combined: 12 Roles. Quick reference (commands and purpose): | Command | Purpose | | - | - | | `kubectl get roles -n default` | List Roles in the `default` namespace | | `kubectl get roles -A` | List Roles across all namespaces | | `kubectl get roles -A --no-headers \| wc -l` | Count Roles cluster-wide | *** ## 3) Inspect Role permissions: kube-proxy Role in kube-system Describe the `kube-proxy` Role: ```bash theme={null} kubectl describe role kube-proxy -n kube-system ``` Example output: ```text theme={null} Name: kube-proxy Labels: Annotations: PolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- configmaps [] [kube-proxy] [get] ``` Key points: * The `kube-proxy` Role grants access to `configmaps`. * It is restricted to the specific `resourceName` `kube-proxy` and only allows the `get` verb. Roles can be scoped to specific resource names using `resourceNames`. Here, the Role allows only `get` on the ConfigMap named `kube-proxy`, not on all ConfigMaps. *** ## 4) Find which subjects (accounts/groups) are bound to the kube-proxy Role List RoleBindings in `kube-system`: ```bash theme={null} kubectl get rolebindings -n kube-system ``` Inspect the specific binding: ```bash theme={null} kubectl describe rolebinding kube-proxy -n kube-system ``` Relevant subjects excerpt: ```text theme={null} Subjects: Kind Name Namespace ---- ---- --------- Group system:bootstrappers:kubeadm:default-node-token ``` Conclusion: `kube-proxy` Role is bound to the group `system:bootstrappers:kubeadm:default-node-token`. *** ## 5) Confirm `dev-user` exists in the kubeconfig and test current permissions View users in kubeconfig: ```bash theme={null} kubectl config view ``` Excerpt showing users: ```yaml theme={null} users: - name: dev-user user: client-certificate-data: REDACTED client-key-data: REDACTED - name: kubernetes-admin user: client-certificate-data: REDACTED client-key-data: REDACTED ``` Test whether `dev-user` can list pods in `default`: ```bash theme={null} kubectl get pods --as dev-user ``` Expected error: ```text theme={null} Error from server (Forbidden): pods is forbidden: User "dev-user" cannot list resource "pods" in API group "" in the namespace "default" ``` Result: `dev-user` lacks permission to list pods in `default`. *** ## 6) Create Role and RoleBinding to allow pod operations for `dev-user` in default Create a Role named `developer` in `default` allowing `list`, `create`, and `delete` on `pods`: ```bash theme={null} kubectl create role developer --verb=list,create,delete --resource=pods # Output: # role.rbac.authorization.k8s.io/developer created ``` Verify the Role: ```bash theme={null} kubectl describe role developer ``` Output: ```text theme={null} Name: developer Labels: Annotations: PolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- pods [] [] [list create delete] ``` Bind `dev-user` to the Role: ```bash theme={null} kubectl create rolebinding dev-user-binding --role=developer --user=dev-user # Output: # rolebinding.rbac.authorization.k8s.io/dev-user-binding created ``` Verify the RoleBinding: ```bash theme={null} kubectl describe rolebinding dev-user-binding ``` Output: ```text theme={null} Name: dev-user-binding Labels: Annotations: Role: Kind: Role Name: developer Subjects: Kind Name Namespace ---- ---- --------- User dev-user ``` Result: `dev-user` can now list, create, and delete pods in the `default` namespace. *** ## 7) Troubleshoot: `dev-user` cannot get `dark-blue-app` in the `blue` namespace Run the failing command as `dev-user`: ```bash theme={null} kubectl --as dev-user get pod dark-blue-app -n blue ``` Error: ```text theme={null} Error from server (Forbidden): pods "dark-blue-app" is forbidden: User "dev-user" cannot get resource "pods" in API group "" in the namespace "blue" ``` Inspect Roles and RoleBindings in `blue`: ```bash theme={null} kubectl get roles -n blue # NAME CREATED AT kubectl get rolebindings -n blue # NAME ROLE AGE kubectl describe role developer -n blue ``` Output: ```text theme={null} Name: developer Labels: Annotations: PolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- pods [] [blue-app] [get watch create delete] ``` Diagnosis: * The `developer` Role in `blue` uses `resourceNames: [blue-app]`, so the Role only applies to the pod named `blue-app`. * `dark-blue-app` is not covered, so `dev-user` is denied. Fix options: * Edit the `developer` Role to include `dark-blue-app` in `resourceNames`. * Or remove `resourceNames` so the role applies to all pods in the namespace (use with caution — see warning). Example Role patch (replace `resourceNames` with `dark-blue-app`): ```yaml theme={null} apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: developer namespace: blue rules: - apiGroups: - "" resources: - pods resourceNames: - dark-blue-app verbs: - get - watch - create - delete ``` Apply the change (for example, `kubectl edit role developer -n blue`) and retry: ```bash theme={null} kubectl --as dev-user get pod dark-blue-app -n blue # Example output: # NAME READY STATUS RESTARTS AGE # dark-blue-app 1/1 Running 0 3d ``` Removing `resourceNames` makes the Role apply to all pods in the namespace. Only do this if you intend to grant broader access; otherwise prefer listing explicit `resourceNames` to maintain least privilege. *** ## 8) Grant `dev-user` permission to create Deployments (apps API group) in `blue` When `dev-user` tried to create a Deployment: ```bash theme={null} kubectl --as dev-user create deployment nginx --image=nginx -n blue ``` Error: ```text theme={null} error: failed to create deployment: deployments.apps is forbidden: User "dev-user" cannot create resource "deployments" in API group "apps" in the namespace "blue" ``` Add a rule to the `developer` Role in `blue` that allows `deployments` in the `apps` API group. Ensure the plural resource name `deployments` is used. Example Role fragment to add: ```yaml theme={null} - apiGroups: - apps resources: - deployments verbs: - get - watch - create - delete ``` A full example `developer` Role that grants both pod access (for `dark-blue-app`) and Deployments: ```yaml theme={null} apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: developer namespace: blue rules: - apiGroups: - "" resources: - pods resourceNames: - dark-blue-app verbs: - get - watch - create - delete - apiGroups: - apps resources: - deployments verbs: - get - watch - create - delete ``` Apply the edit (e.g., `kubectl edit role developer -n blue`) and verify: ```bash theme={null} kubectl describe role developer -n blue ``` Expected policy rules: ```text theme={null} PolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- pods [] [dark-blue-app] [get watch create delete] deployments.apps [] [] [get watch create delete] ``` Now `dev-user` can create a Deployment: ```bash theme={null} kubectl --as dev-user create deployment nginx --image=nginx -n blue # Output: # deployment.apps/nginx created ``` *** ## Summary * Verified the API server is configured with `Node,RBAC`. * Counted Roles cluster-wide (12) and confirmed none in `default`. * Found `kube-proxy` Role only allows `get` on the `kube-proxy` ConfigMap and is bound to the `system:bootstrappers:kubeadm:default-node-token` group. * Created a `developer` Role and RoleBinding in `default` to allow `dev-user` to manage pods there. * Troubleshot a forbidden error in the `blue` namespace caused by `resourceNames` restricting access to `blue-app` rather than `dark-blue-app`. * Extended the Role to include `deployments` in the `apps` API group to allow `dev-user` to create Deployments. Further reading: * [Kubernetes RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) * [Kubernetes API groups and resources](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.27/) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.