Remotely Manage Your Azure VMs with Azure Bastion

Azure Bastion is a new PaaS offering that enables remote management of Azure virtual machine instances in a secure and scalable manner. Unlike other methods typically used for VM management, Bastion doesn't require open HTTP ports exposed over the Internet. Nor does it require a separate virtual machine to act as a "jump box".

VM Management

In an Azure environment, you are responsible for managing operating system updates, security patches, software installs, etc., on your VM instances. Remote management in Azure historically has been accomplished using Remote Desktop (RDP) for Windows VMs, and SSH for Linux VMs. These solutions provided the capability to remotely manage a VM instance (for the remainder of this discussion, I'll describe remote management using RDP, but the rules and requirements are effectively the same for SSH).

Remote management via RDP requires a security rule to be defined in a Network Security Group (NSG). The rule allows traffic from the Internet into the virtual network via port 3389. Opening this port to the Internet is a security risk. Azure provides a message, warning of the risks associated with allowing public access to this port, as shown in the following image.

Jumping to a Secure Solution

The security risks inherent with open ports required for RDP and SSH have led administrators to find more secure solutions. A relative newcomer to remote management scene is something known as a "jump box". A jump box is simply a VM instance within the Azure virtual network. Administrators connect into the jump box using RDP, then create a new RDP connection from the jump box into the other VMs in the virtual network. This is accomplished by separating VMs into different subnets. One subnet contains the jump box and another subnet contains the remaining VMs.

The jump box subnet has NSG rules to allow public connections to port 3389 into the virtual network. The other subnet contains the remaining VMs and has NSG rules to allow port 3389 from private IP addresses only, i.e. the private IP address of the jump box VM, or perhaps the jump box subnet itself. The VMs in this private subnet don't have to have a public IP. This configuration protects the VMs in the second subnet from the public Internet.

In an Azure environment with relatively few VMs, a jump box is a great solution. However, in larger environments with multiple VMs and many administrators, scalability becomes an issue. The jump box may not be able to meet the demand of many administrators managing several VMs simultaneously. There is also the added overhead of managing the jump box VM to consider. Azure Bastion combines the flexibility of RDP/SSH with the security of the jump box solution.

Bastion to the Rescue

Azure Bastion is a PaaS service offering, provisioned inside of a virtual network. It provides secure RDP/SSH connectivity to VMs directly in the Azure portal over TLS, without the need of a public IP address on the destination VM.

The following image, taken from the Microsoft web site, shows the architecture of a Bastion host.

As shown in the figure, Bastion works like a jump box. A Bastion session is started in the Azure portal and connects to the VM via the browser. The connection to the Bastion host from the browser is made using TLS over port 443 ensuring a secure, encrypted connection. A public IP address is not required for the VMs, and no additional security rules are configured to the NSG.

One Azure Bastion host is deployed per virtual network. A Bastion host in a virtual network can remotely manage all VMs in the same virtual network.

Bastion requires a subnet with a specific name where the Bastion host will be deployed. This subnet must be named AzureBastionSubnet. You should create this subnet in your virtual network before you create the Bastion host to make the installation go smoother. In addition to the name requirement, the subnet needs a large address space. When configuring this subnet make sure to give it an address space of at least /27 or larger.

For the sake of brevity, I'm not going to walk through the creation of a Bastion host. An Azure Bastion host can be created via the Azure portal, Azure CLI, or Azure PowerShell. There are detailed instructions for doing so on the Microsoft site. Follow these instructions to get Bastion up and running in your virtual network using your method of choice.

After creating the Bastion host, remote management of a VM is accomplished using the browser. Using the Azure portal, navigate to the VM you wish to manage and select the Connect button. Choose the Bastion value from the list of options. You will see the following dialog, prompting you for the credentials to login to your VM.

Once the connection is established, the browser will show the VM's desktop. At this point, you can remotely manage the VM from within the browser!

The first time you connect to your VM you will be prompted to allow access to the local computer's clipboard. Be aware, if you have a pop-up blocker enabled in your browser, you will need to disable the blocker to allow the prompt. Granting access allows the RDP session to share the clipboard between your local device and the remote session. Bastion supports text copy and paste only. Copying files will require you to roll your own solution, most likely a cloud based file sharing service.

The Bastion RDP session provides an icon on the left most edge of the screen. Clicking this icon expands a form where you enter text that can be shared between the local device and the VM.

In a large Azure environment, it is useful to monitor active Bastion sessions. Bastion provides a useful view into active sessions. To activate the view, click on the Sessions option available in the Bastion blade within the Azure portal.

The Session blade displays information about active sessions, such as which users are connected to which VMs, when they connected, and how long the connection has been active. The connected user's IP address is also available. You can select an ongoing session and force it closed by clicking the delete option which is available under the ellipse menu to the right of each session row.

To end your own remote session just close the browser tab. Alternatively, if you are running a Windows VM you can also disconnect via the Start | Power | Disconnect menu option.

Odds and Ends

Now that you've seen Bastion in action, you should consider the following:

• Bastion is not available in all regions.
• There are limits to the number of concurrent connections you can make. A Bastion host supports roughly 25 RDP or 50 SSH concurrent connections.
• Most modern browsers are supported, but some are not.
• The user making the connection needs the following Reader roles; on the VM itself, on the NIC with private IP of the VM, and on the Azure Bastion host.
• Bastion supports diagnostic logging which can be used to troubleshoot connection issues.
• Since Bastion is a PaaS service, there are costs associated with using it. You should budget for the additional costs before engaging the service.
• Check the documentation for an updated list of regions, an updated list of supported browsers, and pricing.

Azure Bastion provides secure, scalable remote management capabilities as a PaaS service offering. It offers the flexibility of RDP/SSH without the security risks associated with those solutions. Its capabilities match the security of jump box solutions without the overhead of managing the jump box VM itself. Bastion scales beyond a jump box solution for larger Azure environments. Get to know Bastion. It is the future of remote VM management.