kind: Role
metadata: { name: deployer, namespace: dev }
rules:
- { apiGroups: [apps], resources: [deployments], verbs: [get, list, create, update, delete] }
- { apiGroups: [""],   resources: [pods],        verbs: [get, list] }
---
kind: RoleBinding
metadata: { name: ci-bot-deployer, namespace: dev }
subjects: [{ kind: ServiceAccount, name: ci-bot, namespace: dev }]
roleRef:  { kind: Role, name: deployer }
Badge on a Role card: a RoleBinding giving that subject the roleRed lamp on the gate: 403 Forbidden, from RBAC or from admissionResource lamp: the request reached itEvery request to the API server says who is asking: a user like alice, or a pod using its ServiceAccount's token. RBAC then decides what they may do. A Role lists verbs on resources in one namespace; a ClusterRole does the same cluster-wide; a RoleBinding or ClusterRoleBinding grants a role to users, groups or ServiceAccounts. There are no deny rules: anything not granted is refused with 403. After RBAC, admission can still reject a request; Pod Security 'restricted' on a namespace, for example, blocks privileged pods and containers running as root even for someone allowed to create them.
Next: Debugging & Helm →