Role Based Access Controls

In this lesson we explore Kubernetes Role-Based Access Control (RBAC): what a Role is, how to create Roles and RoleBindings, and how to test and restrict permissions.

A presentation slide titled "Role-Based Access Control (RBAC)" displayed on a mostly white background with a dark blue curved section showing a padlock icon and a pointing hand. The design includes simple vector graphics and a small copyright notice.

What is a Role?

A Role is a namespace-scoped RBAC object that defines a set of permissions (rules) for resources inside a specific namespace. Roles are composed of one or more rules that specify which API groups, resources, and verbs (actions) are allowed. Optionally, a rule can restrict access to specific resource names. Key fields in a Role rule:

Field	Purpose	Example
`apiGroups`	API group(s) the rule applies to. Leave blank (`""`) for the core API group.	`[""]`
`resources`	Resource types covered by the rule (e.g., `pods`, `configmaps`).	`["pods"]`
`verbs`	Allowed actions (e.g., `get`, `list`, `create`, `delete`).	`["get","create"]`
`resourceNames`	Optional: restrict the rule to specific named resources.	`["blue","orange"]`

Example: create a namespaced Role

developer-role.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer
  namespace: default
rules:
  - apiGroups: [""]            # core API group
    resources: ["pods"]
    verbs: ["get", "list", "create", "delete"]
  - apiGroups: [""]            # core API group
    resources: ["configmaps"]
    verbs: ["create"]

Apply the Role:

kubectl apply -f developer-role.yaml
# or
kubectl create -f developer-role.yaml

Granting the Role: RoleBinding

To grant the permissions defined in a Role to a user, group, or service account within the same namespace, create a RoleBinding. RoleBindings are namespace-scoped and must live in the same namespace as the Role (unless you reference a ClusterRole). Example RoleBinding manifest:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: devuser-developer-binding
  namespace: default
subjects:
  - kind: User
    name: dev-user
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer
  apiGroup: rbac.authorization.k8s.io

Apply the RoleBinding:

kubectl apply -f devuser-developer-binding.yaml
# or
kubectl create -f devuser-developer-binding.yaml

Important: Roles and RoleBindings are namespace-scoped. For cluster-wide permissions, use a ClusterRole and bind it with a ClusterRoleBinding.

Common kubectl commands to view RBAC objects

Command	Purpose
`kubectl get roles`	List Roles in the current namespace
`kubectl get rolebindings`	List RoleBindings in the current namespace
`kubectl describe role <name>`	Show rules defined in a Role
`kubectl describe rolebinding <name>`	Show subjects and referenced Role/ClusterRole

Examples:

kubectl get roles

kubectl get rolebindings

Describe the created Role:

kubectl describe role developer

Example output:

$ kubectl get roles
NAME        AGE
developer   4s

$ kubectl get rolebindings
NAME                        AGE
devuser-developer-binding   24s

$ kubectl describe role developer
Name:        developer
Labels:      <none>
Annotations: <none>
PolicyRule:
  Resources        Non-Resource URLs   Resource Names   Verbs
  ---------        -----------------   --------------   -----
  configmaps       []                  []               [create]
  pods             []                  []               [get watch list create delete]

Describe the RoleBinding:

kubectl describe rolebinding devuser-developer-binding

Example output:

$ kubectl describe rolebinding devuser-developer-binding
Name:        devuser-developer-binding
Labels:      <none>
Annotations: <none>
Role:
  Kind:  Role
  Name:  developer
Subjects:
  Kind   Name      Namespace
  ----   ----      ---------
  User   dev-user

Testing permissions with kubectl auth can-i

Use kubectl auth can-i to test whether a user has a given permission. As the current user:

kubectl auth can-i create deployments
kubectl auth can-i delete nodes
# returns: yes or no

Example:

$ kubectl auth can-i create deployments
yes

$ kubectl auth can-i delete nodes
no

As an administrator you can impersonate a user with --as to test their permissions:

kubectl auth can-i create deployments --as=dev-user

Include a namespace to check namespace-scoped permissions:

kubectl auth can-i create pods --as=dev-user -n test

If dev-user only has pod creation rights in the default namespace, the previous command for the test namespace will return no.

Restricting access to specific named resources

To limit a rule so it only applies to specific named resources, use resourceNames in the rule. Example: allow get on only two pods named blue and orange:

rules:
  - apiGroups: [""]
    resources: ["pods"]
    resourceNames: ["blue", "orange"]
    verbs: ["get"]

This prevents access to any other pods in the namespace.

Remember: Roles and RoleBindings are namespace-scoped. If you need cluster-wide permissions (across all namespaces), use ClusterRole and ClusterRoleBinding instead.

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

Role Based Access Controls

What is a Role?

Example: create a namespaced Role

Granting the Role: RoleBinding

Common kubectl commands to view RBAC objects

Testing permissions with kubectl auth can-i

Restricting access to specific named resources

Further reading and references

Watch Video

Practice Lab

​What is a Role?

​Example: create a namespaced Role

​Granting the Role: RoleBinding

​Common kubectl commands to view RBAC objects

​Testing permissions with kubectl auth can-i

​Restricting access to specific named resources

​Further reading and references

Watch Video

Practice Lab

What is a Role?

Example: create a namespaced Role

Granting the Role: RoleBinding

Common kubectl commands to view RBAC objects

Testing permissions with kubectl auth can-i

Restricting access to specific named resources

Further reading and references