How to manage resources in the external tenant in Azure?

CATEGORIES

Tech Community

The case

You want to manage resources in other tenants without additional workload around that, such as accounts creation for you and your teammates in the destination Azure tenant or disabling those accounts if someone leaves the team. Is there any solution for that?

The answer is: yes! And it is called Azure Lighthouse.

From docs:

Azure Lighthouse enables cross- and multi-tenant management, allowing for higher automation, scalability, and enhanced governance across resources and tenants. ~What is Azure Lighthouse?

How does it work?

Azure Lighthouse enables managing resources in another tenant directly from your ‘home’ tenant. You can define with that which users and/or Active Directory Security groups should have access to which resources and with which roles.

Requirements

To set up the Azure Lighthouse solution, you have to fulfill some requirements and gather a bunch of information. The full list you can find here:

  • Your tenant ID
  • Customer’s tenant ID
  • List of subscription IDs and/or resource group IDs to which you have to have access
  • List of users and/or Active Directory groups which you want to assign to manage customer environments – IMPORTANT: AD groups have to be Security groups!
  • List of roles and permissions (with their IDs) which you want to assign
  • Someone with non-guest account in customer’s tenant and Microsoft.Authorization/roleAssignments/write permission – it is required to create assignment (Deploy the Azure Resource Manager templates)
  • Something called mspOfferName and mspOfferDescription – the first one defines the connection between both tenants and their resources. IMPORTANT: You can’t have multiple assignments at the same scope with the same mspOfferName.

How to onboard the customer?

If you gathered all of the above requirements, on Github you can find example ARM templates that allow you to onboard. You have to deploy prepared and fulfilled templates to each subscription separately.

Example

For preparing example I will use the template from the official docs:

with parameters file:

I translated the above template to Bicep – it’s much easier to read and edit for me:

The Bicep file can be used with the same parameters file as the classic ARM template.

For test purposes, I used two different Azure tenants. I ‘home’ tenant I created AD Security group called ‘PW MC’. I wanted to give to chosen subscription the Contributor rights for ‘PW MC’ AD group, so I deployed the above template with the Azure CLI:

Previously I logged into the tenant with az login --tenant command.

Effect

The effect should be visible in two places, in both tenants. In the customer tenant when we will go to the Service providers page, we will able to see something like on the screenshot below:

Service providers in Customer’s tenant

and in the ‘home’ tenant when we will visit the My customers page:

My customers page in home tenant

If we click on ‘Default directory’:

Subscription details

Then you can click on the subscription name and do whatever you want with the resources.

Summary

You can see that implementing Azure Lighthouse is quite easy and reduces management concerns. And what is the most important – it is free!

To stay up to date about our Azure Cloud Engineer Piotr Wachulec’s latest posts, make sure to check his private blog and subscribe for his newsletter!

Blog

Building better SaaS products with UX Writing (Part 3)

UX writers are not omniscient, and it’s best for them to resist the temptation to work in isolation, just as...

Blog

Building better SaaS products with UX Writing (Part 2)

The main purpose of UX writing is to ensure that the people who use any software have a positive experience.

Blog

Building better SaaS products with UX Writing (Part 1)

UX writing is the process of creating all the copy and content of a digital experience.

Get in Touch

