iwantcoding.com
🔥 Daily 👥 Rooms 🏆 Top Log in Sign up

RBAC

By · Reviewed & last updated · Part of Kubernetes Tutorial

Kubernetes RBAC (Role-Based Access Control) is the authorisation layer for the API server. Subjects (users / groups / ServiceAccounts) get Roles (per-namespace) or ClusterRoles (cluster-wide) through RoleBindings.

Real RBAC + namespace scoping

EXAMPLE
# 1) Create a namespace + label it (the boundary that scopes Roles)
kubectl create namespace ops
kubectl label namespace ops env=prod team=platform

apiVersion: v1
kind: Namespace
metadata:
    name:   ops
    labels: { env: prod, team: platform }

# 2) Resource quotas — limit total CPU / RAM / object counts per namespace
apiVersion: v1
kind: ResourceQuota
metadata: { name: ops-quota, namespace: ops }
spec:
    hard:
        requests.cpu:    "8"
        requests.memory: 16Gi
        limits.cpu:      "16"
        limits.memory:   32Gi
        pods:            "40"

# 3) Role — scoped to a namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata: { name: deployer, namespace: ops }
rules:
    - apiGroups: ["apps"]
      resources: ["deployments"]
      verbs:     ["get", "list", "create", "update", "patch"]
    - apiGroups: [""]
      resources: ["pods", "pods/log"]
      verbs:     ["get", "list", "watch"]

# 4) ClusterRole — cluster-wide, OR namespaced (when reused via RoleBinding)
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata: { name: node-reader }
rules:
    - apiGroups: [""]
      resources: ["nodes"]
      verbs:     ["get", "list", "watch"]

# 5) RoleBinding — bind a Role to subjects WITHIN a namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata: { name: ops-deployers, namespace: ops }
subjects:
    - kind: User
      name: ada@example.com
      apiGroup: rbac.authorization.k8s.io
    - kind: ServiceAccount
      name: ci-deployer
      namespace: ops
roleRef:
    kind: Role
    name: deployer
    apiGroup: rbac.authorization.k8s.io

# 6) ClusterRoleBinding — for ClusterRoles applied cluster-wide
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata: { name: sre-node-readers }
subjects:
    - kind: Group
      name: sre
      apiGroup: rbac.authorization.k8s.io
roleRef:
    kind: ClusterRole
    name: node-reader
    apiGroup: rbac.authorization.k8s.io

# 7) Audit your perms — kubectl auth can-i
kubectl auth can-i create deployments -n ops
kubectl auth can-i list nodes
kubectl auth can-i '*' '*' --as=ada@example.com
kubectl auth can-i create pods --as=system:serviceaccount:ops:ci-deployer

# 8) Best practices
#   • Default to namespace-scoped Roles. ClusterRoles only when truly cluster-wide.
#   • Bind to Groups / ServiceAccounts, not individual users.
#   • Avoid verbs: ['*'] — list verbs explicitly.
#   • Use kubectl auth can-i in CI to verify expected access.

Why it matters

Namespaces aren’t a security boundary by themselves — they’re the RBAC boundary. Pair them with ResourceQuotas + NetworkPolicies to make multi-tenant clusters safe and predictable.

Tip: Tweak the snippet with Try it Yourself », then sit the quiz at the bottom of the page.

Example

Example
# Role + RoleBinding (namespace) or ClusterRole + ClusterRoleBinding (cluster-wide).
Try it Yourself »

Discussion

Loading…