Azure landing zone, which is a subset of Microsoft Cloud Adoption Framework for Azure, help customers set up their Azure environment for scale, security, governance, networking, and identity.
Once you create an Azure tenant, the next step is to create a subscription(s). You might be thinking, ‘how many subscription(s) do I need’? This really depends on many factors so lets take a look at it.
Azure subscriptions have different limits for different resource types and this link does a great job of explaining the different service limits, quotas, and constraints.
Items to look at when designing the subscription model:
•Network Connectivity (shared or dedicated)
•Active directory requirements, clustering, identity, management tools
•Who are the subscription administrators
•Least privilege model
•Allocation of limited resources
•Evolution over time (users, shared access, resource limits)
Here are some questions that should be asked before creating a subscription:
•Who will be responsible for creating subscriptions?
•What resources will be in a subscription by default?
•Are there any capacity / technical limitations?
•Do we want to ensure Separation of duties?
•Dev/Test Vs. Production?
•Different end customers?
•Different departments or business units?
•What is the right naming convention to be used? Here is a great article on naming convention.
Once the Azure subscription(s) are setup, the next step is to think about how to organize the Azure resources.
Azure Management group
Define the management group hierarchy on organization and environment type such as production, dev/test etc.
The root management group is for global configuration and be careful with the management level assessments as they will cascade through the hierarchy. Assign common polices and RBAC on the management group level.
The built-in RBAC roles for management group are MG contributor and MG reader.
Azure Role-Based Access Control (RBAC)
Using RBAC, you can segregate duties within your team and grant only the amount of access to users that they need to perform their jobs. Instead of giving everybody unrestricted permissions in your Azure subscription or resources, you can allow only certain actions at a particular scope.
- Security principal
A security principal is an object that represents a user, group, service principal, or managed identity that is requesting access to Azure resources.
– Service principal – A security identity used by applications or services to access specific Azure resources. You can think of it as a user identity (username and password or certificate) for an application. -Managed identity – An identity in Azure Active Directory that is automatically managed by Azure. You typically use managed identities when developing cloud applications to manage the credentials for authenticating to Azure services.
2. Role definition
A role definition is a collection of permissions. It’s sometimes just called a role. A role definition lists the operations that can be performed, such as read, write, and delete. Roles can be high-level, like owner, or specific, like virtual machine reader. You can create custom roles if none of the existing built-in roles don’t meet the specific needs of your organization.
Scope is the boundary that the access applies to. When you assign a role, you can further limit the actions allowed by defining a scope. This is helpful if you want to make someone a Website Contributor, but only for one resource group.
Here is the Azure tagging decision guide. Here is the link for best practices on using Resource Tags.
Azure policy can enforce real time policy and at-scale compliance assessment. Also, the policy evaluates all Azure resource and can generate events that can be used for alerting. Furthermore, Azure policy can be used to automatically remediate problem in the environment.
My recommendation is to start with audit policies, which is a safe way of understanding what a policy will do without affecting the user activity. Furthermore, deny policies should be rolled out in stages to understand the impact.
This wraps up the Azure Landing Zone Overview.
3 thoughts on “Azure Landing Zone Overview”
May I suggest some improvements-
1. Naming conventions
2. Networking – IP planning, vNet, subnet structure and ingress/egress planning
Thank you kindly! Since this was mainly an overview, I will have a separate blog post on Azure landing zone networking.
Good Overview of the Landing zones.