Let’s discuss how we can help with your cloud journey. Our experts are standing by to talk about your migration, modernisation, development and skills challenges.








    Passwordless ARM templates using Azure Key Vault

    We at Nordcloud implement ARM templates on the Microsoft Azure platform regularly. In parameters, we sometimes operate with confidential data and store them in private repositories such as Azure DevOps Repos, Github or others. To maintain security at a high level, we should use solutions adapted to storing passwords (secrets).

    Below I will describe how we can implement a sample Azure Key Vault to store passwords and implement a virtual machine that will use the Azure Key Vault password during deployment.

    Required for this task

    1. ARM template Azure Key Vault:
      1. Link: https://github.com/Azure/azure-quickstart-templates/tree/master/101-key-vault-create
    2. ARM template virtual machine:
      1. Link: https://github.com/Azure/azure-quickstart-templates/tree/master/101-vm-simple-linux

    Prerequisites

    1. Powershell Core with Az module or Azure CLI
      1. PowerShell Core: https://docs.microsoft.com/en-us/powershell/scripting/install/installing-powershell-core-on-windows?view=powershell-7.1
      2. Az Module: https://www.powershellgallery.com/packages/Az/5.5.0
      3. Azure CLI: https://docs.microsoft.com/en-us/cli/azure/install-azure-cli

    If you’ve never deployed a code before, you can check how to do it on this page: https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/deploy-powershell

    Let’s get started!

    First, we create a resource group for Azure Key Vault with the command:

    New-AzResourceGroup -Name my-test-keyvault -Location westeurope

    Then we deploy Azure Key Vault from a ready template using the command:

    New-AzResourceGroupDeployment -ResourceGroupName 'my-test-keyvault' -TemplateUri 'https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/101-key-vault-create/azuredeploy.json' -keyVaultName myTestKeyVaultNC -objectId 'YOUR-OBJECT-ID' -secretName 'secret1' -secretValue $(ConvertTo-SecureString ‘PASSWORD' -AsPlainText -Force) -enabledForDeployment $true

    Hints

    • objectID – that is the user ID or SPN object that is to access this password from Azure Key Vault
    • enabledForTemplateDeployment – with the setting true because it allows us to retrieve the password during deployment
    • secretsPermissions – this will allow us to get and list the password
    • secretValue – in the password field, enter the password you want to enter in the Key Vault. Here you can also use a password generator to automatically send you a generated password that nobody knows

    Screen from Azure Key Vault – secrets:

    Screen from Azure Key Vault – Access policy:

    We start deploying a virtual machine by creating a new resource group:

    New-AzResourceGroup -Name my-test-vm -Location westeurope

    Then we need to create our own parameter file on the disk to refer to Azure Key Vault. Save the parameters file locally: https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/101-vm-simple-linux/azuredeploy.parameters.json

    Then change the values to as below:

    {
      "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
      "contentVersion": "1.0.0.0",
      "parameters": {
        "adminUsername": {
          "value": "USRE-NAME"
        },
        "adminPasswordOrKey": {
          "reference": {
              "keyVault": {
              "id": "/subscriptions/ID-SUBSCRIPTION/resourceGroups/my-test-keyvault/providers/Microsoft.KeyVault/vaults/myTestKeyVaultNC"
              },
              "secretName": "secret1"
            }
        },
        "dnsLabelPrefix": {
          "value": "UNIQ-DNS-NAME"
        }
      }
    }
    

    If you don’t know what your Key Vault Resource ID is, use the command:

    (Get-AzKeyVault -ResourceGroupName my-test-keyvault -VaultName myTestKeyVaultNC).ResourceId

    To run deployment with reference to Azure Key Vault, execute the command:

    New-AzResourceGroupDeployment -ResourceGroupName 'my-test-vm' -TemplateUri 'https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/101-vm-simple-linux/azuredeploy.json' -TemplateParameterFile/azuredeploy.parameters.json

    Summary

    We implemented the Azure Key Vault template with a password and additional access for your user ID. You then used the reference to Azure Key Vault in the parameters file to implement the password from the Key Vault for the virtual machine deployment.

    It is a solution for password management during deployments and for designing confidential data of choice for selected users. The above solution can be implemented using Azure DevOps and fully automated to keep all confidential parameters and have up-to-date data retrieved from Azure Key Vault during the implementation.

    If you liked the post, share it!

    Read more cloud blog texts on our Community & Culture pages.

    We at Nordcloud are constantly hiring Azure experts – check the open positions here, apply and join our learning community!

    Blog

    Starter for 10: Meet Jonna Iljin, Nordcloud’s Head of Design

    When people start working with Nordcloud, they generally comment on 2 things. First, how friendly and knowledgeable everyone is. Second,...

    Blog

    Building better SaaS products with UX Writing (Part 3)

    UX writers are not omniscient, and it’s best for them to resist the temptation to work in isolation, just as...

    Blog

    Building better SaaS products with UX Writing (Part 2)

    The main purpose of UX writing is to ensure that the people who use any software have a positive experience.

    Get in Touch

    Let’s discuss how we can help with your cloud journey. Our experts are standing by to talk about your migration, modernisation, development and skills challenges.