Azure Lighthouse–Enabling Centralized Management of Many Azure Tenants

In this post, I will discuss a new feature to Azure called Lighthouse. With this service, you can delegate permissions to “customer” Azure deployments across many Azure tenants to staff in a central organization such as corporate IT or a managed service provider (Microsoft partner).

The wonderful picture of the Hook Head Lighthouse from my home county of Wexford (Ireland) is by Ana & Michal. The building dates back to just after the Norman invasion of Ireland and is the second oldest operating lighthouse in the world.

Here are some useful web links:

• Erin Chapple, Corporate Vice President, Microsoft Azure Compute: Introducing Azure Lighthouse
• Mark Russinovich Chief Technology Officer, Microsoft Azure: How Azure Lighthouse enables management at scale for service providers
• Documentation

In short what you get with Lighthouse is a way to see/manage, within the scope of the permissions of your assigned role, deployments across many tenants. This solves a major problem with Azure. Microsoft is a partner-driven engine. Without partners, Microsoft is nothing. There’s a myth that Microsoft offers managed services in the cloud: that’s a fiction created by those that don’t know much about the actual delivery of Microsoft services. Partners deliver, managed, and provide the primary forms of support for Microsoft services for Microsoft’s customers. However, Azure had a major problem – each customer is a tenant and until last night, there was no good way to bring those customers under the umbrella of a single management system. You had hacks such as guest user access which didn’t unify management – native management tools were restricted to the boundaries of the single customer tenant. And third-party tools – sorry but they’ll not keep up with the pace of Azure.

Last night, Microsoft made Lighthouse available to everyone (not just partners which the headlines will suggest!). With a little up-front work, you can quickly and easily grant/request access to deployments or subscriptions in other tenants (internal or external customers) and have easy/quick/secure single-sign-on access from your own tenant. What does that look like? You sign in once, with your work account, ideally using MFA (a requirement now for CSP partners). And then you can see everything – every tenant, every subscription, every resource group that you have been granted access to. You can use Activity Log, Log Analytics Workspace, Security Center, Azure Monitor across every single resource that you can see.

The mechanics of this are pretty flexible. An “offer” can be made in one of two ways to a customer:

• JSON: You describe your organization and who will have what access. The JSON is deployed in the customer subscription and access is granted after a few moments – it took a couple of minutes for my first run to work.
• Azure Marketplace: You can advertise an offer in the Azure Marketplace. Note that a Marketplace offer can be private.

An offer is made up of a description of:

• The service you are offering: the name, your tenant (service provider)
• The authorizations: who or what will have access, and what roles (from your tenant) can be used. Owner is explicitly blocked by Microsoft.

Here’s a simple example of a JSON deployment where a group from the service provider-tenant will be granted Contributor Access to the customer subscription.

I need to gather a bit of information:

• mspName: The name of the managed services provider. Note that this is a label.
• mspOfferDescription: The name of the service being offered.
• managedByTenantId: The Directory ID of the managed services provider (Azure Portal > Azure Active Directory > Properties > Directory ID)
• Authorizations: A description of each entity (user/group/service principal) from the MSP tenant being granted access to the customer deployment
  • principalId: The ID of the user, group, or service principal. Remember – groups are best!
  • principalIdDisplayName: A label for the current principal – what you want to describe this principal as for your customer to see
  • roleDefinitionId: The GUID of the role that will grant permissions to the principal, e.g. Contributor. PowerShell > (Get-AzRoleDefinition -Name ‘<roleName>’).id

Armed with that information you can populate the fields in a JSON parameters file for delegating access to a subscription. Here’s a simple example:

{
    "$schema": "https://schema.management.azure.com/schemas/2018-05-01/subscriptionDeploymentParameters.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "mspName": {
            "value": "Cloud Mechanix"
        },
        "mspOfferDescription": {
            "value": "An amazing service"
        },
        "managedByTenantId": {
            "value": "12345678-1234-1234-abcd-efghijklmnop"
        },
        "authorizations": {
            "value": [
                {
                    "principalId": "abcdefgh-ijkl-mnop-1234-56789012345",
                    "principalIdDisplayName": "Tier 1+ Support By Cloud Mechanix",
                    "roleDefinitionId": "1a2b3c4d-1234-a1b2-c3d4-asdfghjkjlqwert"
                }               
            ]
        }
    }
}

And then you can deploy the above with the JSON file for delegating access to a subscription:

1. Sign into the customer tenant using PowerShell
2. Run the following:

New-azdeployment -Name "CloudMechanixDelegation" -Location westeurope -TemplateFile .\delegatedResourceManagement.json -TemplateParameterFile .\delegatedResourceManagement.parameters.json

Give it a few minutes and things will be in place:

• The service provider will appear in Service Providers in the Azure Portal for the customer.
• The customer will appear in My Customers in the Azure Portal for the service provider.
• Anyone from the subscriber’s tenant in the scope of the authorization (.e.g. a member of a listed group) will have access to the customer’s subscription described by the role (roleDefintionId)
• Any delegated admins from the service provider can see, operate. manage the customers’ resources in the Azure Portal, Azure tools, CLI/PowerShell, etc, as if they were in the same tenant as the service provider.

Once deployed, things appear to be pretty seamless – but it is early days and I am sure that we will see weirdness over time.

The customer can fire the service provider by deleting the delegation from Service Providers. I have not found a way for the service provider to fire the customer yet.