How-To

A Look at Azure Bastion and Lighthouse

Here's a look at Azure Bastion, for securely connecting to Windows and Linux VMs, and Azure Lighthouse, which lets service providers deliver managed services for their customers .

• By Paul Schnackenburg
• 09/26/2019

Not so long ago Microsoft announced Azure Bastion, a more secure way to connect to your Windows and Linux VMs in Azure. More recently the company revealed Azure Lighthouse, a game changer for Microsoft partners building their future on managing businesses' Azure deployments.

In this article I'll look at both services, Bastion is in preview, but Lighthouse is generally available (GA).

Azure Bastion
Many businesses have migrated their (legacy) applications directly to Linux or Windows Infrastructure-as-a-Service (IaaS) VMs in the cloud. This gets you out of having to manage server hardware and lets you proudly tell your manager that "we're in the cloud now," but this brings some new challenges, particularly around managing the servers. When they were in your datacenter you probably used Remote Desktop Protocol (RDP) or Secure Shell (SSH) to remotely manage them, which was reasonably secure as it was on your internal network. But now that these same VMs are running in the public cloud you have some challenges in how you do this -- opening SSH or RDP directly on Internet-facing ports is dangerous.

There are a few options:

• Point to Site VPN (P2S) where each administrator initiates a connection to your vNet in the cloud. There's a cost overhead to run the VPN gateway in the cloud and it's also an extra step for administrators to take every time they need to do management.
• Site to Site VPN (S2S) is another option, where a router on-premises connects to your vNet(s) permanently. This is a nice option (although you still have the cost of the VPN gateway) in that you can block all access from the Internet, except for any access that the applications running in the VMs require.
• ExpressRoute is similar to S2S, except it's more secure (doesn't traverse the Internet) and has a much higher cost.
• A jump box is a single (or a couple) of VMs that have SSH or RDP access from the Internet configured that you remote into, and then from there you access all other VMs. This is a little better than having all VMs accessible, but you still have a large risk and you may need RDP licensing if you have more than two administrators who use the jump box simultaneously.
• The new Azure Bastion preview service "Jump Box-as-a-Service (JaaS?)" lets you log in to the Azure Portal and then access VMs through SSH or RDP in a Web browser, without those ports being open to the Internet and without you incurring the cost of running a VM as a jump box.

There are some limitations in the current preview (not to be used for production workloads), not the least of which is that there's no support for peered vNets and access is through the browser only (no native RDP/SSH clients, see Figure 2). There's also no option for Multi-Factor Authentication (MFA) or Azure Active Directory (Azure AD) integration and no monitoring or auditing (video recording of each session). All these features are on the roadmap.

Take care if you're integrating Azure Firewall with Bastion.

Note that if you're only managing Windows servers another option is RDP gateway, which gives you a TLS (SSL)-protected connection from a standard RDP client, optionally with Azure AD MFA protection, with no RDP licenses required on the RDP gateway server.

I think Bastion is a great first step, but the current limitations make it hard to see if this is going to be my default recommendation for my clients going forward.

Azure Lighthouse
Microsoft lives and dies by its partners and being a Managed Service Provider (MSP) in Azure hasn't been easy from a technical perspective. You had to invite your technical staff into the client's Azure AD, and if staff changed you had to update those permissions. And staff had to log on to the client's tenant and copy scripts to each tenant (leaking IP) to be able to automate management of each client, with no centralized console.

Azure Lighthouse changes all of this with a new option in Azure Resource Manager (ARM) to accept delegation of a resource to another tenant. There are two ways to onboard customers to Azure Lighthouse: You can publish an MSP offer to the marketplace, either to specific tenants ("Private") or to everyone ("Public") -- there's no option today to limit this by geography -- that a client then accepts, which will delegate their resources to the MSP. Alternatively, you can onboard existing clients using an ARM template. You specify what permissions different groups in your Azure AD tenant will need in the customers' subscriptions (Reader and Contributor will be the most commonly used) and the customer always retains Owner permissions and has the ability to un-delegate subscriptions or delete the MSP from their environment entirely.

Once a client is onboarded you can:

• Run automation across customers without the scripts having to leave your tenant
• See a combined Secure Score for your customers
• Centralize alerts across tenants
• Use Log Analytics for data from customer's logs and use Azure Security Center (ASC) as a centralized view of the security posture of all your customers

You can also use Azure Update Management to patch Windows and Linux server across customers and Azure Policy across customer's environments. There are a number of sample ARM templates in the GitHub repo for Lighthouse.

MSPs see customers who are onboarded on the new My customers page in the Azure portal (see Figure 4) and customers in turn can see their MSPs on the Service providers page in the portal.

You could potentially have a customer that delegates a resource or subscription to more than one MSP. This would work best if one had read access for monitoring and the other MSP could do management with Contributor permissions.

In the Pipeline
I really hope that support for tagging customers subscriptions come to Lighthouse. If you have a handful of clients it works well, but if you have a lot of customers there needs to be ways to group them. Another thing that I'm missing is integration with Azure Sentinel -- certainly being able to centralize the SIEM management across customers is something I'm looking forward to, but it's not available yet.

I find Lighthouse to be a revolutionary addition to Azure that's going to change the way MSPs do business in a many ways, whereas Bastion still has some work to do before it's the obvious way to do remote management.