More and more organizations are finding their way to the cloud. Managing different customer tenants is becoming more challenging for service providers, while customers need insight and control over the access of their multiple service providers.

What Azure Lighthouse delivers is enabling multi-tenant management with scalability, automation, and enhanced governance across resources.

We’ll look at the Azure Lighthouse service and its features. Then we’ll compare the service to other options to manage multiple tenants, followed by a step-by-step guide to onboard an environment to Azure Lighthouse.

Azure Lighthouse

Azure Lighthouse lets customers delegate resource management permissions to service providers over scopes, including subscriptions, resource groups, and individual resources, which enable service providers to perform management operations on their behalf. It uses the Azure Resource Manager capabilities and the standard role-based access control (RBAC) mechanisms. It works regardless of the licensing construct, whether enterprise agreements (EA), cloud solution providers (CSP), or pay-as-you-go subscriptions.

Azure Lighthouse offers service providers a single control plane to view and manage Azure across all their customers. Partners can manage resources from multiple distinct customers through their Azure portal or CLI context. Azure Lighthouse makes customer resources visible to service providers as Azure resources in their tenant, making it easy for service providers to automate status monitoring and manage the resources of many customers from a single location. This applies to everything relevant to Azure resource management, from the Azure portal to services such as Azure Policy, Resource Graph, Log Analytics features of Azure Monitor, or Update Management.

Enable zero trust with Privileged Identity Management

Microsoft offers the possibility to easily enable Azure AD Privileged Identity Management (PIM) capabilities for Azure Lighthouse. Only the eligible roles assigned to that specific user can be activated with PIM-enabled Azure Lighthouse. This follows the zero trust cybersecurity protocol and allows using just-in-time access (JIT) and other PIM capabilities, significantly reducing the risk of operator errors. You can find more information about Privileged Identity Management in the documentation.

Comparison with other options

Let’s look at other options to access multiple Azure tenants; Admin on behalf of (AOBO) and Azure Active Directory B2B. How does Azure Lighthouse compare to these other options?

Admin On Behalf Of (AOBO) grants CSP partners delegated administrator privileges via the partner portal. When onboarding a customer’s CSP, the customer explicitly gives these permissions via the invitation link. This allows owner role-based access control (RBAC) access on all Azure subscriptions for that customer. Not long ago, partners were also given the Global Administration role in Azure Active Directory. Still, with the advent of granular delegated administration privileges (GDAP), they are now assigned lower permissions to read the directory by default. This follows the least-privileged access principles and the zero trust cybersecurity protocol.

AOBO helps overcome the challenge of accessing multiple customer tenants without creating separate accounts for each tenant. However, it is not a real scalable management solution. With AOBO, you still perform actions from one account within one tenant. If you want to perform actions in multiple tenants via AOBO, you are forced to log in per tenant one by one and perform your activities there. This option is only available to CSP partners for customers who participate in the CSP program. In addition, it provides different scalability in insight than Azure Lighthouse because it cannot look across the context of multiple customers or tenants. In other words, it does not provide the “single pane of glass”.

Azure Active Directory (AD) B2B is one of the external identity options Azure AD offers. It is a “bring your own identity” solution so external users can use their Azure AD identity in another tenant. B2B collaboration users are represented in your directory as guest users. This makes it possible to hand out access rights and admin privileges to guest users like tenant-own users.

If you want to perform actions in multiple tenants via Azure AD B2B, you are forced to log in per tenant one by one and perform your activities there. This works just as if you had a customer or domain-specific account. Azure AD B2B forces you to send a guest invitation per identity or user, accept it, and then grant the desired permissions within the customer tenant. This makes the option less scalable and efficient for our purpose. In addition, Azure AD B2B provides different scalability in insight than Azure Lighthouse does because it cannot look across the context of multiple customers or tenants.

Onboarding a customer

Let’s onboard an Azure subscription to Azure Lighthouse and give specific role-based access so that you can familiarize yourself with Azure Lighthouse. Unfortunately, there is no support for Privileged Identity Management (PIM) with Terraform, which will not be covered in these steps. However, it should be a matter of time before it will be supported, as feature requests are already being raised. In the meantime, you can use the AzAPI provider to enable PIM using the ARM samples below. Before you can start onboarding, there are some prerequisites to fulfill:

• Azure tenant and user account: You’ll need two Azure tenants, two Azure Active Directory (Azure AD) instances. One tenant represents the service provider, while the second tenant represents the customer.
• Subscriptions: You’ll need a subscription and owner permissions in the “customer tenant” to onboard and deploy resources.
• Terraform: You’ll need the Terraform command-line interface to deploy and manage Azure resources. You can find more information about Terraform and the AzureRM provider in the documentation.

In this guide, we use Terraform, but Microsoft also offers the capability to manage Azure Lighthouse through ARM templates. You can find more information and samples about this in this GitHub repository.

• Azure CLI: You’ll need the Azure command-line interface for executing the ARM template deployments, and you can find more information about the Azure CLI in the documentation.

Once you have fulfilled the prerequisites, we are ready to start onboarding!

Step 1: Download the Terraform files from our GitHub repository for the rest of this guide. Review the files and adjust where necessary. Line 2 of the main.tf file contains the ID of the built-in Contributor RBAC role. If you wish to assign a different role, you can find the necessary IDs in the Microsoft documentation. Delegating the Owner and User Access Administrator role with Azure Lighthouse is impossible.

Step 2: Start your preferred terminal and connect to Azure using the Azure CLI and your service provider identity (user account).

