Roles

Roles define permissions inside one namespace.

Use a Role when an application, team, or automation process only needs access to resources in a specific namespace. This is the safest default for most application workloads.

Role Example

This Role allows reading ConfigMaps in the lab namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: configmap-reader
  namespace: lab
rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list", "watch"]

Apply it:

kubectl apply -f - <<'YAML'
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: configmap-reader
  namespace: lab
rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list", "watch"]
YAML

Bind The Role

Create a service account:

kubectl create serviceaccount configmap-reader-sa --namespace=lab

Create a RoleBinding:

kubectl create rolebinding configmap-reader-binding \
  --role=configmap-reader \
  --serviceaccount=lab:configmap-reader-sa \
  --namespace=lab

Now check access:

kubectl auth can-i list configmaps \
  --as system:serviceaccount:lab:configmap-reader-sa \
  --namespace=lab

Expected output:

yes

Check access in another namespace:

kubectl auth can-i list configmaps \
  --as system:serviceaccount:lab:configmap-reader-sa \
  --namespace=default

Expected output:

no

That is the point of a Role: the permission stays inside the namespace where it is bound.

Resource Names

Roles can limit access to specific object names:

rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    resourceNames: ["app-config"]
    verbs: ["get"]

This can be useful, but it has limits. For example, list and watch usually do not work cleanly with resourceNames because those verbs operate over collections.

Clean Up

kubectl delete rolebinding configmap-reader-binding --namespace=lab
kubectl delete role configmap-reader --namespace=lab
kubectl delete serviceaccount configmap-reader-sa --namespace=lab

Practical Guidance

Use Roles when:

• the workload only needs one namespace
• a team owns one namespace
• an automation job operates on one application environment
• you want a clear permission boundary

Avoid using Roles to grant access to sensitive resources by habit. Reading Secrets, creating pods, using pods/exec, and updating workloads can all create paths to higher privilege.