Azure Landing Zone: What are all the BuiltInRoles to be assigned? Especially for Management Groups, Subscriptions, Vnets, Gateways, VMs, SA, SQL

Mugil Karthikeyan 0
Viewed 38

Currently, I am working on establishing enterprise-scale landing zones for Cloud Adoption Framework in Azure.

Azure has a list of BuiltInRoles defined as mentioned in this article - https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles.

It is unclear to me which role should be assigned to which resource

Especially for the below Resources

  • Management Groups
  • Subscriptions
  • Vnets
  • Gateways,
  • VMs
  • Storage Accounts,
  • SQL databases

Can you suggest what are all the Roles should be assigned while provisioning any of the above listed Resources?

azure
1 Answers

The Cloud Adoption framework is not about putting some roles on some arbitrary resources. You have to look at the framework in terms of hierarchical levels. Each hierarchical level has its own purpose and therefore uses its own set of permissions to deploy the resources needed for that particular step. I referenced some role mapping templates from aztfmod (Terraform + CAF) so that you get an idea about the role/permission structure.

  • Level 0: Core platform automation
    • Billing subscription role delegation (source)
    • Credential role mappings (source)
    • Launchpad role mappings (source)
  • Level 1: Core platform governance
  • Level 2: Core platform connectivity
  • Level 3: Application landing zones vending machine
  • Level 4: Applications landing zone

If you understand the levels correctly, you are able to infer what permissions are needed at what stage of the deployment of the CAF framework. For example:

  • level 0 is initiated by a user that is tenant administrator and Enterprise Agreement (EA) user, besides it needs to be the owner of the initial "launchpad" subscription.
  • From there this user will create service principals for each of the other stages of the deployment, and delegate permissions according to the principle of least privilege.
  • Key vaults and key vault policies are used to exchange sensitive information like credentials in between steps.
  • Each platform step (automation, governance, connectivity) is then run by its own service principal with its own specific set of permissions set on a specific scope (management group, subscription, resource group).
  • When all the platform components are in place you’ll be able to provision custom landing zones. Where you’ll again create service principals that are scoped to a single subscription. These service principals are able to deploy resources only within that landing zone.
  • Etc.

I would not recommend setting CAF or the permissions by hand, because it will become a pain in the ass to maintain. You could for example use aztfmod a Terraform implementation of CAF. If you follow the steps as described here, you'll create terraform configuration to deploy a CAF setup.

enter image description here

Cloudkollektiv0
Related