az login

Run the command below to retrieve the tenant ID from the service provider tenant. Copy the ID and put it in the ManagingTenant value of the variables.tf file.

az account list --query “[[].name, [].homeTenantId]” --output table

Next, we’ll create a security group within the service provider tenant. This security group represents the users that will receive the delegated permissions to the customer tenant. Run the command below to create an Azure Active Directory group. You can adjust the display name and mail nickname to your liking.

az ad group create \
  --display-name “Team Robino” \
  --mail-nickname “Robino”

Once completed, your terminal receives output from the deployment. Copy the “id” and put this in the AdminGroup value of the variables.tf file.

Now we have to add ourselves to this group. Run the command below to retrieve your user id so we can add it to the group.

az ad signed-in-user show

From the output in your terminal, copy the “id” value. We need it for our next step to add ourselves to the group we’ve created in the previous step. To do so, run the command below.

az ad group member add \
  --group “Team Robino” \
  --member-id “xxxxxxxx–xxxx-xxxx–xxxx-xxxxxxxxxxxx”

Step 3: Let’s connect to the customer Azure tenant using the Azure CLI and your customer identity (user account). In practice, you will likely have to let your customer carry out these steps.

Log out from the service provider tenant and log in with your customer identity by running the commands below.

az logout
az login 

As we want to delegate permissions on a subscription level, we need to retrieve the subscription ID of the subscription to that we want to delegate permissions. Run the command below to retrieve the subscription IDs of the customer tenant.

az account list --query “[[].name, [].id]” --output table

Copy the id in your terminal output from the subscription to which you’d like to delegate permissions. Put this in the SubscriptionId value of the variables.tf file.

We must register the Managed Services resource provider to enable the use and onboarding. An Azure resource provider is a collection of REST operations that provide functionality for an Azure service. Use the command below to switch to the subscription we want to onboard and register the Microsoft.ManagedServices resource provider. Use the ID from the previous step.

az account set --subscription “xxxxxxxx-xxxx–xxxx–xxxx–xxxxxxxxxxxx” 
az provider register --namespace ‘Microsoft.ManagedServices’

Step 4: Now it’s finally time to deploy our Terraform code, which will delegate resource management permissions to our service provider. Run the commands below from the folder where you’ve downloaded the .tf files as your working directory. These commands will initialize the working directory, create an execution plan, and execute the actions proposed in the plan. If you are new to Terraform or want to learn more about it, you can find more information about Terraform in the documentation.

terraform init
terraform plan
terraform apply --auto-approve

Once the deployment is completed, you can access the Azure Portal with your customer account to validate the deployment. You should see a delegation similar to the image below from the delegations blade in the Azure Lighthouse service.

Step 5: Now, we should have delegated resource management permissions. Let’s validate it by creating a resource group in our customers' tenant. First, log in with your service provider account using the commands below.

az logout
az login

To create a resource group in the customer’s subscription, we’ll need to switch to that subscription context. First, run the command below to list all subscriptions you have access to. The onboarded subscription from the previous steps should be visible in the list.

az account list — output table 

From the terminal output, copy the ID of the subscription. This ID should be the same as the ID you’ve put in the SubscriptionID value of the variables.tf file. Run the command below to switch context to this subscription, using the ID of the subscription you’ve just copied.

az account set — subscription xxxxxxxx-xxxx–xxxx–xxxx–xxxxxxxxxxxx 

To create a resource group, run the command below. Change the values to your liking if you’d like.

az group create -l westeurope -n rg-t-weu-robino

Once your deployment has succeeded, we’ll validate the creation of the resource group in the Azure Portal. Being logged in with the service provider account, click on the cogwheel in the top right corner. In the Directories + subscriptions blade, make sure you’ve selected the customer directory and subscriptions.

For service providers that have multiple customers onboarded in Azure Lighthouse, numerous customers can be selected for total overviews. This can be extremely useful for services such as Microsoft Defender for Cloud, Backup Center, or Azure Monitor. This may give you an overview of all alerts and statuses of your customers.

Looking in the Resource groups blade, you should now see your freshly created resource group. This proves that we have been delegated the resource management privileges to create a resource group in the customer’s subscription.

Step 6: Let’s clean up the resources and deployment before ending this step-by-step guide. Run the command below from your terminal to delete the resource group we’ve created in the previous steps. If you have changed the name of the resource group, adjust the command accordingly.

az group delete -n rg-t-weu-robino

We’ll log in with the customer’s account to offboard the customer’s subscription. Do so by executing the commands below.

az logout
az login

Instead of using Terraform to apply the desired state, we will use the terraform destroy command to destroy what Terraform previously deployed. Run the commands below to do so.

terraform plan
terraform destroy

Your terminal output will describe what will be destroyed. This should be the Lighthouse assignment, as it is the only resource that was managed and deployed by Terraform in this guide. Terraform will prompt you to confirm. Type in yes to confirm and destroy the Lighthouse assignment.

As soon as the deployment is completed, head on to the Azure Portal with your service provider account and validate.

Summary

We went through the Azure Lighthouse service, compared it to other options for managing multiple tenants, and onboarded a tenant to Azure Lighthouse. Azure Lighthouse holds many secrets and possibilities to leverage scalable and automation capabilities. Check out the Azure Lighthouse Documentation to learn more about Azure Lighthouse.

Thank you for taking the time to go through this post and making it to the end. Keep an eye on this blog for more content on similar topics.

This post was originally published on Robino.io.