Greetings my fellow Technology Advocates and Specialists.
In this Session, I will provide real-time insights on AZURE LIGHTHOUSE. As Azure Lighthouse provides multiple features, hence for the purpose of this Blog post, we focus on 1) Onboarding Azure Subscription, and 2) Onboarding Azure Resource Group only.
WHAT IS COVERED:-
Live Recorded Session.
Presentation Displayed During Live Demo.
Concepts of Azure Lighthouse.
How is/was the Management before Azure Lighthouse.
Pricing.
Real-time Use Cases.
Important Pointers on Azure Lighthouse.
Deployment Requirement of Azure Lighthouse Using Portal.
Step By Step Process to Implement Azure Lighthouse.
Verification - Service Provider View.
Quick Test.
Option to Automate Deployment of Azure Lighthouse.
Challenges Encountered.
LIVE RECORDED SESSION:-
LIVE DEMO was Recorded as part of my Presentation in JOURNEY TO THE CLOUD 4.0 Forum/Platform
Greetings my fellow Technology Advocates and Specialists.
In this Session, I will provide real-time insights on AZURE LIGHTHOUSE. As Azure Lighthouse provides multiple features, hence for the purpose of this Blog post, we focus on 1) Onboarding Azure Subscription, and 2) Onboarding Azure Resource Group only.
WHAT IS COVERED:-
Live Recorded Session.
Presentation Displayed During Live Demo.
Concepts of Azure Lighthouse.
How is/was the Management before Azure Lighthouse.
Pricing.
Real-time Use Cases.
Important Pointers on Azure Lighthouse.
Deployment Requirement of Azure Lighthouse Using Portal.
Step By Step Process to Implement Azure Lighthouse.
Verification - Service Provider View.
Quick Test.
Option to Automate Deployment of Azure Lighthouse.
Challenges Encountered.
LIVE RECORDED SESSION:-
LIVE DEMO was Recorded as part of my Presentation in JOURNEY TO THE CLOUD 4.0 Forum/Platform
Azure Lighthouse Service was created by Microsoft keeping in mind the Cloud Service Providers.
Azure Lighthouse allows you to enable cross-tenant management and multi-tenant management.
Using Azure Lighthouse, service providers can deliver secure managed services and perform numerous management tasks directly on a customer’s subscription or a resource group.
There are 2 Views when we manage Cloud:- 1) Service Provider; and 2) Customer
Service Provider are mainly responsible for managing 1) Customer Subscription(s) 2) Resource Group(s) 3) Resource(s) and 4) Azure AD Tenant Management (In Some Cases).
Imagine a Scenerio, where a Service Provider has to support Azure Resources spread across, for example, in 10 Subscriptions at a time. All Cloud Engineers who work for the Service Provider will then have to switch between 10 Subscription to support Customer`s Cloud Infrastructure. AZURE LIGHTHOUSE eliminates this PROBLEM STATEMENT.
HOW IS/WAS THE MANAGEMENT BEFORE AZURE LIGHTHOUSE:-
Service Provider has its own Azure Active Directory (AAD) Tenant. In that Tenant, exists the User Identities which provides support to Customer`s Cloud Infrastructure.
Now, Customer also has its own Azure Active Directory (AAD) Tenant. In that Tenant, there exists one or more Subscription(s) which hosts the Azure Resources.
All required User Identities in Service Provider Tenant are added as GUEST USERS (External Identities: B2B) in Customer Tenant. Authentication however is happening over Service Provider AAD Tenant.
Guest Users in Customer AAD Tenant is then managed using AAD Groups.
Required Role Based Access Control (RBAC) is assigned to the AAD Groups which are either associated to subscription(s), Resource Group(s) or Resource(s).
CATALOG Contains one or more ACCESS PACKAGES which in turn contains one or more AAD GROUPS.
User Assignments becomes relatively easy with Access Packages as Cloud Administrator then does not have to add Users one by one to one or more AAD Groups.
PRICING:-
Azure Lighthouse powered by the Azure delegated resource management technology is available at no additional charge. Partners who use these capabilities on Azure services such as Log Analytics, Security Center, etc. will continue to pay for the underlying services. If an underlying service is free (Azure Policy, Azure Resource Health and others), then there are no changes and these services will continue to be free of charge.
Azure Lighthouse are typically used for below Scenarios:-
1.) Customer`s Azure Consumption (Billing).
2.) Managing Customer`s Cloud Infrastructure (Azure Services) over Portal.
3.) Customer`s Azure Tenant Management.
IMPORTANT POINTERS ON AZURE LIGHTHOUSE:-
We can only onboard one Subscription at a time.
We can onboard one or more Resource Group(s).
This deployment must be done by a non-guest account in the customer's tenant who has a role with the Microsoft.Authorization/roleAssignments/write permission, such as Owner, for the subscription being onboarded (or which contains the resource groups that are being onboarded).
DEPLOYMENT REQUIREMENT OF AZURE LIGHTHOUSE USING AZURE PORTAL:-
In order to Onboard a Subscription or Resource Group, we need 2 Subscriptions. One will Simulate as SERVICE PROVIDER and the other as CUSTOMER.
The Non Guest User Account should have Owner RBAC Permission on both Subscriptions.
STEP BY STEP PROCESS TO IMPLEMENT AZURE LIGHTHOUSE:-
SERVICE PROVIDER:-
Create 2 Azure Active Directory Security Groups where exists the Subscription simulating as Service Provider:- 1) LH-Contributor, and 2) LH-Reader
LH-Contributor
LH-Reader
Add Required User(s) to the respective AAD Groups
CUSTOMER:-
Use the Auto Deploy option provided in Github Azure Lighthouse samples:-
Below is how it looks on clicking Auto Deploy option. Details are filled manually. This is executed on Subscription simulated as CUSTOMER
Explanation on the Details:-
Subscription = Name of the Subscription in Customer Tenant.
Region = location of the Azure Resources deployed in the Customer Tenant Subscription.
MSP Offer Name = Custom Name indicating the Name of the Service Provider.
MSP Offer Description = Custom Description of the Service Provider.
Managed by Tenant ID = Tenant ID of the Service Provider
Authorizations = This Field has 3 Elements to it - 1) principalId = Object ID of the Security AAD Group Created in Service Provider Tenant, 2) roleDefinitionId = Built-in RBAC IDs (Here in this Example, it is Contributor), and 3) principalIdDisplayName = Name of the Security AAD Group Created in Service Provider Tenant
Below is how the Authorizations values are passed as:-
For Management and support of Azure Services over Portal, Azure Lighthouse fits, to a certain extent but if Customer follows the path of DevOps (IaC and CI/CD), then unfortunately we have to fall back to the approach described in the Section - How is/was the Management before Azure Lighthouse.
Azure Managed Resource Group with Deny Assignment
Azure Services like Azure Databricks when deployed also deploys its own Managed Resource Group (Where the resources gets created during the runtime of Databricks Cluster). This Managed Resource Group has an Deny Assignment which is by design of Microsoft. As observed, if such is the case, then Azure Lighthouse cannot onboard those Resource Group(s).
Access to Key Vault Secret protected by Access Policies
As explained, the Service Provider Identities DOES NOT reside in the Customer Tenant using Azure Lighthouse. Key Vault Access Policies are Applied either on User Identities (Guest or Non Guest), AAD Groups, Service Principal(s) or Managed Identities to Access Keys, Secrets and Certificates. But As Service Provider Identities does not exists in Customer Tenant, it becomes a challenge and hence unfortunately we have to fall back to the approach described in the Section - How is/was the Management before Azure Lighthouse.
Resources with Granular RBAC
In order to explain this topic better, I take the example of Azure Kubernetes Service (AKS). In order for Kubectl to connect to AKS, Correct RBAC assignment is required to User Identities (Guest or Non Guest) or AAD Group(s). The RBAC here I am referring to is Azure Kubernetes Service Cluster User Role. The Problem Statement here is Service Provider AAD Group assigned to Built-in RBAC (Contributor or Reader) is used to onboard a Subscription or one/more Resource Group(s). These does not allow Service Provider Identities to connect to AKS using Kubectl. Also, Service Provider Identities does not exists in Customer Tenant to assign those required AKS RBAC, and hence it becomes a challenge. Unfortunately we then have to fall back to the approach described in the Section - How is/was the Management before Azure Lighthouse.
Top comments (0)
Subscribe
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (0)