[Book excerpt] Extending Azure management with Azure Lighthouse

Illustrated Azure Blueprints icon Illustrated Azure Blueprints icon

Read an excerpt (Ch 7) from Modern Business Powered by Microsoft Azure: Governance (2019), our governance guide by Jussi Roine.

But wait, there’s even more to governance than the services we’ve covered so far! Azure Lighthouse is the latest governance service in Microsoft’s cloud portfolio, and it’s a bit particular.

While Azure Blueprints and Azure Policy band together to help any company maintain and govern it’s cloud, Azure Lighthouse is primarily intended for Managed Service Providers (MSPs).

Let’s have a look at what it does. 

Azure Lighthouse brings better management capabilities and flexibility for managing multiple Azure tenants through delegated access. Others can—of course—use and benefit from it, but it’s essential to understand that the usage scenarios relate heavily to MSPs and the multiple Azure tenants they need to access. Companies with multiple separate Azure subscriptions can also benefit from Azure Lighthouse.

Overcast logo white

Uncover all the cost-saving opportunities in your Azure environment

What value does Lighthouse add?

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 it’s own 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

  1. Create separate accounts in Northwind Traders, Coho Winery and LitWare Azure Active Directories and secure and manage these properly, or;
  2. 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.

The key is delegated access

Regardless of the approach, the account used to access customer tenants would then need to have permissions delegated for the daily operations and services the customers are paying Contoso for. 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 the 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.

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 onboarded (granted delegated access to).

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 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

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, 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 reused for other customers, and the latter is modified according to Coho Winery’s needs.

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

Screenshot demonstrating Microsoft.ManagedServices registerd in the subscriptions area of the Azure Portal

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:

Lines 28 to 31 of ARM template, rgDelegatedResourceManagement.json

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

The parameter file is modified more heavily, again based on specific needs that Coho Winery has requested.

The modified parameter file looks like this:

A modified version of ARM template, rgDelegatedResourceManagement.json with line 28-31 removed.
Overcast logo white

Save time and money in Azure with ShareGate Overcast

Overcast illustration

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 whatismytenantid.com service, or look it up using Azure CLI, Azure PowerShell or Azure Portal.

Authorizations lists 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.

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:

A PowerShell command to read through the template, apply parameters, and grant principalId access

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.

A screenshot of a verification report from a command run with the -Verbose switch enabled.

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

A screenshot of the Azure Portal showing service provider offers and delegations

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

A screenshot of the Azure Portal showing how to use delegations to grant additional permissions

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

A screenshot of the Azure Portal showing that principalId can see tenant details once the delegation has been applied

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

A screenshot of the Azure Portal showing that Admins can review customer and delegations under My Customers

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:

A screenshot of the Azure Portal showing an error caused the limited permissions granted to a Log Analytics Reader

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

A screenshot of the Azure Portal showing a Log Analytics Reader's capability to review logs and perform queries

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

A screenshot of the Azure Portal showing the customer's capability to remove delegated permissions

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

A screenshot of the Azure Portal showing an access denied message to a user whose delegated permissions have been removed

Moving governance forward

Azure Lighthouse is a much needed and exciting next step for Azure governance. By using Azure Lighthouse, MSPs of all sizes can effectively automate delegated access management and subsequently provide a more secure approach for 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.

You can download the full version of ShareGate & Jussi Roine's Modern Business Powered by Microsoft Azure: Governance now. You can also read more insights from Jussi at his website (jussiroine.com).

Recommended by our team

What did you think of this article?

Order the ShareGate Takeaway, your to-go recap of Ignite 2020 Be the first to catch what we've cooked up!