--- tags: - k8s - l1 - flashcard-deck - k8s-rbac --- [Portal](../../../../library/portal/index.md) | **Level:** [L1: Foundations](../../../../library/portal/levels.md) | **Topics:** [RBAC](../../../../library/portal/topics.md) | **Domain:** Kubernetes id category difficulty tags question answer source_path k8s-rbac/a1c2e3f4b5d6 k8s-rbac easy k8s, rbac, role, clusterrole What is the difference between a Role and a ClusterRole in Kubernetes RBAC? 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.\n\nRemember: Role=namespaced, ClusterRole=cluster-wide. Binding=namespaced, ClusterRoleBinding=global. training/library/topics/k8s-rbac/primer.md k8s-rbac/b2d3f4a5c6e7 k8s-rbac easy k8s, rbac, verbs What are the standard RBAC verbs in Kubernetes and what API operations do they map to? 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.\n\nRemember: RBAC = 4 objects: Role, ClusterRole, RoleBinding, ClusterRoleBinding. "2 Roles + 2 Bindings." training/library/topics/k8s-rbac/primer.md k8s-rbac/c3e4a5b6d7f8 k8s-rbac easy k8s, rbac, serviceaccount What is a ServiceAccount and why should you set automountServiceAccountToken to false? 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.\n\nRemember: Every namespace gets `default` SA. Best practice: dedicated SA per workload.\n\nGotcha: K8s 1.24+: SA tokens no longer auto-mounted as secrets. Use TokenRequest API. training/library/topics/k8s-rbac/primer.md k8s-rbac/d4f5b6c7e8a9 k8s-rbac easy k8s, rbac, binding What is the difference between a RoleBinding and a ClusterRoleBinding? 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.\n\nRemember: Role=namespaced, ClusterRole=cluster-wide. Binding=namespaced, ClusterRoleBinding=global. training/library/topics/k8s-rbac/primer.md k8s-rbac/e5a6c7d8f9b0 k8s-rbac medium k8s, rbac, debugging How do you use kubectl auth can-i to debug RBAC permissions? 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.\n\nRemember: RBAC = 4 objects: Role, ClusterRole, RoleBinding, ClusterRoleBinding. "2 Roles + 2 Bindings." training/library/topics/k8s-rbac/primer.md k8s-rbac/f6b7d8e9a0c1 k8s-rbac medium k8s, rbac, least-privilege Describe a least-privilege RBAC pattern for a CI/CD deployer service account. 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.\n\nRemember: Every namespace gets `default` SA. Best practice: dedicated SA per workload.\n\nGotcha: K8s 1.24+: SA tokens no longer auto-mounted as secrets. Use TokenRequest API. training/library/topics/k8s-rbac/primer.md k8s-rbac/07c8e9f0a1b2 k8s-rbac medium k8s, rbac, aggregation How do aggregated ClusterRoles work and when should you use them? 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.\n\nRemember: Role=namespaced, ClusterRole=cluster-wide. Binding=namespaced, ClusterRoleBinding=global. training/library/topics/k8s-rbac/primer.md k8s-rbac/18d9f0a1b2c3 k8s-rbac medium k8s, rbac, subresources Why does granting get on pods NOT allow reading pod logs? 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.\n\nRemember: RBAC = 4 objects: Role, ClusterRole, RoleBinding, ClusterRoleBinding. "2 Roles + 2 Bindings." training/library/topics/k8s-rbac/primer.md k8s-rbac/29e0a1b2c3d4 k8s-rbac hard k8s, rbac, security, mistakes What are the security risks of using the default ServiceAccount and how do you audit for them? 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.\n\nRemember: Every namespace gets `default` SA. Best practice: dedicated SA per workload.\n\nGotcha: K8s 1.24+: SA tokens no longer auto-mounted as secrets. Use TokenRequest API. training/library/topics/k8s-rbac/primer.md k8s-rbac/3af1b2c3d4e5 k8s-rbac hard k8s, rbac, escalation Explain the escalate and bind verbs. Why are they dangerous? 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.\n\nRemember: RBAC = 4 objects: Role, ClusterRole, RoleBinding, ClusterRoleBinding. "2 Roles + 2 Bindings." training/library/topics/k8s-rbac/primer.md k8s-rbac/4b02c3d4e5f6 k8s-rbac hard k8s, rbac, audit A developer reports they cannot exec into pods despite having pod access. Walk through your debugging process. 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.\n\nRemember: RBAC = 4 objects: Role, ClusterRole, RoleBinding, ClusterRoleBinding. "2 Roles + 2 Bindings." training/library/topics/k8s-rbac/primer.md k8s-rbac/5c13d4e5f6a7 k8s-rbac hard k8s, rbac, wildcard, security Why are wildcard rules (apiGroups: ["*"], resources: ["*"], verbs: ["*"]) in ClusterRoles dangerous, and what is the proper alternative? 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).\n\nRemember: Role=namespaced, ClusterRole=cluster-wide. Binding=namespaced, ClusterRoleBinding=global. training/library/topics/k8s-rbac/primer.md --- ## Wiki Navigation ### Related Content - [Interview: RBAC Forbidden](../../../../library/interview-scenarios/09-rbac-forbidden.md) (Scenario, L2) — RBAC - [K8s RBAC](../../../../library/topics/k8s-rbac/index.md) (Topic Pack, L1) — RBAC - Kubernetes Exercises (Quest Ladder) *(CLI)* (Exercise Set, L1) — RBAC - Kubernetes Security Flashcards *(CLI)* (flashcard_deck, L1) — RBAC - [Multi-Tenancy Patterns](../../../../library/topics/multi-tenancy/index.md) (Topic Pack, L2) — RBAC - [Policy Engines (OPA / Kyverno)](../../../../library/topics/policy-engines/index.md) (Topic Pack, L2) — RBAC - [Runbook: RBAC Forbidden](../../../../library/runbooks/kubernetes/rbac_forbidden.md) (Runbook, L2) — RBAC - [Track: Kubernetes Core](../../../../library/curriculum/tracks/kubernetes_core.md) (Reference, L1) — RBAC