Suppose several teams share a Kubernetes cluster. Developers need to deploy to their own namespace, but should not be able to change the security requirements that govern it. Role-based access control (RBAC) grants access through roles assigned to users. It lets developers manage permitted resources while cluster operators retain control of the guardrails. section 12.0 section 12.6
Four Kubernetes objects put this into practice:
- A Role defines permissions in a namespace. Each rule names API groups, resources, and allowed verbs. Permissions are additive: a rule grants access rather than subtracting it. section 12.6
- A RoleBinding assigns a Role to subjects, such as developer identities, in that namespace. section 12.6
- ClusterRole and ClusterRoleBinding are the cluster-level counterparts when access must extend beyond one namespace. section 12.6
Listing 12.13 Chapter12/12.6_RBAC/role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: developer-access
namespace: team1
rules:
- apiGroups:
- "" #1
resources:
- namespaces #2
verbs: ["get"] #2
- apiGroups: #3
- "" #3
resources: #3
- events #3
- pods #3
- pods/log #3
- pods/portforward #3
- services #3
- secrets #3
- configmaps #3
- persistentvolumeclaims #3
verbs: ["*"] #3
- apiGroups:
- apps #4
- autoscaling #5
- batch #6
- networking.k8s.io #7
- policy #8
resources: ["*"]
verbs: ["*"]
This namespace Role grants broad access to deployment-related resources but permits only `get` on namespaces, so it does not grant permission to change the namespace’s Pod Security annotation. section 12.6
Listing 12.14 Chapter12/12.6_RBAC/rolebinding.yaml
kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: developerA namespace: team1 roleRef: kind: Role name: developer-access #1 apiGroup: rbac.authorization.k8s.io subjects: # Google Cloud user account - kind: User name: example@gmail.com #2
The RoleBinding connects that Role to a named user in the team namespace. Defining permissions and assigning them are separate steps. section 12.6
Check the boundary
After creating the namespace, Role, and RoleBinding, the developer’s deployment is forbidden in the default namespace but succeeds in the team namespace. An attempt to change the team namespace’s Pod Security label is also forbidden. A cluster-scoped resource, such as a PriorityClass, needs separate cluster-level permission. section 12.6
RBAC governs which cluster resources a user can manage. Pod Security admission addresses what permissions Pods may have on nodes. Together they provide useful guardrails, but further network and container isolation may still be needed. section 12.7
