Azure Bastion can best be described as a managed jump host. A jump host, also called a jump box, is a virtual machine that's placed on a virtual network. This article describes how to get started with Azure Bastion.
Let's say you manage two virtual machines deployed to a virtual network in Microsoft Azure. You have one Linux VM that you need to manage with Secure Shell and a Windows Server VM that you need to administer with the Remote Desktop Protocol (RDP).
However, corporate security policy prevents you from associating public IP addresses to those Azure VMs, and the business has not yet considered either a site-to-site virtual private network (S2S VPN) or ExpressRoute circuit to connect your on-premises environment to Azure.
Let's also make the assumption that the security team isn't comfortable with the expense and security overhead involved in deploying a jump host VM into your virtual network.
Well, I guess you're stuck, aren't you? No, not at all--relax. In today's tutorial, I'll show you how to use Azure Bastion.
Azure Bastion Architecture
Azure Bastion can best be described as a managed jump host. A jump host, also called a jump box, is a virtual machine that's placed on a virtual network, assigned a public IP address, and protected with strong network traffic ingress and egress rules.
The idea here is you connect to the jump host and then administer the production VMs on the network through the jump host. In Windows environments, the jump host normally runs Remote Desktop Gateway (RD Gateway) to support multiple simultaneous management sessions.
Although Microsoft hasn't confirmed my suspicion, I believe that Azure Bastion is actually an RD Gateway virtual machine under the hood. That said, we never get to interact directly with Bastion because it acts as a completely managed network virtual appliance.
Take a look at Figure 1, which illustrates my lab environment:
Figure 1. Azure Bastion network topology.
Note the following value propositions Azure Bastion brings the Azure VM administrator:
- Your VMs are never exposed to the Internet directly and do not have public IP addresses
- The Bastion host has a public IP address that accepts inbound traffic only on TCP 443 (HTTPS protocol). That is, you do NOT request connections with Bastion using management ports
- The Bastion host communicates seamlessly with the VMs on your VNet, allowing both SSH and RDP connectivity
- You can optionally deploy network security groups (NSGs) on both the Bastion and VM subnets if you want to include an additional security layer
Let's turn our attention to learning how to create and configure an Azure Bastion host.
Deploy Azure Bastion
I suggest you configure your target virtual network before you deploy the Bastion. The most important point to keep in mind is Bastion requires its own empty, non-delegated subnet. You must name the subnet (appropriately enough) AzureBastionSubnet, and the subnet ID must be at least /27.
I show you my VNet subnet configuration in Figure 2.
Figure 2. This VNet is prepared for Azure Bastion.
Next, go to the Bastions blade, click Add, and complete the Create a Bastion form. In so doing you'll supply the following values:
- Subscription
- Resource group
- Instance name
- Region: Note that Bastion is currently available only in certain Azure regions; keep an eye on the documentation for updates
- Virtual network: Be sure to specify the correct VNet and AzureBastionSubnet subnet
- Public IP address
Click Create and wait for the deployment to complete. Now we'll deploy two virtual machines to the target virtual network, one running Windows Server, and the other running Linux.
Some VM deployment notes for you to consider:
- Be sure not to associate a public IP address to these servers
- Don't associate a network security group (NSG) to the VM's virtual network interface card (NIC) yet
Figure 3 depicts what my virtual network looks like at this point. Strangely, the Azure Diagram feature doesn't show the Bastion on the AzureBastionSubnet subnet:
Figure 3. These VMs have no exposure to the public Internet.
Test RDP and SSH Connectivity
As of this writing in February 2020, we connect to our Azure VMs through the Bastion host only through the Azure portal. That said, the Azure Bastion engineering team at Microsoft eventually plan to support client-side RDP and SSH tools.
For now, browse to the Overview blade of your Windows Server VM, click Connect, and select the BASTION tab, as shown in Figure 4.
Figure 4. Connecting to a VM through Azure Bastion.
After you authenticate with a local administrative account, you'll be prompted to allow or block shared clipboard access, and then you're free to manage that server over a graphical RDP session, as shown in Figure 5.
Figure 5. Managing a Windows Server VM with RDP through Bastion.
For Linux VMs, it's the same basic connection procedure (see Figure 6). You can authenticate to the VM by using either an SSH private key or a password, and you'll ultimately reach an SSH prompt (Figure 7).
Figure 6. Connecting to a Linux VM through Azure
Figure 7. Managing a Linux VM with SSH through Bastion.
To close the session, simply close the browser tab.
As I mentioned, you can add NSGs to both your Bastion subnet as well as your VM subnets to further enhance security. Read the Azure documentation article "Working with NSG access and Azure Bastion" to get a leg up on which ports and protocols you need to allow to and from the Bastion subnet.
Gotchas
As nice as Azure Bastion is, it has some significant "growing pains" to work through, in my humble opinion. First, at $.0.19 USD per hour (approximately $138 USD per Bastion host, per month), and given you cannot stop and deallocate the Bastion, the service is rather expensive.
Second, at this time, Bastion cannot span either peered VNets or VNets connected with a VNet-to-VNet VPN. This means you must deploy a separate Bastion host on every subnet you want to manage this way. Again, this is prohibitively expensive for many businesses.
Third, because we cannot interact with the Bastion host directly, we are currently unable to configure RDP session policies as we do with Group Policy on-premises. In fact, take a look at Figure 8: you don't have too much you can do with the Bastion host outside of inspecting sessions.
Figure 8.
For Further Learning
I hope you're in a more informed position with regard to Azure Bastion than you were prior to reading this article. Allow me to leave you with some hand-selected resources to help you continue your learning journey.