K8S Rbac

← Back to all decks

25 cards — 🟢 4 easy | 🟡 4 medium | 🔴 4 hard

🟢 Easy (4)

1. What is the difference between a Role and a ClusterRole in Kubernetes RBAC?

Show answer

A Role grants permissions within a single namespace. A ClusterRole grants permissions cluster-wide and is required for cluster-scoped resources (nodes, namespaces, PVs). A ClusterRole can also be referenced by a namespace-scoped RoleBinding to reuse permission definitions across namespaces.

Remember: Role=namespaced, ClusterRole=cluster-wide. Binding=namespaced, ClusterRoleBinding=global.

2. What are the standard RBAC verbs in Kubernetes and what API operations do they map to?

Show answer

get (GET single resource), list (GET collection), watch (GET streaming), create (POST), update (PUT full replace), patch (PATCH partial modify), delete (DELETE single), deletecollection (DELETE multiple). Special verbs include bind, escalate, and impersonate.

Remember: RBAC = 4 objects: Role, ClusterRole, RoleBinding, ClusterRoleBinding. "2 Roles + 2 Bindings."

3. What is a ServiceAccount and why should you set automountServiceAccountToken to false?

Show answer

A ServiceAccount is the identity a pod uses to authenticate to the Kubernetes API. Every pod uses one (default SA if not specified). Setting automountServiceAccountToken: false prevents the API token from being mounted into pods that do not need API access, reducing the blast radius if a pod is compromised.

Remember: Every namespace gets `default` SA. Best practice: dedicated SA per workload.

Gotcha: K8s 1.24+: SA tokens no longer auto-mounted as secrets. Use TokenRequest API.

4. What is the difference between a RoleBinding and a ClusterRoleBinding?

Show answer

A RoleBinding grants permissions within one namespace. A ClusterRoleBinding grants permissions across all namespaces. A RoleBinding can reference a ClusterRole (scoping it to one namespace), while a ClusterRoleBinding always grants cluster-wide access. The binding type determines the scope, not the role type.

Remember: Role=namespaced, ClusterRole=cluster-wide. Binding=namespaced, ClusterRoleBinding=global.

🟡 Medium (4)

1. How do you use kubectl auth can-i to debug RBAC permissions?

Show answer

kubectl auth can-i -n checks your own permissions. Use --as=system:serviceaccount:: to impersonate another identity. kubectl auth can-i --list -n shows all permissions for the current user in that namespace. This is the primary RBAC debugging tool.

Remember: RBAC = 4 objects: Role, ClusterRole, RoleBinding, ClusterRoleBinding. "2 Roles + 2 Bindings."

2. Describe a least-privilege RBAC pattern for a CI/CD deployer service account.

Show answer

Create a namespace-scoped Role with only the verbs and resources needed: get/list/create/update/patch on deployments (apps group), services, and configmaps. Bind it with a RoleBinding to a dedicated ServiceAccount in the CI namespace. Never use ClusterRoleBinding. Never grant delete on namespaces or access to secrets unless specifically required.

Remember: Every namespace gets `default` SA. Best practice: dedicated SA per workload.

Gotcha: K8s 1.24+: SA tokens no longer auto-mounted as secrets. Use TokenRequest API.

3. How do aggregated ClusterRoles work and when should you use them?

Show answer

Aggregated ClusterRoles use label selectors to automatically merge rules from multiple ClusterRoles. The built-in admin, edit, and view roles aggregate from roles labeled rbac.authorization.k8s.io/aggregate-to-view, etc. Use aggregation when you add CRDs and want their permissions included in the default roles. Never edit built-in roles directly.

Remember: Role=namespaced, ClusterRole=cluster-wide. Binding=namespaced, ClusterRoleBinding=global.

4. Why does granting get on pods NOT allow reading pod logs?

Show answer

Pods and pods/log are separate resources in the Kubernetes API. RBAC rules must explicitly list subresources. Similarly, pods/exec, pods/portforward, and deployments/scale are distinct resources that require their own permission grants. Forgetting subresources is a common RBAC mistake.

Remember: RBAC = 4 objects: Role, ClusterRole, RoleBinding, ClusterRoleBinding. "2 Roles + 2 Bindings."

🔴 Hard (4)

1. What are the security risks of using the default ServiceAccount and how do you audit for them?

Show answer

The default SA starts with no permissions, but Helm charts or cluster operators may bind roles to it, meaning every pod in that namespace inherits those permissions silently. Audit with: kubectl get rolebindings,clusterrolebindings -A -o json | jq for subjects with name default. Fix by creating dedicated SAs per workload and ensuring default has no bindings beyond discovery.

Remember: Every namespace gets `default` SA. Best practice: dedicated SA per workload.

Gotcha: K8s 1.24+: SA tokens no longer auto-mounted as secrets. Use TokenRequest API.

2. Explain the escalate and bind verbs. Why are they dangerous?

Show answer

The escalate verb allows a subject to modify a Role or ClusterRole to include permissions they do not already hold — bypassing the normal RBAC escalation prevention. The bind verb allows creating RoleBindings that reference roles the subject could not otherwise grant. Together they enable privilege escalation. Never grant these verbs unless the subject genuinely manages RBAC for the cluster.

Remember: RBAC = 4 objects: Role, ClusterRole, RoleBinding, ClusterRoleBinding. "2 Roles + 2 Bindings."

3. A developer reports they cannot exec into pods despite having pod access. Walk through your debugging process.

Show answer

1) Check what they can do: kubectl auth can-i create pods/exec -n --as=. 2) pods/exec is a subresource separate from pods. The role must explicitly include pods/exec with the create verb. 3) Check their RoleBindings: kubectl get rolebindings -n -o json and inspect roleRef. 4) Inspect the referenced Role for pods/exec rules. 5) Fix by adding a rule for resources: ["pods/exec"] with verbs: ["create"]. 6) Verify with auth can-i.

Remember: RBAC = 4 objects: Role, ClusterRole, RoleBinding, ClusterRoleBinding. "2 Roles + 2 Bindings."

4. Why are wildcard rules (apiGroups: [""], resources: [""], verbs: ["*"]) in ClusterRoles dangerous, and what is the proper alternative?

Show answer

Wildcard rules grant unrestricted access to every current and future API resource in the cluster. If a pod with these permissions is compromised, the attacker has full cluster-admin access. Wildcards also cover secrets, RBAC objects, and node operations. The alternative is explicit enumeration of only the required apiGroups, resources, and verbs. Use separate roles for read vs write access and bind them at the narrowest scope (RoleBinding over ClusterRoleBinding).

Remember: Role=namespaced, ClusterRole=cluster-wide. Binding=namespaced, ClusterRoleBinding=global.