Lab Role Based Access Controls

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:

1) Identify the API server authorization modes

Check the static manifest used by kube-apiserver:

cat /etc/kubernetes/manifests/kube-apiserver.yaml

Relevant excerpt showing the flag:

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:

ps -aux | grep kube-apiserver

Example output fragment:

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:

kubectl get roles
# or explicitly:
kubectl get roles -n default

Check all namespaces and count:

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:

kubectl describe role kube-proxy -n kube-system

Example output:

Name:        kube-proxy
Labels:      <none>
Annotations: <none>
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:

kubectl get rolebindings -n kube-system

Inspect the specific binding:

kubectl describe rolebinding kube-proxy -n kube-system

Relevant subjects excerpt:

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:

kubectl config view

Excerpt showing users:

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:

kubectl get pods --as dev-user

Expected error:

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:

kubectl create role developer --verb=list,create,delete --resource=pods
# Output:
# role.rbac.authorization.k8s.io/developer created

Verify the Role:

kubectl describe role developer

Output:

Name:        developer
Labels:      <none>
Annotations: <none>
PolicyRule:
  Resources   Non-Resource URLs   Resource Names   Verbs
  ---------   -----------------   --------------   -----
  pods        []                  []               [list create delete]

Bind dev-user to the Role:

kubectl create rolebinding dev-user-binding --role=developer --user=dev-user
# Output:
# rolebinding.rbac.authorization.k8s.io/dev-user-binding created

Verify the RoleBinding:

kubectl describe rolebinding dev-user-binding

Output:

Name:        dev-user-binding
Labels:      <none>
Annotations: <none>
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:

kubectl --as dev-user get pod dark-blue-app -n blue

Error:

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:

kubectl get roles -n blue
# NAME        CREATED AT
kubectl get rolebindings -n blue
# NAME               ROLE             AGE
kubectl describe role developer -n blue

Output:

Name:        developer
Labels:      <none>
Annotations: <none>
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):

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:

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:

kubectl --as dev-user create deployment nginx --image=nginx -n blue

Error:

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:

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

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:

kubectl describe role developer -n blue

Expected policy rules:

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:

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.

Introduction

Core Concepts

Scheduling

Logging & Monitoring

Application Lifecycle Management

Cluster Maintenance

Security

Storage

Networking

Design and Install a Kubernetes Cluster

Install "Kubernetes the kubeadm way"

Troubleshooting

Helm Basics (2025 Updates)

Kustomize Basics (2025 Updates)

Other Topics

Mock Exams

Lab Role Based Access Controls

1) Identify the API server authorization modes

2) Count Roles (default namespace and cluster-wide)

3) Inspect Role permissions: kube-proxy Role in kube-system

4) Find which subjects (accounts/groups) are bound to the kube-proxy Role

5) Confirm `dev-user` exists in the kubeconfig and test current permissions

6) Create Role and RoleBinding to allow pod operations for `dev-user` in default

7) Troubleshoot: `dev-user` cannot get `dark-blue-app` in the `blue` namespace

8) Grant `dev-user` permission to create Deployments (apps API group) in `blue`

Summary

Watch Video

​1) Identify the API server authorization modes

​2) Count Roles (default namespace and cluster-wide)

​3) Inspect Role permissions: kube-proxy Role in kube-system

​4) Find which subjects (accounts/groups) are bound to the kube-proxy Role

​5) Confirm dev-user exists in the kubeconfig and test current permissions

​6) Create Role and RoleBinding to allow pod operations for dev-user in default

​7) Troubleshoot: dev-user cannot get dark-blue-app in the blue namespace

​8) Grant dev-user permission to create Deployments (apps API group) in blue

​Summary

Watch Video

1) Identify the API server authorization modes

2) Count Roles (default namespace and cluster-wide)

3) Inspect Role permissions: kube-proxy Role in kube-system

4) Find which subjects (accounts/groups) are bound to the kube-proxy Role

5) Confirm `dev-user` exists in the kubeconfig and test current permissions

6) Create Role and RoleBinding to allow pod operations for `dev-user` in default

7) Troubleshoot: `dev-user` cannot get `dark-blue-app` in the `blue` namespace

8) Grant `dev-user` permission to create Deployments (apps API group) in `blue`

Summary