Azure Lighthouse for ISVs
As an ISV you can be the service provider for your customers or manage multiple Entra tenants from your main Entra tenant. You might have multiple tenants because of:
- Mergers and Acquisitions
- Regulatory compliance needs
- Multiple subsidiaries etc.
Introduction
I’ll use the scenario here for an ISV who wants to access their customers tenant.
Azure Lighthouse is the service which allows delegation of subscription and resource groups. So if you are not using Lighthouse you’ll add yourself as a guest user to your customer tenant or use B2B external identity feature, then switch to the customer tenant as needed.
This can become a time consuming process if you have multiple customers to work with. This also limits the customer tenant visibility to one at a time.
Get Simran Jeet Kaur’s stories in your inbox
Join Medium for free to get updates from this writer.
Azure Lighthouse helps simplify cross-tenant administration. So basically, it lets you do management tasks on multiple tenants subscription/resource group directly from primary tenant. It is free of cost as long as you have an existing Azure subscription.
How it works?
Azure Lighthouse leverages Azure RBAC to allow a set of permissions for your credentials against the target resources (for e.g. customer subscriptions). You can have different permissions to different resources in the same customer tenant.
The key here is delegated resource management. Through the delegated resource management, your customer’s subscriptions are mapped to your primary subscriptions. That means the services in your primary tenant have delegated access to specific resources in your customers subscription.
Role based Access Control practices
Since we talked about the RBAC to be the key for Lighthouse, here are some best practices before setting it up.
- Use Entra groups instead of individual role for easier management.
- The custom and owner roles will not work with Lighthouse. The highest role can be contributor
- Use principle of least privilege while assigning permissions to the groups.
- Any Data Actions roles are not supported.
- Ensure that the Entra users require MFA.
- See more security details here: Recommended security practices — Azure Lighthouse | Microsoft Learn
- See more best practices for defining users and roles here: Tenants, users, and roles in Azure Lighthouse scenarios — Azure Lighthouse | Microsoft Learn
Implementing the delegation using ARM templates
First understand the authorization — It is the object ID of a user, group or service principle who needs the access to customer tenant + role definition. The scope of authorization can be subscription, resource group or multiple resource groups.
If you want the delegation to management group, refer to this article — Onboard all subscriptions in a management group — Azure Lighthouse | Microsoft Learn
To create the deployment template, here are some of the details required:
- Gather tenant (tenant ID) and subscription (subscription id) details of the customer.
- Define roles and permissions (part of authorization as we discussed). Microsoft recommendations is also assign the Managed Services Registration Assignment Delete Role when onboarding a customer, so users in your tenant can remove access to delegation later if needed. If this role isn’t assigned, the delegation can only be removed in customer tenant.
- Then create the template. You can either create the template manually or use these lighthouse samples: Azure/Azure-Lighthouse-samples: Provide samples for understanding managed service solutions (github.com)
- The template must be deployed by a non-guest user with an elevated role in customer tenant. The deployment can be done either by PowerShell, cli or portal. See this for more details — Onboard a customer to Azure Lighthouse — Azure Lighthouse | Microsoft Learn
- Once deployed, it takes approximately 15 mins for the delegation to work.
Lighthouse Use cases
Azure Lighthouse in the SaaS Scenarios — It can be used by ISVs using SaaS based offerings with their customers where the ISV is a managed service provider or support provider and require access to the customer’s subscription.
If you are ISV that has SaaS as multitenant offering, and you hosts the solution in your own tenant, you can let your customer access the specific resources using Lighthouse. Learn more here — Azure Lighthouse in ISV scenarios — Azure Lighthouse | Microsoft Learn
Lighthouse and Managed Applications — Azure Managed Applications enable you to offer cloud solutions that are easy for customers to deploy and operate. As a publisher, you implement the infrastructure and can provide ongoing support. To make a managed application available to all customers, publish it in Azure Marketplace. Here is an important comparison of to use Lighthouse vs Managed Applications — Azure Lighthouse and Azure managed applications — Azure Lighthouse | Microsoft Learn
Lighthouse in Sentinel — As an ISV if you have a requirement of managing multiple sentinel, this article can help you implement Lighthouse and manage the sentinels easily — Managing Microsoft Sentinel across multiple tenants using Lighthouse — Microsoft Community Hub
Other Resources
- Lighthouse enhanced service and scenarios — Assuming appropriate roles are granted, most azure tasks and services can be used with delegated resources across tenants. Here is a link to summarize that: Cross-tenant management experiences — Azure Lighthouse | Microsoft Learn
- Removing the delegation — it can be done either at customer tenant or service provider tenant. Use this link to remove the delegation — Remove access to a delegation — Azure Lighthouse | Microsoft Learn
- Adding eligible authorizations using PIM — Privileged Identity Management with Azure Lighthouse enables Zero Trust | Microsoft Azure Blog
