Role-Based Access Control (RBAC)

Role-Based Access Control (RBAC) determines who can perform what actions on which resources. In cloud and container environments, RBAC spans multiple authorization layers that must align correctly.

Kubernetes RBAC controls access to cluster resources through Roles and ClusterRoles bound to service accounts or users. Azure RBAC governs access to Azure resources with built-in roles scoped from subscriptions down to individual blobs. Identity Provider permissions (Azure AD, Entra ID) add directory-level authorization for Graph API calls and cross-tenant access.

Production failures often stem from misalignment across these layers. A service account may have correct Kubernetes permissions but lack Azure role assignments. An Azure identity may have storage access but no federated credential linking it to pods. Each layer validates independently.

Articles in this collection cover permission models, layering challenges, and validation patterns that catch misconfigurations before they cause incidents.

Pod Identity & Access Control in AKS: What Actually Breaks

Pod Identity & Access Control in AKS: What Actually Breaks

Traditional AKS authentication relied on service principals and mounted secrets. Workload Identity Federation eliminates credential lifecycle problems, but introduces new failure modes. This article covers the operational realities: where credentials still leak, how RBAC layers compound across Kubernetes and Azure, and validation patterns that prevent identity failures in production.