Category: Management

this photo by Evgeni Tcherkasski on Unsplash
Azure

The power of Azure Lighthouse

One of the biggest challenges facing partners offering support around Azure is how best to permission access across multiple customer tenancies. Specifically how to assign the correct level of permissions to users that require them and how to monitor the users once access is enabled.

Another problem that goes hand in hand with this is how to centrally manage and monitor large volumes of resources, spread across various customers, whilst using a single shared set of tools and dashboards.

Until Azure Lighthouse, access for support would often be configured in one of the following ways:

  • Dedicated accounts within the customer tenancy (Azure AD) for partners to use for support
  • Partner accounts added as guests to every customer tenancy using Azure B2B

Contacting customers every time the partner takes on a new member of the support team. Having permissions assigned to individual guest accounts rather than security groups. Support staff switching constantly between directories. Are just some of the problems that highlight that neither option is suited to offering support at scale.

CSP partner accounts with enough permissions can use Administer-on-Behalf-Of (AOBO) to offer support. AOBO offers access to customer subscriptions at an administrator level. This method of access is generally a concern to both customers and partners. Would you really want a backup admin having full access to all services?

Azure Lighthouse uses delegated resource management to project resources from customer Azure environments, into a single partner tenancy. Delegated partner accounts can then view resources from all customer tenancies within a single portal for centralised management.

At a high level, security groups are created in the partner’s tenant, based on support roles. Users are then assigned to those security groups. In the customer’s tenancy, the required amount of permissions can then be assigned to these security groups using RBAC roles. Delegate access for these groups can then be assigned at the subscription or resource group level.

Benefits include:

  • Resources spread across multiple customers can be managed from a single portal
  • Single instances of native Azure services can be used, for example, Service Health, Azure Advisor, Azure Monitor, Security Center (A full list of enhanced services can be found here)
  • Governance can be applied centrally across all of your tenants for consistency
  • Share dashboards can be populated with information from multi-customers
  • Azure security across the entire customer base is easily visible from one location
  • More opportunity for unified automation and reporting using scripting and APIs

Ultimately, this should enable easier management at scale across your entire customer base. No more switching directories!

Delegating access or “onboarding” can be done in one of two way.

  1. Deploying an ARM template into the client’s subscription to enable delegation management as defined within the template
  2. Customer offer that has been previously published to the Marketplace.

NOTE: It is not currently possible to do this via the portal, Azure CLI or cloud shell.

Using an ARM template to Onboard

Microsoft has made available various sample templates that can be found in this Github Repository. In the following example, I’m going to be onboarding a customer at the subscription level. I’ve downloaded the template that best fits this scenario and now need to modify it to represent the offer.

Each template comes with a parameters file which needs to be populated with the following offer information:

  • mspOfferName: Name describing the offer
  • mspOfferDescription: Description of the offering
  • managedByTenantId: Partner tenant ID
  • Authorizations:  Description of each entity (user/group/service principal) from the partner tenant being granted access to the customer deployment

Having gathered the information above, I can populate the parameters.json file.

Now that I have a template for the offer, I need to deploy the template in the customer’s tenant. Although I’m running it at the subscription level, if the customer has multiple subscriptions, this would need to be repeated for each.

I’m going to use PowerShell to kick off the deployment but it could as easily be done with Azure CLI.

Once the deployment has run, I can go ahead and confirm the delegated link has been properly established.

Logged in as the customer I can browse to the Service providers blade, click on Delegations and then select the respective offering to view what roles have been assigned to the partner.

The image below shows that the Tier 1 Support and Tier 2 Support groups have been successfully assigned with the roles outlined in the parameters.json file passed to the deployment.

Having seen how this appears to the customer, let’s now switch and take a look from the service provider perspective.

Once signed in to the Azure portal as the supporting partner, I browse to the My customers blade. From here I can see the customers who I have delegated access to manage, the role assignments and subscriptions or resources groups that the partner has permissions over.

If I switch to the Virtual machines blade, I can now view virtual machines provisioned across all of my customers from the single window. This shared experience is similar across all Azure services that are now integrated with Azure Lighthouse, for example, Azure Advisor, Security Center, etc.

Removing delegation

If support is no longer required by the customer, the offering or delegation can simply be removed. Browse to the Service provider blade within the portal, select the offering or delegation and then click on the Delete button.

As you would expect, it’s also possible to remove the delegation using PowerShell or Azure CLI as outlined in this Microsoft article. https://docs.microsoft.com/en-us/azure/lighthouse/how-to/onboard-customer#remove-access-to-a-delegation

Recommendations

When planning to integrate Azure Lighthouse for the first time, there are a couple of security recommendations and general best practices that are worth keeping in mind.

  • Multi-Factor Authentication should be enforced
  • Use the least privilege principle when assigning permissions
  • Consider using Privileged Identity Management (PIM)
  • Where possible try not to assign access to entire subscriptions unless required
  • Use Azure Policy to enforce standards across all of your customers
  • Include a user with the Managed Services Registration Assignment Delete Role
  • Any user who needs to view the My customer’s page in the Azure portal has the Reader role (or another built-in role which includes Reader access).

For a more in-depth look into the Azure Lighthouse service and what it offers, take a look at Microsoft docs: https://docs.microsoft.com/en-us/azure/lighthouse/overview

