Role-Based Access Control (RBAC)

Role-Based Access Control sounds like a single mechanism. In a modern Azure workload it is at least three, layered, each evaluated independently, and each capable of failing the request on its own. The articles in this collection treat RBAC as the alignment problem it actually is: getting Kubernetes RBAC, Azure RBAC, and the identity-provider permissions to agree on what a pod, a deployment pipeline, or an operator is allowed to do.

Azure RBAC content focuses on scope and least privilege as engineering decisions rather than slogans. Subscription-level Contributor is not a starting point — it is an audit finding. Articles cover how to scope role assignments to the resource group, the resource, or the data-plane action that actually needs it, and how to use Azure ABAC conditions to constrain access by tag or principal type without writing a custom role.

Kubernetes RBAC sits beside cluster-level admission control and is where most teams over-permission. ClusterRoleBindings that should have been RoleBindings, service accounts with default left in place, audit logs that show nothing because audit policy was never configured. Articles walk through the patterns that produce the principle-of-least-privilege output the documentation promises but the defaults don’t deliver.

Workload Identity Federation is the connective tissue. The federated credential subject has to match the pod’s service account, the managed identity has to hold the Azure role assignment, and the Kubernetes RBAC has to allow the workload to use that service account in the first place. Three RBAC systems, one failed authentication, and a 401 that says nothing useful. Articles cover the validation patterns that catch each misalignment before deployment.

The recurring theme: RBAC misconfigurations are rarely a single missing permission. They are a layer that quietly disagrees with another.