Azure Lighthouse & Sentinel at Scale – Part 2

In this post we continue our exploration of enabling multitenant management with scalability, higher automation, and enhanced governance across resources. Let’s jump right in this week and learn about delegation using Azure Lighthouse in enterprise scenarios and how an MSP might use delegation to optimize SOC operations.

First up, check out last week’s post here to get a foundational view of what Azure Lighthouse is all about.

Overview & Quick Re-Cap

What does Lighthouse bring to both sides?

1. Designed to enable enterprise
2. Cross-tenant management
3. Deployment automation
4. Single portal for SOC Teams to access Microsoft Sentinel and Log Analytics Workspaces
5. Ability to deliver well-architected services across all managed environments
6. There is no additional cost to use Azure Lighthouse (Q1 2024)

So, what happens to permissions management in the customer tenant with Azure Lighthouse?

The answer is delegation. Let’s talk about permissions…..

Delegation

A tenant is a representation of an organization. It’s a dedicated Microsoft Entra ID instance created when a tenant is created. A customer may have multiple tenants.

Each Microsoft Entra tenant is distinct and separate from other Microsoft Entra tenants, and has its own tenant ID (a GUID). (GUID = Globally Unique IDentifier).

To manage Azure resources in another tenant, a provider must sign in to the Azure portal using an account associated with the target, 2nd tenant. This is where without delegation you may have multiple credentials to multiple tenants to accomplish the required work.

Delegation means one login.

Should I say that again? Delegation means you use just one login to administer multiple tenants.

A tenant is a dedicated and trusted instance of Microsoft Entra ID. Typically, each tenant represents a single organization. Azure Lighthouse enables logical projection of resources from one tenant to another tenant. This allows users in the managing tenant (such as one belonging to a service provider) to access delegated resources in a customer’s tenant, or lets enterprises with multiple tenants centralize their management operations.

In order to achieve this logical projection, a subscription (or one or more resource groups within a subscription) in the customer tenant must be onboarded to Azure Lighthouse. This onboarding process can be done either through Azure Resource Manager templates or by publishing a public or private offer to Azure Marketplace. With either onboarding method, you’ll need to define authorizations. Each authorization includes a principalId (a Microsoft Entra user, group, or service principal in the managing tenant) combined with a built-in role that defines the specific permissions that will be granted for the delegated resources.

Logical Projection

Microsoft:

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.

Assigned roles to be delegated to subscriptions and resource groups, or subscriptions, are set in the delegation package created by the Provider or MSP. The general advantage here under delegation is that our SOC Team can now log in once and access multiple customers without having to manage all those different logons and passwords.

The registration assignment assigns the registration definition to a specific scope — that is the onboarded subscription or resource group.

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. (See Microsoft Image above ‘Azure delegated resource management…..’.)

All actions go through Azure Resource Manager and permissions are confirmed against the Registration Definition and Assignment.

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.

Summary

How Lighthouse Works:

1. Identify roles needed for groups, service principles, and users to manage the customer tenant.
2. Define and build the ARM template to deploy Lighthouse.
   • This builds the registration definition and registration assignment in the customer tenant.
3. Utilize Microsoft Sentinel in both the provider and customer tenants through delegation.
4. Access can be reviewed or revoked at any time by the customer.
5. Logging can be reviewed and analyzed by the customer at all times.

Join me for the next post where we continue our Azure Lighthouse deep dive! We will explore more of the technical details and talk about Lighthouse Best Practices and Security Baseline.