How to use AWS Workspaces as jumphosts for secure remote access?

There are a few ways to grant your developers and SREs access to your AWS infrastructure. One popular way is to create bastion hosts. This host is a public facing instance with a public IP.

Developers can log into the instance (typically a Linux or Windows OS) with a certificate file and get access to the environment behind it. But, if you have more than 5 developers and 7 VPCs, this arrangement gets very cumbersome: Pem key sharing, spreadsheets with subnet mappings, etc.

AWS Workspaces offers a great alternative to bastion hosts. What is AWS Workspaces? It is desktop in the cloud. For you citrix/vmware folks, it is VDI in the cloud. Workspaces (VDI instances) run in their own VPC, called the Workspaces VPC. This VPC is peered to other VPCs using AWS peering.

Each user (developer, tester, SRE etc.) gets their own AWS Workspace instance. Users can be authenticated using AD integration. So, it feels like a natural extension of your current desktop infrastructure into the cloud. Once the user logs in, they will be able to access the AWS instances using private IPs.

Using workspaces as jumphosts provides the flexibility of controlling user authentication using AD, provide a full desktop experience in a controlled fashion and ability to track user activity.

Further Reading: https://docs.aws.amazon.com/workspaces/latest/adminguide/amazon-workspaces.html

This set up poses one major challenge: How do you control which AWS network spaces each Workspace instance can access? AWS Security Groups are not supported on Workspaces. It is even more challenging when you consider the fact that Workspace instances run in an AWS-managed VPC.

Aviatrix encrypted peering has been the solution of choice to provide network segmentation for AWS workspaces. Aviatrix’s controller deploys gateways in the Workspaces VPC in the application VPCs that require access from the desktops. These VPCs can now be connected using encrypted tunnels using Aviatrix’s simple “point and click” interface (or using scripting tools like terraform, chef etc.)

The administrator can then set the Gateways’ security policy up to be “Deny all”. Then, selectively allow Source IP – Target IP pairs. This way, the administrator can carve out access permissions for the various workspace users.

A diagram of the set-up is shown below:

To get started, you can start with deploying the Aviatrix controller in your VPC: http://docs.aviatrix.com/StartUpGuides/aviatrix-cloud-controller-startup-guide.html