Azure Bastion

Mastering Azure Bastion: Secure Remote Access for Cloud Infrastructure

Introduction: The Challenge of Secure Remote Management

Managing virtual machines in a cloud environment often presents a significant security dilemma. Traditionally, administrators have relied on public IP addresses assigned directly to virtual machines to facilitate remote management via protocols like RDP (Remote Desktop Protocol) or SSH (Secure Shell). While this approach is functional, it exposes your infrastructure directly to the public internet. This exposure invites a constant barrage of automated scanning and brute-force attacks from malicious actors looking for open ports. Once a port is open to the world, your virtual machine becomes a target for credential stuffing, exploit attempts, and potential unauthorized access.

Azure Bastion is a service designed to solve this exact problem by providing secure, seamless RDP and SSH connectivity to your virtual machines directly in the Azure portal over SSL. By using Azure Bastion, you no longer need to assign public IP addresses to your virtual machines for administrative access. Instead, the Bastion service acts as a hardened gateway, sitting inside your virtual network. When you connect, you initiate a session through the Azure portal, and the Bastion host facilitates the connection to your private virtual machine. This architecture ensures that your servers remain completely isolated from the public internet while still allowing authorized administrators to manage them.

Understanding and implementing Azure Bastion is not just about convenience; it is a fundamental pillar of a "Zero Trust" security strategy. By removing the need for public IP addresses on your workload virtual machines, you shrink your attack surface significantly. In this lesson, we will explore the architecture of Azure Bastion, how to configure it effectively, how to integrate it into your existing network topologies, and the best practices for maintaining a secure administrative environment.

The Architecture of Azure Bastion

Azure Bastion is a Platform-as-a-Service (PaaS) offering, meaning Microsoft manages the underlying infrastructure, patching, and availability. When you deploy a Bastion host, you are essentially deploying a managed virtual appliance into a dedicated subnet within your Azure Virtual Network (VNet). This subnet must be named AzureBastionSubnet.

Key Components

• The Bastion Subnet: This is a mandatory requirement. The subnet must be at least a /26 in size and must be named specifically AzureBastionSubnet. This naming convention allows the Azure control plane to identify where to deploy the Bastion service.
• The Public IP Address: While your virtual machines do not need public IPs, the Bastion host itself requires a public IP address (or can be configured with specific private endpoints in advanced tiers) to allow you to connect to it from the Azure portal.
• The Bastion Host: This is the service resource that holds the configuration and handles the RDP/SSH traffic. It performs the protocol translation, wrapping your session in an encrypted SSL/TLS tunnel.
• The Target Virtual Machine: Your target VM resides in a private subnet. It does not need a public IP address and should ideally have Network Security Group (NSG) rules that allow traffic only from the Bastion subnet.

Callout: Bastion vs. Jumpbox Before Azure Bastion, the industry standard was to create a "Jumpbox" or "Bastion VM." This involved creating a small, hardened Linux or Windows VM, placing it in a public subnet, and managing it yourself. This approach required you to manage OS patches, security updates, and local firewall configurations. Azure Bastion replaces this manual labor with a fully managed service, eliminating the management overhead and reducing the risk of misconfiguration on the jumpbox itself.

Deployment Step-by-Step

Deploying Azure Bastion is a straightforward process, but it requires careful planning regarding network addressing. Follow these steps to set up your environment.

1. Preparing the Virtual Network

Before you can deploy the service, ensure your VNet has a dedicated subnet for the Bastion service.

1. Navigate to your Virtual Network in the Azure portal.
2. Select Subnets from the left-hand menu.
3. Click + Subnet.
4. Enter the name AzureBastionSubnet.
5. Set the address range to a size of at least /26.
6. Save the changes.

2. Deploying the Bastion Resource

Once the subnet is ready, you can provision the service.

1. Search for "Bastion" in the Azure search bar and select Bastion.
2. Click + Create Bastion.
3. Select your subscription, resource group, and provide a name for the Bastion resource.
4. Choose the region (this must match the region of the VNet where your AzureBastionSubnet exists).
5. Select the Tier (Basic or Standard). For most production environments, the Standard tier is recommended as it supports features like session recording and file transfer.
6. In the Virtual Network section, select the VNet you prepared earlier.
7. Verify that the AzureBastionSubnet is automatically selected.
8. Configure the Public IP address settings.
9. Click Review + create and finalize the deployment.

