Originally posted on here at https://lucian.blog. Follow Lucian on Twitter @lucianfrango.


Since this service stumbled on the open web by way of a leak in June 2019 and having used it for a while now in preview plus since its been GA- for me this seems to be the best way to conduct secure remote access to IaaS infrastructure in Azure.

The idea of not having to deploy any internet accessible infrastructure (not having to open up TCP22 or TCP3389) to the avalanche of 1337 h4x0rs trying to gain access to anything and everything on those ports is great news. Awesome news. Amazing in fact!

For now though (as of late January 2020), FYI THIS IS IMPORTANT (in bold capitals so you know its really important), Bastion has a limiting feature that is frustrating (of course theres numerous limiting factors, but this one is particularly annoying). Let me explain…

When Bastion is deployed, that is done in a VNet with a requirement of a dedicated AzureBastionSubnet as part of the build/initial setup. No, having to deploy a dedicated subnet is not annoying. Just carve off a /27 subnet from the address space and away it goes.

Whats annoying is that other requirement in having to deploy Bastion in a VNet. With that said- Azure Bastion isn’t transitive (much like how VNets are) so it’s scope cannot extend beyond a single VNet. ANNOYING.

In other words, should you have many VNets, which I am certain you certainly do dear reader, you’ll be up for deploying many Bastions (a 1-to-1 ratio in fact if you need to remote manage any instances in all of those VNets). Most customers I work with have a large Azure footprint and a single VNet is rare. Most customers in fact reply on a Hub and Spoke network topology with centralised firewall services in the Hub.

So for now, that makes using Bastion cumbersome. You need to have a strong naming convention to know which Bastion to pick thats related to whichever VNet.

In an ideal world, the transitive limitation would be removed and you could have Bastion deployed in a Hub VNet (in some kind of logical management zone), and remote to VM instances in both the Hub and all the Spoke VNets of the environment.

 

If you agree, which I hope you do, maybe jump onto here and give it a few up votes and hopefully sometime in 2020 we’ll see Bastion a bit more useful:

https://feedback.azure.com/forums/217313-networking/suggestions/38002603-bastion-supporting-vnet-peering-for-hub-spoke-de.

Category:
Azure Infrastructure
Tags:
,