Who Can Access What? Designing RBAC and Identity in Azure
Who should be allowed to access an Azure resource? Azure makes it easy to create resources. The harder question comes afterwards: who should be allowed to access them? A Function App may need to read secrets from Key Vault. A Logic App may need to call APIs through API Management. A developer may need to deploy to Dev but have no access to Production. A CI/CD pipeline may need to deploy infrastructure without becoming an Owner of the entire subscription. This is where Azure Role-Based Access Control (RBAC) and Managed Identity become critical. In this article, I look at how to design access around people, applications and deployment pipelines, while keeping permissions as narrow as practical. The article covers: Azure RBAC and access scopes Least-privilege access Managed Identities Developer vs Production access boundaries Application identities CI/CD deployment permissions RBAC vs API authentication Privileged access and PIM Common RBAC design mistakes One of the key principles is simple: Give an identity only the permissions it actually needs. For example, if a Function App only needs to read secrets from Key Vault, giving it Contributor access to the entire Resource Group solves the problem with a much broader permission than necessary. Good RBAC design is not about assigning more permissions. It is about understanding: Who needs access? Why do they need it? What exactly do they need to do? At what scope should access be granted? How can that access be managed securely over time? I would be interested to hear how others approach RBAC and identity design in enterprise Azure environments. Full article: https://www.linkedin.com/pulse/who-can-access-what-designing-rbac-identity-azure-chethan-raj-ud6gc/How Should You Structure Dev, UAT, Staging and Prod in Azure?
This is one of those decisions that can look simple at the beginning of a project and become increasingly important as the environment grows. Should each environment have its own Resource Group? Should Production have a separate Subscription? Where should shared services live? How should naming, tagging and CI/CD fit into the design? There isn't one universal answer. The right structure depends on factors such as security boundaries, ownership, lifecycle, deployment processes and operational requirements. In this article, I look at: Dev, UAT, Staging and Production environment boundaries Resource Groups vs Azure Subscriptions Production isolation Naming conventions Azure tagging CI/CD considerations Blue/Green deployment considerations Common environment architecture mistakes The main idea is that environment architecture should be designed around clear operational and security boundaries rather than simply creating more Resource Groups. I would be interested to hear how others structure Dev, UAT, Staging and Production in enterprise Azure environments. Full article: https://www.linkedin.com/pulse/how-should-you-structure-dev-uat-staging-prod-azure-chethan-raj-ktfac/
