Back 
This post is the third in a series about alternatives to bastion hosts in each of the major cloud providers. The first post covered an introduction to bastion hosts, the SSH multiplexing attack, some disadvantages to managing your own bastions, and an alternative solution in GCP. The second post covered the Session Manager service provided by AWS. This post will cover the Azure Bastion service, which is a very good choice for providing management access, although it doesn’t quite address all of our requirements.
The requirements it did satisfy:
- Does not require public IP addresses for the VMs.
- Eliminates the possibility of SSH multiplexing attacks.
- Captures metadata and full session logs (when possible) for remote access.
The requirement it did not satisfy is:
- Consolidates access (such as SSH or RDP) to IAM credentials.
Although the initial access to the bastion is authorized via IAM credentials, you still need to maintain SSH certificates in order to access your virtual machines from the bastion.
While the Azure Bastion service supports Linux and Windows instances, we will focus on using it with Linux-based virtual machines running in an Azure Virtual Network.
Why Azure Bastion service?
The bastion service provides the following features that make it a good fit for our purposes:
- Allows admins to monitor and disconnect active sessions
- Captures metadata about sessions very easily in audit logs
Azure Bastion instances can be used to access virtual machines within private subnets that allow no ingress from the internet. However, the virtual machines must allow SSH ingress from the bastion subnet. Unfortunately, the bastion service does not currently support just-in-time access or Active Directory integration, although these features are on the roadmap.
The figure below, which was taken from Azure documentation, shows that the virtual machines are not at all accessible from the internet, even by our enterprise user. The user accesses the Azure portal to start a session over HTTPS with the bastion instance. Once that’s been established, the user can then use the bastion to connect to the target virtual machine(s) over SSH.
Now that you have an idea of how the Azure Bastion service works in general, we’ll take a closer look at it by breaking down the details into the following categories:
- Networking Considerations
- Virtual Machine Configuration
- Identity Management
- Logging
Networking Considerations
Create the bastion
In order to use the Azure Bastion service for access, you must first create a subnet called, “AzureBastionSubnet.” This is the name it must be given according to the documentation found here.
Once you have created the subnet, you can