Note: The initial deployment of an Azure Bastion resource can take anywhere from 5 to 15 minutes. This is because Azure is provisioning managed compute resources behind the scenes to support your connectivity.

Connecting to Virtual Machines

Once deployed, connecting to your virtual machines becomes a native experience within the portal.

1. Navigate to the Virtual Machines blade in the Azure portal.
2. Select the VM you wish to access.
3. Click Connect in the top menu and choose Bastion.
4. Click Use Bastion.
5. Enter your authentication credentials (username and password, or SSH private key).
6. The portal will open a new browser tab/window containing the remote desktop or terminal session.

This process is entirely browser-based. You do not need to install any local clients like PuTTY or Remote Desktop Connection manager on your local machine. The entire session is encrypted over port 443, making it highly firewall-friendly for administrators working from restricted corporate networks.

Advanced Configurations and Features

The Standard Tier of Azure Bastion introduces several features that are critical for enterprise environments. Understanding these is essential for maintaining a secure and auditable infrastructure.

Session Recording

In many regulated industries, you are required to keep logs of administrative actions performed on sensitive infrastructure. Azure Bastion Standard allows you to record the RDP or SSH sessions. These recordings are stored in an Azure Storage account, providing a visual audit trail of what occurred during an administrative session.

File Transfer

Standard Bastion supports file transfer between your local machine and the remote virtual machine. This is particularly useful for uploading patches, configuration files, or scripts to your servers without needing to expose SMB or SCP ports to the wider network.

Shareable Links

You can generate a shareable link that allows a user to connect to a specific VM via Bastion without needing full access to the Azure portal. This is ideal for external contractors or developers who need temporary, scoped access to a specific resource.

IP-based Connection

Sometimes, you need to connect to a resource that is not an Azure VM, such as an on-premises server connected via VPN or ExpressRoute. With IP-based connection, you can use Bastion to connect to any machine that is reachable from your virtual network via its private IP address.

Network Security Group (NSG) Configuration

To truly secure your environment, you must configure your Network Security Groups correctly. The Bastion host acts as the entry point, so your target VMs should be locked down.

Required Inbound Rules for Bastion Subnet

The AzureBastionSubnet must allow specific traffic to function correctly:

Required Inbound Rules for Target VM Subnet

Your target VMs should only accept traffic from the Bastion subnet.

Warning: Never allow port 3389 or 22 from the "Internet" or "Any" source in your NSG. This is the exact vulnerability that Azure Bastion is intended to eliminate. Always restrict the source to the specific IP range of your AzureBastionSubnet.

Scripting and Automation

While the portal is great for ad-hoc access, automation is the key to scale. You can manage Bastion deployments using Azure CLI or PowerShell.

Deploying via Azure CLI

The following snippet demonstrates how to create a Bastion host using the Azure CLI.

# Define variables
resourceGroup="myResourceGroup"
vnetName="myVNet"
bastionName="myBastionHost"
publicIpName="myBastionPublicIP"

# Create the Public IP for Bastion
az network public-ip create \
    --name $publicIpName \
    --resource-group $resourceGroup \
    --sku Standard \
    --location eastus

# Deploy the Bastion host
az network bastion create \
    --name $bastionName \
    --resource-group $resourceGroup \
    --vnet-name $vnetName \
    --public-ip-address $publicIpName \
    --location eastus

Explanation of the Script

1. Public IP Creation: The Bastion service requires a Standard SKU public IP. We create this first to ensure it is ready for the Bastion resource.
2. Bastion Creation: The az network bastion create command links the service to the existing VNet. The command automatically looks for the AzureBastionSubnet within the VNet. If it does not find it, the deployment will fail.

Best Practices for Enterprise Environments

1. Centralized Bastion Deployment

In a hub-and-spoke network topology, you do not need to deploy a Bastion host in every spoke VNet. You can deploy a single Bastion host in your "Hub" VNet and use VNet Peering to allow the Bastion host to reach the virtual machines in the spoke VNets. This significantly reduces costs and management complexity.

2. Monitoring and Auditing

Always enable Diagnostic Logs for your Bastion resource. Send these logs to a Log Analytics workspace. This allows you to monitor:

• Who connected to which VM.
• When the connection started and ended.
• Any potential connection failures.

3. Identity and Access Management (IAM)

Use Azure Role-Based Access Control (RBAC) to limit who can use the Bastion service. Not every user who has access to the Azure portal needs the ability to initiate a Bastion session. Assign the "Virtual Machine Administrator Login" or "Virtual Machine User Login" role only to the users who strictly require it.

