We’ve talked about AWS cross-account management options in our Assume Role and SSO articles. How do we effectively manage subscriptions and services across multiple tenants in Azure? Azure Lighthouse submits a good answer to this question. We’ll talk more about the Azure Lighthouse service in this article.
There are a number of traditional ways for Managed Service Providers (MSP) to manage their customers’ tenants and resources. The common ones are accessing target tenants as member users or guest users.
- Member User Access
This way customers need to create user accounts for the MSP agents in their tenant. The MSP agents can then use the provided user credentials to log in to the customer tenant to manage their resources. As a result, MSP agents must maintain multiple identities and credentials, which increases security risk and maintenance overhead.
- Guest User Access
AAnother way is that MSP can ask their customer to invite MSP agents as guest users to customer’s Azure Active Directory (AAD). MSP agents can then use their own user credentials to log in to customer’s tenant. It seems to be a relief for MSP agents, as they don’t have to maintain multiple identities and credentials. But the maintenance overhead from customer’s side is high, e.g. customers have to manage these guest users’ lifecycle. Furthermore, the MSP agents still need to switch between tenants to manage different customers’ resources.
So for multi-tenant management, both solutions have their limitations and operation overheads. Luckily Microsoft has created the Azure Lighthouse service that can address all the pain points mentioned above, as well as providing better scalability, automation and governance.
As usual, let’s use a diagram to take a look at how Lighthouse works. Given we will be talking about multiple tenants along this article, let’s firstly give these tenants some shortened names (as Aussies always do). For the managed tenants, let’s call them Workload Tenants (WT); for the managing tenant, let’s call it Management Tenant (MT). The MT and WTs are in the one-to-many relationship as shown below.
As shown in the diagram, MSP agents can use their MT identity to access WT resources through the Lighthouse. The access level starts from subscription downwards, i.e. subscriptions, resource groups and resources. MSP agents can’t access or configure settings at WT’s management group or directory level.
From the Authentication, Authorisation and Audit point of view, no additional identities need to be created in WTs’ Azure Active Directories (AAD). MSP agents authenticate themselves using their own MT identity credentials within their own tenant. The customer side, i.e. the WT side, holds the stake for what access and permission they want to grant to MSP agents. The activities that MSP agents conducted on WT resources are captured in WT’s activity log. These AAA setups provide authority and transparency to customers, as well as provide enablement and efficiency to MSP agents.
In addition to the advantages mentioned above, Azure Lighthouse also provides the following benefits:
- Centralized tenant management
e.g. MSP agents can view all managed tenants from the My Customers page on the Azure portal
- Scaled resource management
e.g. Lighthouse supports resources at different levels (like subscription, resource group and individual resources), resources in different regions, as well as resources in the hybrid scale (like Azure Arc-enabled servers and K8s).
- Comprehensive tooling support
e.g. Lighthouse supports MT’s existing ARM templates, APIs, management tools and workflows. We’ll talk a bit more about how Lighthouse works together with security tools in the Security section.
- Easy implementation
e.g. Lighthouse can be set up using either ARM template or managed service offers in the Azure Marketplace. We’ll talk about both methods in the Hand On section shortly.
Last but not least, Azure Lighthouse is a free service. Any MSPs or enterprises who manage multiple tenants can use Lighthouse with no additional costs. For more information about Azure Lighthouse, see Azure Lighthouse Documentation.
Having talked about what is Azure Lighthouse and its benefits, let’s get to the hands on part and see how we can set it up. In general, there are two ways to set up Azure Lighthouse:
- via Azure Resource Manager (ARM) templates
- via Azure Marketplace
ARM Template Method
Let’s take a look at the ARM template method first. In a nutshell, this method is about creating ARM template file(s) first, and then deploying them in the WT tenant. We can create the template from the Azure portal or manually edit the template JSON file(s):
Regardless which option is used, the outcome will be the same, i.e. having one or more JSON files generated. We can then move to the WT side to deploy the template files.
Note that we’ve mentioned that there can be more than one JSON files generated. The reason being is that we can choose to include all Lighthouse related information in one JSON file, or split the parameters to a separate file. By hosting parameters in a separate file, we’ll end up with two JSON files, e.g. subscription.json and subscription.parameters.json.
Once we have the ARM template files ready, the next step is deploying them at the WT side. It’s usually the subscription owner who conducts the deployment. Alternatively, it can be done by a non-guest user who has the roleAssignment/write permission. There are three ways to deploy the template:
Microsoft has well-defined user instructions, as the links provided above, so we won’t replicate the steps in this section.
The second way to set up Azure Lighthouse is via Azure Marketplace. If the first method is suitable for both MSPs and enterprises who manage multiple tenants, then the Marketplace method is only applicable to MSPs.
The prerequisite of publishing the Azure Lighthouse as a Managed Service Offer in the Azure Marketplace is that the MSP must have Silver or Gold Cloud Platform competency level or be an Azure Expert MSP. The details of create and publish a Lighthouse offer is available at Publish a Managed Service Offer to Azure Marketplace.
Once the Lighthouse deployment is completed, via either ARM template or Marketplace, both MT and WT sides will be able to see the relevant onboarding information. The MT agents can see the information from the My Customers page. The WT owner can see the information from the Service Providers page.
Having talked about the benefits of using Azure Lighthouse to conduct cross tenant management, let’s take a look at the security side. Imagine a WT owner asks the MSP a question like:
“How do I trust that your MT environment is secure so that I can give you access to my resources via Lighthouse?”
This is a very valid question and concern from the WT aspect. It makes the security posture of the MT environment a critical prerequisite for Lighthouse implementation.
To answer this question, Microsoft has provided a security baseline for Lighthouse. This baseline is sourced from the Azure Security Benchmark (ASB). ASB provides guidance on security best practices and recommendations covering the following control domains:
- Network Security (NS)
- Identity Management (IM)
- Privileged Access (PA)
- Data Protection (DP)
- Asset Management (AM)
- Logging and Threat Detection (LT)
- Incident Response (IR)
- Posture and Vulnerability Management (PV)
- Endpoint Security (ES)
- Backup and Recovery (BR)
- Governance and Strategy (GS)
Not all ASB security controls are applicable to Azure Lighthouse. The applicable ones are grouped and listed in Azure Security Baseline for Azure Lighthouse.
In addition to providing security control guidelines mentioned above, Microsoft has taken one step further to centralise ASB related controls and data in a workbook, called Azure Security Benchmark Workbook. This workbook covers all the control domains listed above and facilitates with built-in filters and customisable reports. For more information about this workbook, see What’s New: Azure Security Benchmark Workbook.
Azure Lighthouse provides an effective cross-tenant management solution to Cloud Managed Service Providers, as well as organisations that own multiple Azure tenants. It supports management-at-scale that enables Workload Tenant owners to delegate access and permissions to Managed Service Providers at multiple levels. And both Managed Service Providers and Workload Tenant owners can see who took actions on the resources via the activity logs.
Additional kudos should be given to Microsoft as they’ve taken extra steps to provide ASB for the Lighthouse as well as ASB Workbook that make MSPs’ life way more easier on strengthening their security posture, which ticks the most critical prerequisite checkbox for Lighthouse implementation.