Azure Lighthouse Core Services

If your organization manages Azure services for others or your cloud resources are operated by a Managed Service Provider (MSP), then you should be excited about Azure Lighthouse. This service for Microsoft Azure has simplified delegated administration for millions of cloud users. Azure Lighthouse gives MSPs a new management layer at the customer level, allowing them to administer every resource centrally for every customer through a single console. 

Check out the first blog in this series for an answer to the question: What is Azure Lighthouse? This post will focus on how the Azure Delegated Resource Management (ASDM) service and Azure Active Directory (Azure AD) technologies power Azure Lighthouse. Although this post discusses using Azure Lighthouse for MSPs to manage tenants, the same functionality can be used for enterprises to centrally manage their different cost centers across different Azure subscriptions.

Azure Lighthouse Access with Azure Delegated Resource Management (ADRM)

If you have used Microsoft Azure, you are probably familiar with Azure Resource Manager (ARM). ARM is the centralized deployment and management component for all of your resources, including VMs, web apps, networks, storage, databases, and almost every other Azure-managed service. 

Most administrators will use its GUI through the Azure Portal, but it is also supported with Azure PowerShell, PowerShell CLI, and REST APIs. It allows you to specify a subscription (for billing), create a resource group, and deploy Azure-based resources. Azure Delegated Resource Management (ADRM) is built on ARM but allows you to add an extra management layer of “customers.” This allows you to centrally manage multiple tenant accounts without having to change your credentials, subscription, or directory.

Trust is still critical with this new management paradigm so that there is transparency between the MSP and their tenant. The tenant must authorize their service provider to access specific subscriptions, resource groups, or resources. They can customize the role-based access control (RBAC), selecting from the 70+ types of Azure-supported roles. During the service provider’s onboarding, a tenant can see a list of inbound access requests that clearly show what permissions are needed. 

All actions performed by any service provider are logged in both the tenant’s and MSP’s accounts so that there is a consistent audit trail for both parties.

Behind the scenes, ADRM works by adding new security identifiers to each Azure resource, which include the service provider’s ID and role. When a tenant is onboarded either through accepting a Managed Service offering in the Azure Marketplace or authorizing access through a direct request, this service provider identifier is added. Now, the MSP can see all the resources they have been granted access to from their own centralized management dashboard.

ADRM is a technology used in the Azure Cloud Solution Provider (CSP) program. CSPs use the Administer on Behalf Of (AOBO) technology to get access to their tenant’s subscriptions. Basically, they are granted complete access to a customer environment at the subscription level. It is harder for tenants to configure as they must also grant their MSP the Admin Agent role. 

From the tenant’s perspective, this lacks the role-based access control feature to specify individual resource groups for each service provider to access. From the MSP’s side, they are not given a multi-customer management interface, so they are constantly context-switching. Azure Lighthouse will likely replace the CSP program over time.

Azure Lighthouse Security with Azure Active Directory (AAD)

Besides ADRM, the other fundamental technology used to enable Azure Lighthouse is Azure Active Directory (AAD). Like traditional Active Directory used for identity and access management in a private cloud, Azure AD protects and secures public cloud services. Each AAD user gets a tenant ID, which is a unique identifier. 

When an MSP is granted access to manage their tenant’s resources, they can perform certain operations against those resources associated with that tenant ID from their own account. Service providers now have a new dashboard, My Customers, which allows them to see each of their customers, subscriptions, offers, delegations, and permissions. Below are 4 use cases or best practices Azure AD enables in this situation:

Principle of Least Privilege

A good best practice for Azure Lighthouse users to follow is the least privilege principle, meaning tenants should minimize access to the service providers. Customers should only grant access to resources that the MSP needs and provide as little access as required to successfully complete their tasks. This protects the tenant and the service provider by minimizing the impact an inexperienced or disgruntled employee could have on a customer’s environment.

Group-Based Membership

Azure Active Directory also allows admins to be pooled together in groups, so, for example, all MSPs that need access to networks can be placed in the ‘Network Admins’ group, and so on. These groups can then be granted access to specific Azure resources. This helps all Azure Lighthouse users because as individual admins move in and out of the service provider’s company, they only need to be added or removed from the appropriate group, and their permissions will be automatically propagated to the correct resource groups. 

This is a more secure method than directly assigning admin access to each resource across all tenants. If an admin leaves the service provider, then they just need to be removed from the AD group instead of having their access revoked from numerous locations. The MSPs themselves can also manage this internal onboarding/offboarding, so the tenant does not need to worry about the service provider’s staff. MSPs should regularly review group access to maintain compliance and minimize the risk of unauthorized access.

Standardized Permissions

If you are a service provider who has published their services through the Azure marketplace, remember that the AAD permissions you request will be identical across all of your tenants. If you need to customize a plan for a specific client, you can take your public plan private by specifying a list of subscription IDs that can access it. Alternatively, you can give a tenant an Azure Resource Manager (ARM) template directly if need be. More details on this point will be provided in a future post in this series.

Multi-Factor Authentication

The final Azure Active Directory best practice you should follow is requiring multi-factor authentication (MFA). This protects the tenant and builds trust in the service provider by requiring them to log with using not just a password but also a phone or biometric device. MFA is a native Azure service that is easy to set up following these instructions.

Wrap-Up

Now, you have a fundamental understanding of the core technologies that power Azure Lighthouse, with Azure Delegated Resource Management and Azure Active Directory. By following the best practices described in this blog, you will develop trust amongst your tenants, incentivizing them to subscribe to more of your service offerings. Check out the next post in this series, which details the integration of Azure services with Azure Lighthouse, so stay tuned!

As always, if you have any questions or concerns, be sure to let us know in the comments section below!