Background

In order to deliver a seamless automation experience against Azure hosts that exist in private or isolated subnets, the Azure Bastion Service provides an easy way to allow access to those services without the need to stand up and manage a custom Bastion host. This service allows for a cloud-native way to spin up a bastion connection on-demand, access the resources behind the bastion for automation, and then tear it down when no longer required. Support for this service will allow for more secure managed application network topologies and network traversal and allow Ansible to deliver agentless configuration against isolated nodes in Azure.

Business impact: Automating the creation and deletion of Azure Bastion Hosts removes the need for customers to spend time setting up bastion hosts themselves. Quickens the ability to jump hosts on demand when needed, and remove the bastion host when done. Prevents unnecessary costs when customers may not remove the host on their own and saves time in setting up.

Story

As an Ansible on Clouds user I can configure the Azure Bastion Service through playbook automation to configure and manage the solution for my organization and I can use that service as a jump host option at play run time to access Azure resources on private networks that are not directly connected to my Ansible deployment through network peering. This allows me to configure secure DMZ-style ephemeral access to Azure private networks without the cost and security implications of managing long-lasting virtual bastion hosts.