Azure Lighthouse - managing customer Azure tenants as a Service Provider

Azure Lighthouse - managing customer Azure tenants as a Service Provider

Yesterday, Microsoft announced Azure Lighthouse. This post will walk you through what the service is, what benefits it brings, and why you should start using it.

What is Azure Lighthouse?

Azure Lighthouse is a new service from Microsoft, released on July 11th, 2019. It brings better management capabilities and flexibility for managing multiple Azure tenants through delegated access. It’s intended primarily for Managed Service Partners (MSPs), or companies that provide support, service desk, and similar services for businesses. Others can – of course – use and benefit from it, but it’s essential to understand that the usage scenarios relate heavily to MSPs and multiple Azure tenants they need to access. Companies with multiple separate Azure subscriptions can also benefit from Azure Lighthouse.

The benefits Microsoft cites for Azure Lighthouse include managing customer tenants at scale, bringing in better precision and visibility, and having the ability to create unified platform tooling.

With Azure Lighthouse, MSPs can use Azure Resource Management infrastructure together with Azure Identities to delegate access. Access is delegated for MSP accounts to customer Azure tenants. This way, a company – Contoso, in this example – selling support services and professional services on Azure, can more easily manage and architect their access and operations to customer tenants.

Contoso can offer its services to customers through Azure Marketplace using ARM templates. These offers can be either public or private. Contoso can also package and provide applications directly to their customers as managed applications through Azure Marketplace. Besides these, Contoso can securely manage customer resources in one or multiple tenants, as well as perform administrative tasks, such as using PowerShell scripts against multiple tenants.

If our fictional company, Contoso, had three customers – Northwind Traders, Coho Winery, and LitWare – they could use Azure Lighthouse to manage access through one resource to all customer tenants. Without Azure Lighthouse, Contoso would have to either

  • Create separate accounts in Northwind Traders, Coho Winery, and LitWare Azure Active Directories and secure and manage these properly

or

  • Invite their superuser accounts as guest accounts to each customer Azure AD tenant – and convince the customer in the process that this account should be a trusted account

Regardless of the approach, the account used to access customer tenants would then need to have permissions delegated for daily operations and services the customers are paying Contoso. Some customers might require tricky and complicated access methods, such as using a separate jump server or a dedicated VPN connectivity to access the tenant in the first place. Others might require two-factor authentication (usually Multi-Factor Authentication in Microsoft world) that is then bound to a single device.

Several employees could share accounts that MSPs such as Contoso in this example might use. Whoever has the device registered for MFA claims at any given time has to relay the claim or token to the other person trying to access a customer tenant. This effectively mitigates the usefulness of using two-factor authentication in the first place in a scenario like this, and some MSPs might feel inclined to disable it for being too cumbersome and problematic in a day-to-day usage scenario.

How does Azure Lighthouse work?

Azure Lighthouse relies on  Azure Delegated Resource Management, which provides basic operations for the MSP. These operations include classic CRUD (Create, Read, Update, Delete) operations at a given scope.

A service provider first identifies the access roles and users/groups that they will use to manage a given customer’s Azure resources. Then, by either using a manual approach through PowerShell or a specially crafted Azure Marketplace offering, the customer’s Azure tenant is on-boarded (granted delegated access to). The service provider can then see the customer’s Azure tenant ‘light up’ in their own Azure Portal view and can manage the tenant as they would manage any other tenant.

Key here is delegated access, as both the customer and the service provider can mutually agree on the level of access needed and then granted. The service provider shouldn’t need Owner or Contributor-level permissions to all resources, as a customer might want to decentralize access and management between multiple MSPs.

Getting started with Azure Lighthouse

A GitHub repo has been made available by Microsoft, that has the necessary base templates for either (PowerShell or Azure Marketplace) approach for onboarding. You’ll primarily be working with simple ARM templates that are described in JSON.

Let’s consider an example. Contoso, our fictional MSP, would like to offer support services for Coho Winery. The scope of the support is agreed on Azure Log Analytics so that Contoso can monitor and proactively provide support using Azure Monitor and Azure Data Explorer. Coho Winery has several other partners providing support for other Azure resources, like Northwind Traders who is a fierce competitor to Contoso. This is one of the reasons that Coho Winery would like to shield Contoso’s visibility into their Azure resources, but would still like to benefit from Contoso’s expertise in analyzing Azure issues.

To onboard Coho Winery, Contoso needs to craft two JSON files – the ARM template, and a parameter file. The former can be re-used for other customers, and the latter is modified according to Coho Winery’s needs.

