Azure Lighthouse architecture
Azure Lighthouse helps service providers simplify customer engagement and onboarding experiences, while managing delegated resources at scale with agility and precision. Authorized users, groups, and service principals can work directly in the context of a customer subscription without having an account in that customer's Azure Active Directory (Azure AD) tenant or being a co-owner of the customer's tenant. The mechanism used to support this access is called Azure delegated resource management.
Azure Lighthouse can also be used within an enterprise which has multiple Azure AD tenants of its own to simplify cross-tenant management.
This topic discusses the relationship between tenants in Azure Lighthouse, and the resources created in the customer's tenant that enable that relationship.
Delegation resources created in the customer tenant
When a customer’s subscription or resource group is onboarded to Azure Lighthouse, two resources are created: the registration definition and the registration assignment. You can use APIs and management tools to access these resources, or work with them in the Azure portal.
The registration definition contains the details of the Azure Lighthouse offer (the managing tenant ID and the authorizations that assign built-in roles to specific users, groups, and/or service principals in the managing tenant.
A registration definition is created at the subscription level for each delegated subscription, or in each subscription that contains a delegated resource group. When using APIs to create a registration definition, you’ll need to work at the subscription level. For instance, using Azure PowerShell, you’ll need to use New-AzureRmDeployment before you create a new registration definition (New-AzManagedServicesDefinition), rather than using New-AzureRmResourceGroupDeployment.
The registration assignment assigns the registration definition to a specific scope—that is, the onboarded subscription(s) and/or resource group(s).
A registration assignment is created in each delegated scope, so it will either be at the subscription group level or the resource group level, depending on what was onboarded.
Each registration assignment must reference a valid registration definition at the subscription level, tying the authorizations for that service provider to the delegated scope and thus granting access.
Azure Lighthouse creates a logical projection of resources from one tenant onto another tenant. This lets authorized service provider users sign in to their own tenant with authorization to work in delegated customer subscriptions and resource groups. Users in the service provider's tenant can then perform management operations on behalf of their customers, without having to sign in to each individual customer tenant.
Whenever a user, group, or service principal in the service provider tenant accesses resources in a customer's tenant, Azure Resource Manager receives a request. Resource Manager authenticates these requests, just as it does for requests made by users within the customer's own tenant. For Azure Lighthouse, it does this by confirming that two resources—the registration definition and the registration assignment—are present in the customer's tenant. If so, Resource Manager authorizes the access according to the information defined by those resources.
Activity from users in the service provider's tenant is tracked in the activity log, which is stored in the customer's tenant. This allows the customer to see what changes were made and by whom.
How Azure Lighthouse works
At a high level, here's how Azure Lighthouse works:
- Identify the roles that your groups, service principals, or users will need to manage the customer's Azure resources.
- Specify this access and onboard the customer to Azure Lighthouse either by publishing a Managed Service offer to Azure Marketplace, or by deploying an Azure Resource Manager template. This onboarding process creates the two resources described above (registration definition and registration assignment) in the customer's tenant.
- Once the customer has been onboarded, authorized users sign in to your managing tenant and perform tasks at the specified customer scope (subscription or resource group) per the access that you defined. Customers can review all actions taken, and they can remove access at any time.
While in most cases only one service provider will be managing specific resources for a customer, it’s possible for the customer to create multiple delegations for the same subscription or resource group, allowing multiple service providers to have access. This scenario also enables ISV scenarios that project resources from the service provider’s tenant to multiple customers.