Atrás 
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 create a bastion instance within that subnet. An external IP address will be assigned to the bastion for you. There is no need to assign a Network Security Group (NSG), or set any firewall rules on the bastion instance.
Setting the NSG rules
By default, there is no network security group (NSG) assigned to the bastion host. The recommendations for NSG rules associated with the bastion hosts and virtual machines are available here. We implemented the recommendations, and you can see our NSGs below.
This screenshot shows an example of the NSG associated with our bastion host:
The default NSG rules will allow the bastion to connect to the virtual machines, but it allows all ports and protocols. This screenshot shows an example of the NSG associated with our virtual machines:
The NSGs contain inbound and outbound rules. These are processed in the order of the priority number assigned, with the lowest number taking precedence. As traffic is evaluated, if it does not match the lower numbers, it will progress and eventually be caught by the “Deny” statements at the highest values. In this example, any traffic that originates from within the Virtual Network will be allowed to hit the network interface of the virtual machine(s).
If you applied a rule with a higher priority that