Coho Winery’s also needs to have Microsoft.ManagedServices resource provider registered:

The ARM template, rgDelegatedResourceManagement.json, is one of the many sample templates from Microsoft. It can be used as-is or modified for specific needs. In this example, Contoso chose to remove lines 28 to 31:

,
        "rgName": {
            "type": "string"
        }

This way Contoso can get subscription-wide access, instead of just delegated access to a specific Azure Resource Group.

The parameter file (see template here) is modified more heavily, again based on specific needs that Coho Winery has requested. The modified parameter file looks like this:

{
    "$schema": "https://schema.management.azure.com/schemas/2018-05-01/subscriptionDeploymentParameters.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "mspName": {
            "value": "Contoso"
        },
        "mspOfferDescription": {
            "value": "Contoso's managed services"
        },
        "managedByTenantId": {
            "value": "59323343-539f-43f4-8443-d313d3ca25c6"
        },
        "authorizations": {
            "value": [
                {
                    "principalId": "ce614409-9cfb-43f4-b653-b8fcfd2b4ad8",
                    "principalIdDisplayName": "Contoso Support Account",
                    "roleDefinitionId": "73c42c96-874c-492b-b04d-ab87d138a893"
                }
              
            ]
        }
    }
}

mspName is the name of the MSP providing the service. mspOfferDescription is for describing the service, as Contoso might have multiple different offerings for Coho Winery in place. managedByTenantId is Contoso’s tenant ID. You can resolve this easily using ShareGate’s free service, or look it up using Azure CLI, Azure PowerShell or Azure Portal.

Authorizations list one or more delegated permissions. principalId is the resource (user, group, or service principal) that needs access to Coho Winery’s tenant. principalDisplayName is a friendly name for this, and roleDefinitionId is a role ID from Azure’s RBAC (Role-Based Access Control). We’ve chosen Log Analytics Reader. You can view all the IDs and built-in roles here.

Using these two files, we can use PowerShell’s Azure management module ‘Az’ to grant the permissions. Coho Winery (the customer) needs to run the following command against their Azure tenant:

New-AzDeployment -Name ContosoLogAnalytics -Location "West Europe" -TemplateFile "c:\temp\contoso-loganalytics-delegate.json" -TemplateParameterFile "c:\temp\contoso-loganalytics-delegate-parameters.json" -Verbose

This will read through the template, apply the parameters, and grant Contoso’s principalId access to Coho Winery’s tenant. Using the -Verbose switch Coho Winery’s IT admins can verify the deployment succeeds, or if it fails, the exact reason.

Coho Winery can now review service provider offers and delegations through Azure Portal by selecting Service Providers under All Services:

Coho Winery can also use Delegations to grant additional permissions for Contoso:

On Contoso’s side, once the delegation has been applied, the principalId can now see Coho Winery’s Azure tenant through Azure Portal:

Under My Customers Contoso’s Lighthouse Admin can also review all customers and delegations in a clear view:

As the permissions are delegated and the role we delegated was Log Analytics Reader, the Contoso Lighthouse Admin cannot perform any additional tasks against Coho Winery’s tenant. Creating a Web App, for example, fails:

To verify that the delegated permissions work, Contoso’s Lighthouse Admin can view Coho Winery’s Log Analytics and perform queries:

Should Coho Winery’s later divest its support services agreement with Contoso, they can remove the delegated permissions:

Contoso’s Lighthouse Admins will immediately lose all access to Coho Winery’s Azure resources:

In summary

Azure Lighthouse is a much-needed and exciting next step for Azure Governance, which already includes Azure Blueprints, Azure Policy, Management Groups, and Resource Graph. By using Azure Lighthouse, MSPs of all sizes can effectively automate delegated access management and subsequently provide a more secure approach to managing their customer’s Azure resources. Customers can more easily manage delegated access, as they don’t have to worry about external user accounts or one service provider having Global Admin privileges for their tenants.

The PowerShell approach is a bit cumbersome for now, as one needs to take great care in specifying the principalIds and roleDefinitionIds. I also ran into a few issues when I selected a specific RBAC ID that included capabilities that are not currently supported on Azure Lighthouse. Therefore, testing is crucial, and proper comments and documentation are also beneficial.

A step beyond delegated access is the ability to push private or public Azure Marketplace offerings to select (or any) customers. I’m sure this capability will, in time provide even the small MSPs the ability to serve customers globally with greater precision and focus.