This post is part of a mini-series that explains how Microsoft Customers, Azure AD Tenants, Azure Subscriptions and Cloud Solution Providers all work together.
It is aimed at anyone who wishes to purchase Azure resources from a Cloud Solution Provider (CSP) such as NewOrbit, as well as Microsoft Partners who wish to understand the relationship between CSPs and Customers better.
This is an immensely confusing topic that often stumps people who have spent years working with Azure - even as Partners.
I focus on explaining the concepts rather than being 100% technically correct. This means some of the detail is glossed over or simplified.
This series focuses on Partners providing Azure to Customers, but the Microsoft 365 side is inherently linked to this so there will be some straying into that area as well.
As with so many things from Microsoft, Lighthouse is more than one thing… In this post, I am talking about Lighthouse as a way for a Partner to access a Customer’s Azure Subscription.
Lighthouse is a really great technology that makes life easier for Partners, whilst leaving Customers in control. It is, however, somewhat complex to get started with and it is easy to get confused. It also involves a fair bit of what looks like magic, at least initially.
What is Lighthouse?
- A Partner can define a list of Azure RBAC roles they would like specific users or groups to have in the Customer’s Azure subscription. Importantly, the users/groups exist in the Partner’s Tenant - not in the Customer’s Tenant.
- The Customer can approve this request and - importantly - can revoke it at any time.
- The Partner users who have been given access this way can access resources in the Customer’s subscription while staying logged in to their own Tenant. In fact, a Partner user can simultaneously see all the resources they have access to across all their Customers.
From a Customer’s point of view, this is easy because they do not have to create and remove Guest Users for the majority of Partner access.
From a Partner’s point of view, it makes it really easy to access resources whilst complying with least-privilege principles and auditing requirements.
What you can do with Lighthouse
- General, day-to-day access to a Customer’s Azure resources is easy with Lighthouse.
- You can use the portal as well as the CLI and most other tools transparently.
- A Partner can give Billing Reader access to an Account Manager so they can report on costs both on individual Customers and across Customers in the Azure portal.
- You can set up specific accounts or inboxes to have Monitor Reader roles so that alerts can be sent to the Partner.
- And much more. Almost anything you can do with only an Azure RBAC role, you can do through Lighthouse.
What you can’t do with Lighthouse
- You can’t use Lighthouse to access resources in the Customer’s Tenant. You can’t even list the users in the Customer’s Tenant. This is important.
- Because you cannot list users, you cannot manage permissions using Lighthouse. Pretty much any deployment to Azure should use Managed Identity for intra-service authorization, meaning you really need to be able to view and edit permissions on resources.
- If you create a Key Vault using Lighthouse, that Key Vault will be set up to be owned by the Partner’s Tenant. You can move this afterwards using PowerShell, but it can easily catch you out.
- For this and other reasons, at NewOrbit we have a general policy of not using Lighthouse to create resources in the Customer’s subscriptions, especially as we use Bicep to deploy resources. Instead, we always use a Guest Account to deploy resources.
Setting it up
Part of the relative reluctance to adopt Lighthouse more broadly is probably due to the steep learning curve, which is caused by the flexibility. You can do a lot with Lighthouse, in lots of different ways and there are multiple ways to set it up. This is great, but, as a Partner, it can be confusing and you definitely need to invest substantial time in learning it and figuring out what works best for you before rolling it out. For Customers, it is very easy and straightforward.
Users or groups
When you read the Lighthouse docs, it’s easy to think that you should specify individual users in the request. I.e. “Give Lisa Contributor access and Suleima Reader access to the subscription”.
If you do this, you will probably immediately think, then what happens when you need to change things around? And you’d be right - that approach is not smart.
Instead, you should create security groups in your Tenant and add users to those groups. Then you can specify the groups in the Lighthouse request. This makes it much easier to manage going forward.
Marketplace?
It is possible to “publish a Lighthouse offer to the Azure Market Place”. The idea is that a Customer can then subscribe to this offer and the Partner will automatically get access to the Customer’s subscription.
This, in turn, means that Partner users will all have the same access to all Customers who take up the offer. This may be appropriate in some situations, but I prefer to be a bit more granular. Unless, of course, you start to create different offers for different Customers (there is support for “private” offers, to help with this).
In any case the Market Place option is there, should you need it. I have no real experience with it as it doesn’t really fit our needs at NewOrbit.
Deployment template
You can create an ARM Template that specifies which roles you would like assigned to which Principals in the Partner Tenant. This can then be deployed to the Customer’s Tenant in the same way as any other ARM template.
Note that the Foreign Principal can do this deployment - as long as the Customer is in agreement, of course.
It is a bit daunting and there is a learning curve - but once you get the hang of it, it is pretty straight forward.
How NewOrbit does it
NewOrbit provides a range of different services to different clients. For some clients we are Azure resellers, providing Azure itself, a support contract and on-demand consultancy and architecture services. At the other end of the spectrum, we provide fully managed systems for some clients, where we develop, maintain, support and host a client system in Azure. Instead of having to hand-craft lots of different Lighthouse offers, we have a structure that allows us to adapt to each Customer’s needs.
We create a number of security groups for each Customer in our Azure AD Tenant. We then request different roles for each group in the Lighthouse ARM template. This is the same for all customers and is scripted to make it easy and replicable.
Once this has been set up, we can then add and remove individual users from these security groups on demand to give them access to the Customer’s subscription at the appropriate level.
We have a monthly review process that checks the membership of these groups, which makes it easy to spot and remove users who no longer need access.
In addition, we use Privileged Identity Manager to manage short-term assignments to these groups as appropriate. There is a way to do this directly in Lighthouse as well, but the group approach feels a bit easier - at least for us.
Conclusion
Lighthouse is a great way for a Cloud Solution Provider to access a Customer’s Azure subscription.
It is easy for the Customer to approve and revoke access, which is important for compliance and auditing.
It is easy to use for the Partner users and can be used for most day-to-day tasks.
It does take quite a bit of effort to get started - there is a lot to learn and, as a Partner, it is not easy to experiment and test things out. We have certainly had to go back and re-apply Lighthouse to all our Customers a few times as we have learned more about how it works.
It is also important to understand where you should not use Lighthouse - in particular we don’t recommend using it to deploy resources to the Customer’s subscription due to certain edge cases.
