An image showing a padlock being used to secure a gate

I’ve been waiting patiently for news on Azure Bastion since hearing it was in development a short while back. I wasn’t able to access the Private Preview, so news that it had entered Public Preview was a pleasant surprise!

Securely accessing IaaS workloads in Azure has always been cumbersome. If you have VPN access into your Azure environment(s) it’s a non-issue, but for isolated, or test and development workloads it represents more of a challenge. Mitigating the concern of public access via RDP / SSH with solutions like just-in-time (JIT) access is one option, but many resort to jump-box solutions which add administrative overhead and complexity.

There’s an array of good-practice documentation out there which can assist with securing administrative connections into Azure. Some of these focus on the notion of a hardened jump-box, others look at access management solutions like RD Gateway integrated with Network Access Protection (NAP). The common pitfall with these solutions is the human factor when it comes to setup. Coupled with the ongoing need to patch, update, and maintain…

Enter: Azure Bastion

The concept of a bastion host is a simple one. It focuses on the idea that a system can be designed to support specific internet-facing functions in a way which is secure. The principle is applicable to lots of workloads, but is particularly relevant to the jump-box concept (notably in AWS where the terminology has applied for a long time).

Azure Bastion is a PaaS service designed to support access to IaaS workloads via RDP and SSH; without a VPN or the assignment of public IP addresses 🙂 Deployed directly into your Azure virtual network, it supports web-based access over SSL. This negates the need for clients, and ensures access where firewalls might be blocking required ports… simplifying access in addition to being straightforward to deploy and administer:

Image showing the Azure Bastion architecture and traffic flow(s)

I’d planned to include a “how-to” guide on deployment and configuration in this post, but time has escaped me today and I was keen to get this up while the news is fresh. I’ll post this soon, along with some “real-world” twists. In the meantime the folks in the Product Team have put an excellent deployment guide together. You can find this within the release documentation, specifically the “Create a bastion host” section here 🙂

Limitations

There are some short-term limitations to be aware of. Preview status means no SLA, and availability is currently limited to a handful of regions:

  • West US
  • East US
  • West Europe
  • South Central US
  • Australia East
  • Japan East

…on the plus side, Preview status also means cheaper, with 50% off until it enters general release 🙂

It’s also worth noting that single-sign on capability via Azure AD identities is coming soon. I’m super excited about this on the basis that this will extend support to include Azure MFA and, presumably, Conditional Access. Those of you that have read my previous posts (e.g. Conditional Access: New Baseline Policies) will know that Azure AD is a firm favourites of mine!

I’ve been excited for Azure Bastion since I first got wind that it was coming. At face value it’s a minor addition, but web-based RDP / SSL is a significant new capability, and the future integrations with Azure AD will unlock more opportunities for addressing a variety of use cases. I’m particularly keen to see whether it can be paired with B2B guest access. This could be game changing for MSP’s who need secure and simple remote management of customer infrastructure.

Time will tell… in the meantime, happy playing! Feel free to comment below with your thoughts – I’d welcome your feedback. Alternatively get in touch with me on Twitter 🙂