Azure Bastion: Secure Administrative Access in the Cloud

Introduction: The Challenge of Secure Remote Access

In the early days of cloud computing, administrators often relied on traditional methods to manage virtual machines. This typically involved exposing Remote Desktop Protocol (RDP) or Secure Shell (SSH) ports directly to the public internet. While this approach was functional, it created a massive attack surface. Hackers constantly scan the public IPv4 address space for open ports 3389 (RDP) and 22 (SSH), attempting brute-force attacks or exploiting vulnerabilities in the underlying services.

Azure Bastion was developed to solve this specific security problem. It acts as a managed Platform-as-a-Service (PaaS) offering that provides secure and seamless RDP and SSH connectivity to your virtual machines directly in the Azure portal over TLS. By using Azure Bastion, you no longer need to assign public IP addresses to your virtual machines, effectively hiding them from the public internet while maintaining administrative control. This lesson explores the architecture, deployment, and operational best practices for using Azure Bastion to protect your infrastructure.

Understanding the Architecture of Azure Bastion

Azure Bastion is not just a simple proxy; it is a specialized service that resides within your Virtual Network (VNet). When you deploy Bastion, it is placed into a dedicated subnet named AzureBastionSubnet. This placement is critical because it allows the service to communicate directly with your virtual machines using their private IP addresses.

How the Connection Works

When an administrator initiates a connection through the Azure portal, the request travels over HTTPS (port 443). The Bastion service authenticates the user and then establishes a session with the target VM. Because the traffic stays within the Azure backbone network, your virtual machines do not need a public IP address. This design ensures that your internal resources remain completely isolated from the public internet, significantly reducing the risk of unauthorized access.

Callout: Bastion vs. Jumpbox Before Azure Bastion, organizations often deployed a "Jumpbox" or "Bastion Host" VM. This was a standard virtual machine that acted as a gateway to other VMs. The problem with a custom Jumpbox is that it requires ongoing maintenance, including OS patching, security hardening, and managing public IP addresses. Azure Bastion removes this management overhead entirely because it is a managed service where Microsoft handles the underlying infrastructure and security updates.

Key Features and Capabilities

Azure Bastion provides several features that go beyond simple remote access. These features are designed to improve security, auditability, and ease of use for IT operations teams.

• Browser-Based Access: Because the connection occurs over HTTPS, you do not need any special client software installed on your local machine. You can connect to your VMs using any modern web browser.
• No Public IP Required: You can remove public IP addresses from your virtual machines entirely. This is a foundational step in hardening your cloud environment against common internet-based threats.
• Integrated Authentication: Bastion supports standard authentication methods, including local credentials, domain credentials, and even Microsoft Entra ID (formerly Azure AD) integration for SSH, which allows for passwordless access using SSH keys.
• Session Recording: For highly regulated environments, the Premium SKU of Azure Bastion allows you to record sessions. This provides a clear audit trail of what actions were performed on the server.
• Shareable Links: You can generate a shareable link that allows external users or team members to access a specific VM without needing direct access to the Azure portal, governed by strict time-bound policies.

Deployment: Step-by-Step Configuration

Deploying Azure Bastion involves a few specific steps that must be followed in order. Because Bastion requires a specific subnet, you must ensure your VNet has enough address space to accommodate it.

Step 1: Prepare the Virtual Network

Before deploying Bastion, you must create a dedicated subnet. The subnet must be named AzureBastionSubnet exactly, or the deployment will fail.

1. Navigate to your Virtual Network in the Azure Portal.
2. Select "Subnets" from the left-hand menu.
3. Click "+ Subnet" and enter AzureBastionSubnet as the name.
4. Ensure the subnet size is at least /26 (this is the minimum requirement to allow for future scaling and service updates).

Step 2: Deploy the Bastion Resource

Once the subnet is prepared, you can deploy the Bastion service.

1. In the Azure portal, search for "Bastion" in the top search bar.
2. Click "Create" to start the deployment process.
3. Select your Subscription, Resource Group, and provide a unique Name for the Bastion resource.
4. Choose the Region (it must be the same as the VNet).
5. Under the "Virtual Network" section, select the VNet you prepared in Step 1.
6. Assign a Public IP address to the Bastion service itself. Note that this IP is for the Bastion service, not your VMs. You can further restrict access to this IP using Network Security Groups (NSGs).

Step 3: Configuring the Network Security Group (NSG)

Even with Bastion, you need to manage your NSG rules correctly. The Bastion service needs to talk to your VMs, and your VMs need to accept traffic from the Bastion subnet.

• Inbound to Bastion: Allow HTTPS (Port 443) from the internet.
• Inbound to VMs: Allow RDP (3389) or SSH (22) from the AzureBastionSubnet.

Warning: Do Not Open Ports to the World A common mistake is leaving RDP/SSH ports open to the "Internet" or "Any" source in your NSG rules. When using Bastion, your NSG rules for the VM subnet should only allow traffic originating from the AzureBastionSubnet IP range. If you leave the ports open to the public, the Bastion service provides no security benefit because the VM remains accessible via its public IP address.

Advanced Connectivity: Native Client Support

While browser-based access is convenient, many administrators prefer using their native tools like PuTTY, MobaXterm, or the native Windows RDP client. Azure Bastion supports this via the "Native Client" feature. This allows you to tunnel your local traffic through the Bastion service without relying on the browser's HTML5 interface.

How to use the Native Client

To use this, you must have the Azure CLI installed on your local machine.

1. Open your terminal or command prompt.
2. Log in to Azure: az login.
3. Execute the following command to connect via SSH: az network bastion ssh --name <BastionName> --resource-group <RGName> --target-resource-id <VMID> --auth-type ssh-key --ssh-key ~/.ssh/id_rsa

