Accessing VMs Securely with Azure Bastion

Overview and What You Will Learn

In this lab, you will deploy Azure Bastion into a VNet, connect to a VM with no public IP address at all through the Azure Portal's browser-based session, and confirm that VM's management port was never exposed to the internet at any point.

Why This Matters in Production

A team opens SSH directly to the internet on a production VM "just for now, I'll close it later," and that exposed port becomes exactly the kind of finding a real compromise starts from - automated scanners find open management ports within hours, not weeks. Azure Bastion removes the temptation entirely, since secure access is available without ever needing to expose the port in the first place.

Core Principles

Azure Bastion is deployed once per VNet and provides secure RDP and SSH access to every VM inside that VNet through the Azure Portal, with the VM's own management port never exposed publicly at all.

Bastion requires its own dedicated subnet, specifically named AzureBastionSubnet, within the same VNet as the VMs it will provide access to.

Detailed Step-by-Step Practical Lab

1. Create a Resource Group and VNet with a subnet for VMs:

2. Add the dedicated Bastion subnet - the name must be exactly AzureBastionSubnet:

3. Create a public IP for the Bastion resource itself - this is the only public IP in the entire setup, and it belongs to Bastion, not to any VM:

4. Deploy Azure Bastion into the dedicated subnet:

5. Create a VM with no public IP address at all:

6. Confirm the VM genuinely has no public IP:

7. In the Azure Portal, navigate to the VM and select Connect, then Bastion - this opens a browser-based SSH session using Bastion's connection, with the VM's own SSH port never exposed to the internet at any point.

8. Clean up:

Production Best Practices & Common Pitfalls

Common Mistake

Deciding to skip Bastion "just for a quick one-time fix" and temporarily opening RDP or SSH to the internet instead. "Just for now" is exactly the situation real compromises come from - the moment that thought occurs is the exact moment to deploy Bastion instead.

Tip

One Bastion deployment serves every VM in the VNet - it is not a per-VM cost or setup. Once deployed, it becomes the standard, default access path for the entire environment going forward.

• The AzureBastionSubnet name is mandatory and exact. Azure specifically looks for this subnet name when deploying Bastion - a differently named subnet, even with an identical address range, will not work.
• Bastion access still respects RBAC and NSG rules on the destination VM's subnet. Deploying Bastion does not bypass other access controls - it replaces the need for a public IP and open management port, not the need for proper permissions.

Quick Reference & Troubleshooting Commands