Save to My DOJO
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 new 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 centrally administer every resource for every customer through a single console. Check out the first blog in this series for an answer to the question of: 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.
NOTE: Are you still looking to get started with Azure? Our eBook on Selling Azure is a great place to start for MSPs!
Azure Lighthouse Access with Azure Delegated Resource Management (ADRM)
If you have used Microsoft Azure you 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 top of 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+ different type of Azure-supported roles. During the service provider’s onboarding, a tenant can see a list of inbound access requests which clearly show what permissions are needed. All actions performed by any service provider are logged in both the tenant 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 newer technology that what is 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). Similar to traditional Active Directory which is 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 principle of least privilege, meaning that tenants should minimize access to the service providers. Customers should only grant access to resources which the MSP needs and provide as little access as is required for them to successfully complete their tasks. Not only does this protect the tenant, but also the service provider by minimizing the impact that an inexperienced or disgruntled employee could have on a customer’s environment.
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 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. This internal onboarding/offboarding can also be managed by the MSP themselves, 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.
If you are a service provider who has published their services through the Azure marketplace, then keep in mind 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 and make it private by specifying a list of subscription IDs which 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.
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 which is easy to set up following these instructions.
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, providing them with an incentive to subscribe to more of your service offerings. Make sure you check out the next post in this series which goes into detail about the integrating 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!
Not a DOJO Member yet?
Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!