A few weeks ago, we published this article explaining how to automate the deployment and operations of Azure Sentinel using Infrastructure as Code and DevOps principles.
We received great feedback about the article, but also some questions about how to do this in a multi-tenant environment using Azure Lighthouse. We will try to tackle the different considerations in this post, showing how to implement this with our DevOps tool of preference, Azure DevOps.
If you don’t use Lighthouse and don’t plan to (maybe you only have one Azure AD tenant), you can still apply the concepts explained in this post when working in a multi-workspace Sentinel deployment (just skip the Azure Lighthouse section).
The first thing you need to do as an MSP (or in a multi-tenant organization) working on Azure is to onboard your customers into your Azure Lighthouse environment. We will not cover this in this post, but you can read here how to do that. You can also refer to this other article published in this blog about the Sentinel-Lighthouse integration.
As a result of the Lighthouse onboarding operation, an identity (or set of identities) from the MSP tenant will be able to access the customer environments with the appropriate roles defined in your onboarding ARM template or Managed Services Marketplace Offer.
Depending on the type of service you’re offering to the customer, these roles will vary, but for a Sentinel-only service, we recommend using the Built-in Sentinel roles (Sentinel Reader, Sentinel Responder, and Sentinel Contributor). Also, take into account that you cannot delegate custom roles with Lighthouse.
Also, it is important to mention that, with Lighthouse, you can provide access to the customer environment to user principals and/or service principals that exist in your tenant. Here is an example of the roles that you could use in your Lighthouse Marketplace Offer (or ARM template) and how it’s applied to customers:
As you can see, we have defined one marketplace offer with two plans inside it. Different plans can have different permissions for the MSP to access the customer environment. It’s also important to mention that you can make plans public or private. If you choose public, any Azure user will see your offer available in the Marketplace and can purchase it. If you make it private, you specify which customer/s have access to it.
In our example, we have created two plans, one that offers a full Sentinel managed service and another with limited permissions. Each plan contains a set of delegations, some for User Groups and one for Service Principals (SPN) used for Automation purposes. That way, the customer is onboarded with all the access needed from your side to perform the requested service. The service principal is the identity that we will use to connect our Azure DevOps environment to the customer Azure subscription.
After multiple customers have purchased your Plan, the service principals you defined will have access to all those customers' subscriptions with the role you specified (in our example, Sentinel Responder or Sentinel Contributor).
Now that we have onboarded one or more customers into Azure and our identities have access to multiple tenants, we can automate the deployment and management of their Azure Sentinel environments. But how do we set up our Azure DevOps service connections, projects, repositories, and pipelines to operate multiple customers?
A service connection is the first thing to set up for a multi-tenant environment. As you might remember from our previous article on the DevOps topic, we created a single service connection pointing to a single subscription. As we are now managing multiple customers, we will need to create one for each of them. On the positive side, we can use the same service principal for all of them because it was onboarded into Lighthouse, and it now has access to all our customer subscriptions. :smiling_face_with_smiling_eyes:
As you now have multiple customer environments, you also need to create multiple variable groups, one for each customer. You will then use these accordingly inside your pipelines, stages, or jobs.
Managing code repositories requires a difficult design decision that you need to make. Are you going to use a single repository for all your customers? Are you going to create a separate repository for each customer? Do you need further isolation between customers?
These are some of the typical design choices:
. |- Artifacts/ | |- Scripts/_________________________ # Folder for scripts helpers | |- CustomerA/ ________________________ # Folder for Customer A | |- AnalyticsRules/ ______________________ # Subfolder for Analytics Rules | |- analytics-rules.json _________________ # Analytics Rules definition file (JSON) | | |- Connectors/ ______________________ # Subfolder for Connectors | |- connectors.json _________________ # Connectors definition file (JSON) | | |- HuntingRules/ _____________________ # | |- hunting-rules.json _______________ # Hunting Rules definition file (JSON) … | |- CustomerB/ | |- AnalyticsRules/ ______________________ # Subfolder for Analytics Rules | |- analytics-rules.json _________________ # Analytics Rules definition file (JSON) | | |- Connectors/ ______________________ # Subfolder for Connectors | |- connectors.json _________________ # Connectors definition file (JSON) | | |- HuntingRules/ _____________________ # | |- hunting-rules.json _______________ # Hunting Rules definition file (JSON) …
We only show 3 subfolders per customer for brevity, but there would be more for Playbooks, Workbooks, etc.
Once you have your repository structure identified, it's time to decide how you will organize your deployment pipelines.
There are several options when it comes to building your pipelines in a multi-tenant environment:
This is the approach that we used in our previous post here, although we were only managing a single Sentinel environment in that case.
You can see an example of this approach in our repository here.
You can see an example of this approach in our repo here.
Please refer to this page to better understand the different concepts (stages, steps, jobs, tasks, etc.) on structuring your pipelines.
In this post, we have explained how to combine Azure Sentinel’s DevOps capabilities using Azure Lighthouse to manage a multi-tenant environment. As you have seen, there are several implementation options; deciding which one to use greatly depends on your organization's size and how your teams collaborate with each other…at the end, this is what the DevOps culture is all about!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.