Role-Based Access Control (RBAC)

RBAC controls who can do what in the cluster using Roles and RoleBindings.

RBAC (Role-Based Access Control) is how Kubernetes decides whether a request is allowed. It is built from four object types.

Roles: what is allowed

  • A Role grants permissions within one namespace.
  • A ClusterRole grants permissions cluster-wide or on cluster-scoped resources.

Bindings: who gets it

  • A RoleBinding attaches a Role to a user, group, or ServiceAccount in a namespace.
  • A ClusterRoleBinding does the same cluster-wide.

Each rule lists apiGroups, resources, and verbs (get, list, watch, create, update, delete). Permissions are purely additive — there are no "deny" rules.

Example

Example · yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: team-a
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: team-a
  name: read-pods
subjects:
  - kind: ServiceAccount
    name: app-sa
    namespace: team-a
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

When to use it

  • A team creates a Role that allows read-only access to pods and logs in the dev namespace, then binds it to all developers via a RoleBinding.
  • An SRE creates a ClusterRole for node management and binds it to the on-call engineer's user account during incident response.
  • A CI service account is given a Role with only create/update on Deployments in its namespace, following the principle of least privilege.

More examples

Role and RoleBinding for developers

Creates a Role allowing read-only pod and log access, then binds it to all members of the developers group in the development namespace.

Example · yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: dev-viewer
  namespace: development
rules:
  - apiGroups: [""]
    resources: [pods, pods/log]
    verbs: [get, list, watch]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-viewer-binding
  namespace: development
subjects:
  - kind: Group
    name: developers
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: dev-viewer
  apiGroup: rbac.authorization.k8s.io

ClusterRole for node admin

Grants cluster-wide node get/patch/update rights to a named user using a ClusterRole and ClusterRoleBinding.

Example · yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-admin
rules:
  - apiGroups: [""]
    resources: [nodes]
    verbs: [get, list, patch, update]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: oncall-node-admin
subjects:
  - kind: User
    name: [email protected]
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: node-admin
  apiGroup: rbac.authorization.k8s.io

Check permissions with auth can-i

Uses kubectl auth can-i to verify permissions for the current user and to impersonate a ServiceAccount for debugging RBAC.

Example · bash
# Test what the current user can do
kubectl auth can-i create deployments -n production
kubectl auth can-i delete pods --all-namespaces

# Test as a specific service account
kubectl auth can-i get secrets \
  --as=system:serviceaccount:default:deploy-bot

Related

k8s serviceaccountsk8s security

Discussion

  • Be the first to comment on this lesson.