Back 
Introduction
Any enterprise running virtual machines in the cloud needs to securely manage them, which is commonly done with Remote Desktop Protocol (RDP) or Secure Shell (SSH). One problem that arises is how to manage this access without exposing the management protocols to the internet, leaving them open to various types of attacks. Historically, it has been a best practice to implement bastion hosts to limit the exposure of the management protocols. However, there are some disadvantages to that approach. Recently, the big three cloud providers, Amazon Web Services (AWS), Google Cloud Platform (GCP), and Azure, have all released services that provide an alternative solution. We’ll be publishing a series of blog posts on these solutions, detailing the alternatives from each provider in its own blog post. The last blog post of the series will cover Netskope Private Access (NPA), which provides a Zero Trust Network Access (ZTNA) solution that is easy to deploy and can secure management access across all three providers.
In this post, we’ll first review what bastion hosts are, what the difficulties are with them, and then present the general model that all of the alternative solutions follow. Finally, we’ll examine the GCP services, OS Login, and Identity-Aware Proxy (IAP) in more detail to show how they can be used as an alternative to bastion hosts.
Bastion Hosts
Before looking at the alternatives, we will review what bastion hosts are and the general issues enterprises have with them.
What are bastion hosts?
Bastion hosts are computers that are deliberately exposed on a public network to enable access to a private network. Once a user has connected to the bastion host, they are able to access additional virtual machines that are not accessible from the internet. Because they are prone to attacks, bastion hosts should be appropriately hardened. These hosts should also be logging SSH sessions and sending the logs to a centralized repository.
Bastion hosts are usually hosted in separate subnets from the rest of your internal infrastructure, so the networks can be segmented. The bastion hosts are located within a publicly available subnet, while the more sensitive virtual machines are hosted in private subnets.
Why run bastion hosts?
Bastions provide security against brute force attacks on your sensitive virtual machines, by removing the need to open the SSH port to the internet. They allow an enterprise to consolidate access and reduce the attack surface of their infrastructure. Monitoring can also be consolidated and enhanced for sensitive workloads, so alerts attributed to bastions may be addressed faster than other alerts in the organization’s security monitoring tools.
Problems with Running Bastions
The problem with running bastion hosts is that it’s additional infrastructure you have to maintain yourself. Patching, monitoring, and keeping them running creates more load on your administrators. If you need to support a large user base, then you may need to run a lot of bastion hosts, and those all just add to your cloud provider bill.
In addition, there is a feature of SSH called SSH multiplexing, which may be used to attack your organization. It could allow a malicious actor to pivot from a user’s compromised laptop to your servers in the cloud. If you are able to use an alternative to bastion hosts, which we’ll discuss in more detail later in this post, then you can effectively eliminate the possibility of SSH mul