This command establishes a local tunnel to the Bastion service, which then forwards the encrypted traffic to your target VM. This method is often faster and provides a more responsive experience, especially for tasks that involve heavy typing or file interactions.

Security Best Practices for Azure Bastion

Implementing Bastion is a significant step toward a secure environment, but it must be managed correctly to be truly effective.

1. Enforce Just-in-Time (JIT) VM Access

Combine Bastion with Microsoft Defender for Cloud’s JIT access. JIT allows you to lock down your VMs completely, and only open the ports for a limited period when a user requests access. When combined with Bastion, you create a "double-lock" mechanism: the port is closed by default, and even when opened, it is only accessible through the secure Bastion gateway.

2. Monitor with Azure Monitor

You should enable diagnostic logs for your Bastion resource. These logs provide visibility into who is connecting to which VM, when the connection started, and when it ended. Sending these logs to a Log Analytics workspace allows you to create alerts for unusual activity, such as connections outside of business hours or unsuccessful login attempts.

3. Use Conditional Access

If you are using Microsoft Entra ID, apply Conditional Access policies to the Azure portal. You can require Multi-Factor Authentication (MFA) for any user attempting to access the Azure portal. This ensures that even if an administrator's password is compromised, the attacker cannot access the Bastion service to reach your internal VMs.

4. Regularly Audit NSG Rules

Infrastructure changes frequently. It is common for someone to accidentally add an "Allow All" rule to an NSG during troubleshooting. Use Azure Policy to audit your NSGs and automatically flag any rules that permit inbound RDP or SSH access from the public internet.

Comparison: Bastion SKUs

Azure Bastion is available in different SKUs, each offering different levels of capability. Choosing the right one depends on your organizational requirements.

Note: The Developer SKU The Developer SKU is a cost-effective option for individual developers or small teams. It does not require a public IP address for the Bastion resource itself, making it even more secure. However, it is limited to native client support only and lacks the advanced auditing features found in the Premium tier.

Troubleshooting Common Issues

Even with a managed service, issues can arise. Here are the most common pitfalls and how to address them.

Connection Timeout Errors

If you receive a connection timeout, the first place to check is the NSG. Ensure that the AzureBastionSubnet has permission to communicate with the target VM. If the VM is in a different VNet, ensure that VNet peering is configured and that the Bastion subnet can route traffic to the destination.

"Authentication Failed" Errors

This usually indicates an issue with the credentials being used. If you are using SSH keys, ensure that the public key is correctly stored on the target VM. If you are using password-based authentication, verify that the account has not been locked out or that the password has not expired. Remember that Bastion does not override the security policies of the guest OS; if the user is disabled in Active Directory, they will not be able to log in via Bastion.

Connectivity Issues with Multiple VNets

If you have a hub-and-spoke network topology, you must deploy Bastion in the Hub VNet. For this to work, the Spoke VNets must have VNet peering enabled with the Hub. Furthermore, you must ensure that the "Allow gateway transit" setting is managed appropriately so that traffic can flow from the Bastion in the hub to the VMs in the spokes.

Practical Example: Automating Deployment with Bicep

Manually configuring Bastion is fine for small environments, but for enterprise setups, you should use Infrastructure as Code (IaC). Below is a simplified Bicep template snippet for deploying a Bastion resource.

resource bastionHost 'Microsoft.Network/bastionHosts@2023-05-01' = {
  name: 'my-bastion-host'
  location: resourceGroup().location
  properties: {
    ipConfigurations: [
      {
        name: 'bastion-ip-config'
        properties: {
          subnet: {
            id: resourceId('Microsoft.Network/virtualNetworks/subnets', 'myVNet', 'AzureBastionSubnet')
          }
          publicIPAddress: {
            id: bastionPublicIP.id
          }
        }
      }
    ]
  }
}

Explanation:

1. Microsoft.Network/bastionHosts: This defines the resource type.
2. ipConfigurations: This links the Bastion to the mandatory AzureBastionSubnet.
3. publicIPAddress: This attaches the required public IP resource.

Using templates ensures that your deployment is consistent, repeatable, and documented, which is a core tenet of modern cloud management.

Summary: Key Takeaways

1. Security First: Azure Bastion is a critical tool for removing public IP addresses from your virtual machines, which is the single most effective way to prevent internet-based brute-force attacks.
2. Managed Advantage: By using a PaaS service, you shift the burden of patching and securing the access gateway to Microsoft, allowing your team to focus on managing the actual workloads.
3. Strict Networking: Always ensure your NSGs are configured to allow traffic only from the AzureBastionSubnet. Never expose RDP (3389) or SSH (22) to the internet.
4. Audit and Monitor: Leverage the Premium SKU's session recording and diagnostic logging to maintain a full audit trail of administrative activities, which is essential for compliance.
5. Use Native Clients: For power users, the native client support provides a superior experience compared to the browser, while still benefiting from the security of the Bastion tunnel.
6. IaC Integration: Always use tools like Bicep or Terraform to deploy Bastion. This prevents configuration drift and ensures that your security posture is consistent across all your environments.
7. Layered Defense: Bastion is part of a larger security strategy. Combine it with Microsoft Entra ID, Conditional Access, and Just-in-Time access to create a robust defense-in-depth architecture.

By following these practices, you can effectively secure your administrative access, reduce the risk of unauthorized entry, and simplify the management of your virtual machine fleet within Azure. Azure Bastion represents the standard for secure connectivity in modern cloud architecture, and mastering its deployment and configuration is an essential skill for any cloud administrator.