Introduction
On May 30th, 2024, Microsoft announced Azure Bastion Premium, featuring the highly anticipated session recording capability. This feature, long requested since Bastion’s general availability in November 2019, marks a significant enhancement.
In my view, session recording is an essential addition to Bastion, as it provides superior compliance and security. It enables the direct recording of Bastion sessions into a Storage Account, bolstering its compliance and security capabilities.
For the uninitiated, Azure Bastion serves as a ‘jumpbox’ for virtual machines hosted on Azure. Its key advantage is eliminating the need to expose virtual machines via a public IP, thus reducing potential attack vectors and fortifying VM security. Azure Bastion is a fully managed, native service that supports both RDP and SSH connections through port 443.
In this blog I will go over how to set this up, and offer a demo/lab with a Bicep template so you can quick-deploy and test the session recording out yourself.
Setup & configuration
Let’s get started with what Azure components we’ll be deploying:
- Azure Bastion: Premium with Public IP
- Virtual Network with AzureBastionSubnet /26 & vmSubnet /24
- Two Virtual Machines (Windows for RDP and Linux for SSH)
- Storage Account for sessions to save into
The current Microsoft documentation for this is great, so I won’t be repeating what they have already set out: Configure Bastion session recording
Bicep Deployment
Next, you’ll need to login to Azure CLI and set your subscription context to deploy into, followed by creating the Resource Group:
az login
az account set -s "subGuid"
az group create --name rg-bastion-demo --location uksouth
az deployment group create -g 'rg-bastion-demo' -f '.\bastion.bicep' -p '.\bastion.bicepparam' -p parAdminPassword=Some-Password-Here
BashUsing the below Bicep template & parameters:
Bastion & Storage Setup
As mentioned before, the Microsoft documentation covers setup nicely. However, for our deployment we still need to perform some manual GUI tasks: Enabling session recording on the Bastion instance & generating a SAS URI for use.
Currently, the latest API Microsoft.Network/bastionHosts@2023-11-01 does not have a way (that I can see) to enable session recording at ARM level yet. In addition to this, generating a SAS URL via Bicep is not recommended as it’s exposing secrets via outputs.
Storage
Once the Bicep deployment has finished, locate the Storage Account resource > Data Storage > Containers > Click the three meatballs > Generate SAS:
- read, create, write, list
- set an expiry
- Generate and collect the URL produced
Lastly, notice under Settings > Resource sharing (CORS), the Bicep template has added the Bastion FQDN URL to the blob service:
Bastion Session Recording
Next, you need to enable the session recording feature within the Bastion instance config in the Portal, which can be done by:
- Navigate to the Bastion resource in the Azure porta
- Go to Settings > Configuration
- Tick session recording (Preview)
- Wait for the instance to finish deploying the changes before proceeding
Finally, to complete the setup, configure the Azure Bastion session recordings to save into the container. Use the SAS URL you’ve just generated by following these steps:
- Navigate to the Bastion resource in the Azure portal.
- Go to Settings > Session recordings.
- Click on ‘Add or Update SAS URL’.
- Paste the generated SAS URL into the field.
- Select ‘Upload’ to finalize the configuration
Recordings
Now that everything is set up, simply log in to the Virtual Machines using Azure Bastion, and the session recording will automatically start, saving directly to the Storage Account. In my example below, you will find two recordings for each deployed VM: one for RDP and one for SSH:
These uploads are very quick to appear, once the Bastion connection finishes. It’ll show the audit history with the name, which is the virtual machine, a link to view the recording, session length & date created.
Here’s a GIF on what clicking on the ‘View recording’ hyperlink looks like:
While exploring deployment options, I encountered a limitation regarding native client support and session recording as of the time of writing:
Conclusion
To conclude, I think this is a really welcomed and long anticipated addition to Bastion, under the new Premium SKU. With recordings now uploading to a blob container, organisations can implement lifecycle management and archive recordings as needed, aligning with their specific requirements.
Bastion session recording will help to bring Bastion to the forefront as a solution for organisations who have stricter compliance, regulatory and sensitive workloads as the go-to native tooling.
Moreover, the Premium SKU’s introduction of private-only Bastion access via a private IP further solidifies its security benefits.
I’m curious to hear everyone’s thoughts on the session recording feature. What do you think?
Latest Posts
Eliminate old API versions in your Azure Bicep templates
Azure DevOps Agent: Azure Container Instance with Private Azure Container Registry
Compliance with Azure Bastion: Session recording