RBAC Roles and Bindings

Cluster Architecture and Configuration / Guide 15 of 103 / Intermediate

• Kubernetes1.36.4
• Cluster4 nodes
• Runtimecontainerd 2.2.6
• CNICalico v3.32.1
• TimeAbout 40 min

Rule contents are choices. The deny-by-default model and the additive-only evaluation are not.

This guide includes

Use this when someone or something needs access and you have to grant exactly enough. This matters because RBAC is four object kinds over one verb-and-resource model, and a single command answers permission questions that people otherwise guess at.

• keeping the four kinds straight - Role and ClusterRole, RoleBinding and ClusterRoleBinding
• asking the authoriser directly with auth can-i --as=, and reading rules back with describe role and auth can-i --list
• generating the same Role and RoleBinding imperatively, with no YAML at all
• proving it from inside a Pod and getting a real 403 rather than an impersonated answer
• using a ClusterRole for cluster-scoped resources like nodes, which no RoleBinding can reach

Before you start

• A working cluster and kubectl with admin rights, since creating Roles requires them.
• The kubectl session guide, particularly api-resources: RBAC rules are written in terms of API groups and resource names, and that is where you look them up.
• The control plane guide, for why --authorization-mode=Node,RBAC is what makes any of this apply.

1. 1

   The four kinds, and the one thing to get right

2. 2

   auth can-i, the command that ends the guessing

3. 3

   Read the rules back, two ways

4. 4

   Generate the same objects imperatively

5. 5

   Prove it from inside a Pod, with a real 403

6. 6

   ClusterRoles, cluster-scoped resources, and cluster-admin

7. 7

   Clean up, and one deletion trap

Official sources

• Using RBAC authorization
• Authorization overview
• Configure ServiceAccounts for Pods
• Accessing the API from a Pod
• kubectl auth can-i
• Default roles and role bindings