Azure

Azure Bastion – End of the Jumpbox?

A common headache facing customers migrating workloads to the public cloud is deciding how best to provide secure remote access to Windows and Linux VMs.

This is normally achieved using Remote Desktop Protocol (RDP) and Secure Shell (SSH) sessions connected over public IP addresses, either directly assigned to individual hosts or a shared Jumpbox. Another option is to only allow remote access from a trusted private network over an inter-site connection such as a site-to-site VPN or ExpressRoute.

Either way, enterprises are forced to compromise security or impact the user’s experience, limiting where they can access from or by forcing them to traverse numerous network levels to gain access to the required service.

The problem with adding public endpoints directly to a host or even to a Jumpbox is that it makes them susceptible to malicious attacks. Amongst other things, it’s possible to use port scanning to discover the public IP and then brute force attacks to compromise the machine.

In efforts to reduce risk, security features such as MFA, Just in Time Access (JiT) and ACL can be implemented, but this can be difficult to manage and not totally infallible.

Azure Bastion

In answer to this problem, Microsoft has released in public preview the Azure Bastion service. Bastion is a new managed PaaS service that provides seamless RDP and SSH connectivity for your VMs over Secure Socket Layer (SSL). The service does this without having to configure each VM with its own public endpoint.

Key features available during the public preview include:

  • RDP and SSH from the Azure portal: Initiate RDP and SSH sessions directly in the Azure portal with a single-click seamless experience
  • Remote session over SSL and firewall traversal for RDP/SSH: HTML5 based web clients are automatically streamed to your local device providing the RDP/SSH session over SSL on port 443
  • No public IP required on Azure Virtual Machines: Azure Bastion opens the RDP/SSH connection to your Azure virtual machine using a private IP, limiting exposure of your infrastructure to the public Internet
  • Simplified secure rules management: Simple one-time configuration of Network Security Groups (NSGs) to allow RDP/SSH from only Azure Bastion
  • Increased protection against port scanning: The limited exposure of virtual machines to the public Internet will help protect against threats, such as external port scanning
  • Hardening in one place to protect against zero-day exploits: Azure Bastion is a managed service maintained by Microsoft. It’s continuously hardened by automatically patching and keeping up to date against known vulnerabilities.

Is it ready for the Enterprise customer?

Whether VNets have been implemented due to project segmentation, business unit, location and so on, it’s very rare to encounter an enterprise customer that does not have to control VMs sprawled over multiple VNets.

At the time of writing, limitations of the Bastion service mean that it does not yet support VNet peering. It is also only possible to deploy a Bastion host within a single VNet.

The service roadmap highlights plans to add great capabilities like Azure AD integration, Seamless Single-Sign-on and Multi-Factor Authentication to the service. Further research of various blogs and community chat suggest that support for peered VNets is another feature also being explored.

For now, when trying to access VMs attached to VNets in unsupported regions or for customers that don’t wish to deploy a Bastion host for each VNet, the workaround is to simply adopt a hub-spoke network architecture. The Bastion host sits in the hub VNet which it shares with a Jumpbox, in essence replacing the need for a secure VPN connection. It’s then from the Jumpbox that remote access can be gained across the network peerings.

Before configuring the service, there are a couple of things with the public preview to bear in mind.

  • During the public preview, the service can only be deployed from the Azure Marketplace when accessed through the Bastion preview portal: https://aka.ms/BastionHost
  • The service requires a dedicated subnet called AzureBastionSubnet of at least /27 in size
  • The preview is limited to West US, East US, West Europe, South Central US, Australia East and Japan East
  • Supported browsers are limited to Microsoft Edge (Windows), Google Chrome (Windows, Mac) and Microsoft Edge Chromium (Windows, Mac).

Configuring a Bastion Host

1. Log in to the Bastion preview portal and from the homepage, click on +Create a resource.

2. On the New page, type Bastion in the Search the Marketplace box and then press Enter.

3. Select the Bastion (preview) offering, then click on Create.

4. Fill in the Create a bastion web form and finally click Review + create

Connecting to a VM

1. Now the service has been created, simply choose a VM and click on the Connect button as normal.

2. A new BASTION tab is now active on the Connect to virtual machine blade. Select the tab, fill in the username and password details before finally clicking Connect.

The following image shows the RDP session running within the boundaries of the web browser and the Azure portal.

The user experience is the same for SSH sessions.

Conclusion

With console access lacking in Azure and many planned features on the road map, for the most part, I’m really excited about the service. Whether it completely replaces customers needs for a Jumpbox or just offers an alternative to a secure connection to a Jumpbox in place of the normal VPN or ExpressRoute offering, it’s definitely a big step in the right direction.

The one slight concern I have is that Windows or Linux admins who have previously only had access to the client OS and may know little or nothing about Azure, are suddenly going to be exposed to the Azure portal rather than accessing the client directly. Making sure the portal is locked down and security features are configured and in place will be essential. I’m sure though as the service matures, it’s likely that improvements will address this.

To answer the question above, is the Jumpbox dead? My gut feeling is that for now, probably not. In the not too distant future, well it’s looking possible.

To learn more about the Azure Bastion service, head over to Microsoft docs: https://docs.microsoft.com/en-gb/azure/bastion/bastion-overview