debugging some ways to deploy applications. Sometimes when troubleshooting a problem, it helps to have administrative access directly to the server. Finding solutions to avoid making additional network firewall rules for server management can be clumsy. Creating ways to avoid modifications to your or running a dedicated VPN exist. In a world of distributed teams managing IT solutions, you may want to consider the Platform-as-a-Service (PaaS) to manage how administrators can access your resources. This blog post will look into what Bastion is and how to get started using it.
Why do you need to administrative access into your Virtual Machines still?
Not all applications are born int he cloud. Some come from remaining IT systems you may have had to lift-and-shift from another provider or an on-prem solution. You also may want to do some debugging via system logs to try to find an answer to common problems like, "why is this process failing" or the always fun "why is this server crashing" question. We've come up with many solutions to automate deploys and have systems remain ephemeral, but there's still a need for someone to log in at times.
Bastion? Jump Box?
The concept of a Bastion server isn't new, some may know it as a "jump box." Many times in my past I'd need to SSH into a company-managed server that spanned multiple networks in order to access resources. Once I had authenticated into this "jump box" I could now use an internal network to access my servers and start looking to troubleshoot whatever issue that required manual intervention.
Bastion as a term for this "jump box" has been used dating back to of Trusted Information Systems that discusses why firewalls are important. Marcus stated a Bastion host was:
Bastion host -- Bastions are the highly fortified parts of a medieval castle; points that overlook critical areas of defense, usually having stronger walls, room for extra troops, and the occasional useful tub of boiling hot oil for discouraging attackers. A bastion host is a system identified by the firewall administrator as a critical strong point in the network's security. Generally, bastion hosts will have some degree of extra attention paid to their security, may undergo regular audits, and may have modified software.
Bastion hosts look to limit potential threats of intrusion to your VMs by placing the host at the perimeter of your VNET. Access all virtual machines within a local or peered virtual network through a single hardened access point.
What is Azure Bastion?
is a way to access your VMs without having to log in directly from a local host. Bastion is a PaaS that allows you to provision a fully managed "go-between" server for accessing your servers via SSH (Windows/Linux) or RDP (Windows) over TLS. There's no agent involved, no special NSG rules, no special network ports, and no need to patch these Bastion hosts. Connections to your Virtual Machines are all done in the Azure Portal for both SSH and RDP, so there's no software installations required either on your VM or your local workstation.
From the you can find some of the key features such as:
-
RDP and SSH directly in Azure portal: You can get to the RDP and SSH session directly in the Azure portal using a single click seamless experience.
-
Remote Session over TLS and firewall traversal for RDP/SSH: Azure Bastion uses an HTML5 based web client that is automatically streamed to your local device. You get your RDP/SSH session over TLS on port 443, enabling you to traverse corporate firewalls securely.
-
No Public IP required on the Azure VM: Azure Bastion opens the RDP/SSH connection to your Azure virtual machine using private IP on your VM. You don't need a public IP on your virtual machine.
-
No hassle of managing Network Security Groups (NSGs): Azure Bastion is a fully managed platform PaaS service from Azure that is hardened internally to provide you secure RDP/SSH connectivity. You don't need to apply any NSGs to the Azure Bastion subnet. Because Azure Bastion connects to your virtual machines over private IP, you can configure your NSGs to allow RDP/SSH from Azure Bastion only. This removes the hassle of managing NSGs each time you need to securely connect to your virtual machines. For more information about NSGs, see .
-
Protection against port scanning: Because you do not need to expose your virtual machines to the public Internet, your VMs are protected against port scanning by rogue and malicious users located outside your virtual network.
-
Protect against zero-day exploits. Hardening in one place only: Azure Bastion is a fully platform-managed PaaS service. Because it sits at the perimeter of your virtual network, you don’t need to worry about hardening each of the virtual machines in your virtual network. The Azure platform protects against zero-day exploits by keeping the Azure Bastion hardened and always up to date for you.
Azure Bastion is deployed to a virtual network and supports virtual network peering. Specifically, Azure Bastion manages RDP/SSH connectivity to VMs created in the local or peered virtual networks. Azure Bastion supports manual host scaling. You can configure the number of host instances (scale units) in order to manage the number of concurrent RDP/SSH connections that Azure Bastion can support. Increasing the number of host instances lets Azure Bastion manage more concurrent sessions.
Why Azure Bastion? Why not just create a Network Security Group rule to allow you to connect to your VM directly?
Azure Bastion takes the need away from managing administrator networking rules from users by providing a "jump box" to act as a go-between for services like RDP and SSH. You do not need to add or drop security rules each time you log in, which helps reduce your potential for allowing unwanted rules to stay in your NSG. Azure Bastion deploys a fully managed PaaS service within your Virtual Network. All connections are done via your browser over TLS on port 443 so you can remain sure your connections are secure. By using this service you're also limiting port scanners from hitting your administrative ports from bad actors.
Azure Bastion and VNet peering can be used together. When VNet peering is configured, you don't have to deploy Azure Bastion in each peered VNet. This means if you have an Azure Bastion host configured in one virtual network (VNet), it can be used to connect to VMs deployed in a peered VNet without deploying an additional Bastion host.
What's this going to cost?
There are two tiers of service that can be selected when configuring Bastion. While both the Standard and Basic SKUs both permit you to access targeted VMs in your peered virtual networks and allow you to access private keys from Azure Key Vault, the Standard offering provides you with some advanced features.
The following table shows features and corresponding SKUs.
| CONNECT TO TARGET VMS IN PEERED VIRTUAL NETWORKS | AVAILABLE | AVAILABLE |
|---|---|---|
| Access Linux VM Private Keys in Azure Key Vault (AKV) | Available | Available |
| Host scaling | N/A | Available |
| Specify custom inbound port | N/A | Available |
| Connect to Linux VM using RDP | N/A | Available |
| Connect to Windows VM using SSH | N/A | Available |
Azure Bastion pricing involves a combination of hourly pricing based on SKU, scale units, and data transfer rates. Pricing information can be found on . You pay for the service as you go. You can access the Basic SKU in most regions (at the time of this post) for $0.19 per hour with free outbound data transfer for the first 5 GB per month.
How do I get started?
My VM
I've spun up an Ubuntu Linux VM that hosts a simple application in Node JS and nginx acting as a proxy. Let's say this application is currently responding slowly to my users, and I need to see directly on the server what's causing the bottleneck. You can find instructions for creating a if you'd like to follow along
When I created my server I only permitted HTTP and HTTPS protocols to access my server. My Azure Security Center managed subscription currently limits my account from allowing SSH or RDP to the public Internet. Rather than set up a special rule for just my home computer, I've disabled access to SSH via network completely on the NSG side. The Linux server itself continues to run the sshd service with no changes. I also configured this server with a simple VNET with one Subnet for my network that will be peered to a public IP for HTTP access. So far nothing that special here, just a VM with access to website ports available.
Enabling Bastion from the portal
When it's time to configure Bastion for my VM, navigate to the VM's in the Resource Group you created it in and then click on the VM's name. The simplest way to kick off the workflow to create Bastion is to just click the "Connect" button in the upper left-hand corner and select it. There's also an option under "Operations" on the left rail of the portal for Bastion. Either will do to get you started.
You are then presented with a "Use Bastion" button to click on to step through the next portion of the workflow. Click the button to move forward.
You'll now be dropped into the network setup for your Bastion. You will see there's an existing VNET space for Step 1 of 3 that won't require you to make any additional changes to the CIDR notation.
Step two will then create a secondary subnet named "AzureBastionSubnet" in an additional address space. My primary network address space is 172.17.0.0/16 and the newly created subnet is 172.17.1.0/27. The mask for this subnet must be a /26 or larger. You can also create this Bastion dedicated subnet in an NSG if you want, but in today's case I am not.
If you choose to apply an NSG to 'AzureBastionSubnet', make sure you have added the required rules to the NSG. If you do not add these rules to the NSG, the subnet creation/update will fail.
Now click "Create Subnet" to finish Step 2.
Now on Step 3 which will allow you to select the name of the Bastion host, the SKU you'd like to use, the number of instances used as hosts for your Bastion, the public IP, and the resource group it will live within.
You can customize your Bastion installation if you'd like, but in my case, I am going for the defaults.
To then kick off the Bastion creation, I'll click "Create Azure Bastion using defaults" and wait for the service provisioning to complete. It will take a few minutes because it needs to create the AzureBastionSubnet, allocate a public IP, and then provision the Bastion VMs.
Connecting to my VM via Bastion
Once I actually have a Bastion host, I can now go to the "Connect" button in the VM portal and select Bastion. Once this is done I'll be able to establish a connection via Bastion. You can select if you want to use password authentication, a private key you share from your local computer or a private key you may be storing in Azure Key Vault. I'll be selecting Azure Key Vault where I've already stored one of my regularly used keys as a secret. If you have a passphrase associated with your key, you can click "Advanced" and enter it there. Once completed click "Connect" to open up a new browser with access to the VM.
I now have an SSH terminal within my browser to access my VM, troubleshoot my issue, and then apply a fix.
The process is fairly similar to RDP into a Windows Server. You'll just provide the system password for your Windows VM and then access the RDP session in the browser.
That's that.
You're now creating connections to your VM with confidence by eliminating some of the manual management of networks or requiring a VPN. You can get started working with this service quickly by reviewing the documentation to create your Azure Bastion host for your specific needs.
Helpful docs for Azure Bastion:
Posted at https://sl.advdat.com/3cHtXRo