4. Keep Bastion Updated

Since Azure Bastion is a PaaS service, Microsoft handles the patching. However, ensure that your underlying VNet and NSG configurations are reviewed regularly to ensure they still align with your security requirements as your network grows.

Common Pitfalls and How to Avoid Them

Pitfall 1: Incorrect Subnet Naming

The most common error is failing to name the subnet AzureBastionSubnet. The Azure control plane looks for this specific string to deploy the service. If you name it "BastionSubnet" or "ManagementSubnet," the deployment will fail with a validation error.

Pitfall 2: Insufficient Subnet Size

Users often create a /29 subnet for Bastion, thinking it only needs a few IPs. However, Azure Bastion requires a /26 subnet to ensure it has enough capacity for internal operations and scaling. Always provision a /26 or larger.

Pitfall 3: Forgetting to Remove Public IPs from VMs

Deploying Bastion is only half the battle. If you leave a public IP address attached to your virtual machine, that VM is still exposed to the internet. After deploying Bastion, audit your VMs and remove all public IP addresses that are not strictly required for external-facing services (like a Load Balancer).

Pitfall 4: Misconfigured NSG Rules

Administrators often get frustrated when Bastion fails to connect and respond by opening all ports in the NSG. This defeats the purpose of the security tool. Use the IP Flow Verify tool in Azure Network Watcher to troubleshoot specific connectivity issues without resorting to "Allow All" rules.

Callout: Troubleshooting Connectivity If you find yourself unable to connect, check these three things in order:

1. Does your AzureBastionSubnet have the correct NSG rules to allow Gateway Manager traffic?
2. Does the target VM's NSG allow traffic on 3389/22 from the Bastion subnet?
3. Is there a User Defined Route (UDR) on the Bastion subnet that is forcing traffic to an on-premises firewall or appliance? Bastion requires direct internet/VNet connectivity to function correctly.

Comparison: Connectivity Methods

Frequently Asked Questions (FAQ)

Can I connect to a VM in a different VNet?

Yes. If your VNets are peered, the Bastion host in the hub VNet can reach the VMs in the spoke VNet. You do not need a Bastion host in every VNet.

Does Azure Bastion work with Linux VMs?

Yes, Azure Bastion supports SSH for Linux virtual machines. The experience is essentially a terminal session running inside your web browser.

Can I use Bastion with a Custom Domain?

Yes, you can configure Bastion to work with your own DNS settings, provided that the internal resolution within your VNet is functioning correctly.

Is there a limit to how many concurrent sessions I can have?

Yes, there are limits based on the tier. The Standard tier allows for higher concurrency than the Basic tier. For very large environments, you may need to plan for multiple Bastion hosts or ensure you are using the appropriate SKU.

Summary and Key Takeaways

Azure Bastion represents a modern approach to cloud infrastructure management. It prioritizes security without sacrificing the agility required for daily operations. As you move forward in your cloud journey, remember these core principles:

1. Zero Trust Networking: Never assume that a network is secure. By removing public IP addresses from your virtual machines, you eliminate an entire class of threats.
2. Managed Services over DIY: Wherever possible, choose managed services like Bastion over manual implementations (like Jumpboxes). This reduces your maintenance burden and ensures that security patches are handled by the provider.
3. Auditing is Mandatory: In the event of a security incident, your logs are your best friend. Always enable session recording and diagnostic logging for your administrative gateways.
4. Network Architecture Matters: Design your network with a hub-and-spoke model to centralize management services like Bastion. This makes it easier to enforce security policies and monitor access.
5. Strict NSG Hygiene: Your Network Security Groups are your first line of defense. Keep them restrictive, and use the "Principle of Least Privilege" when defining who can access the Bastion service.
6. Automation: Treat your infrastructure as code. Use CLI or Terraform to deploy your networking components to ensure consistency across your environments.
7. Browser-Based Access: Emphasize the ease of access provided by browser-based connectivity. It removes the need for local client management and works regardless of the user's local operating system or installed software.

By implementing Azure Bastion correctly, you are not just setting up a tool; you are building a robust, defensible foundation for your cloud operations. As threats evolve, the move toward identity-based and gateway-based access will continue to be the gold standard for secure infrastructure management. Take the time to configure your Bastion environment with care, and your future self will appreciate the security and peace of mind it provides.