Architecting for Cloud Security: Bastion Hosts

When it comes to cloud security, there are several concerns that come up. These can be broadly classified into two categories. The security threats faced by the customers who have their applications and data on the cloud and the threats faced by the cloud vendors. The latter is beyond the control our control, and most cloud providers today go through a rigorous compliance and certification process to address these. As such, cloud security is almost always a shared responsibility between the cloud vendor and the customer.

This post is the first part of our series focusing on cloud security from a customer perspective, where we cover secure access. More specifically, we will look at an effective way to tighten access to your resources on the cloud.

Bastion Hosts – A bastion host is an instance that resides within a public subnet or DMZ within your cloud network. These are typically accessed using SSH or RDP. Once you connect to your bastion host, the bastion host then establishes secure connectivity to other instances with your private network.

For the bastion hosts to provide an effective security layer, we need to configure the security groups and Network ACLs properly. In a typical scenario, a bastion host acts as a bridge to allow you a secure access path to other instances within your private subnet. The image above is a representation of a bastion host architecture.

Private Keys and SSH Forwarding – By default, Linux instances in EC2 use SSH key files for authentication instead of SSH usernames and passwords. We strongly recommend our customers to use key pairs as they can reduce the chance of hackers trying to guess the username and passwords. This, however, presents a challenge with bastion hosts as the private keys are typically stored on the client laptops securely and are needed to access the instances over ssh. It would not be a prudent solution to transfer these keys to the bastion hosts either.

One solution would be to enable ssh forwarding. This will allow the ssh keys to be transferred to the bastion hosts and, from there on, be used to login into the remote machines.

Most ssh clients have ssh forwarding enabled by default. Before you can use that, you will need to add your private keys to your ssh-agent as below

Adding private keys to your SSH agent

myMBP:~ samx18$ ssh-add -k MyCTREC2Key.pem

You can list the keys that are add to your agent as below

myMBP:~ samx18$ ssh-add -l 2048 41:f7:54:7d:41:26:99:26:b0:3c:09:62:6a:3d:70:42 /Users/XXXXXXXXXX/MyOregonEC2Key.pem (RSA) 2048 e2:bb:2c:6a:69:0f:93:09:43:83:f7:f8:2a:36:89:52 /Users/XXXXXXXXXX/MyCTREC2Key.pem (RSA) 2048 cd:9e:1f:99:a2:c1:9a:e0:5d:80:11:c1:0e:65:9a:79 /Users/XXXXXXXXXX/SamOregonEC2.pem (RSA) 2048 e6:d6:78:13:2e:6b:e0:e5:3f:83:f6:f8:c7:54:c3:d7 /Users/XXXXXXXXXX/RealEBSKey.pem (RSA)

Now you can use the -A option to forward your keys to the bastion hosts

myMBP:~ samx18$ ssh –A ec2-user@<bastion-IP-address>

Once connectivity is established to the bastion host, you can ssh to the instances within your private network via a simple ssh as below

ssh ec2-user@<IP-private-subnet-instance>

The ssh-agent will automatically cycle through all the keys available in its key chain, including the one that was forwarded to it from your laptop, until it finds a match with it and can log on to the instance.

Lastly, as with everything else in your architecture, make sure you build in redundancy for your bastion hosts to ensure that you do not lose access to your instances in case you lose the bastion host.

[2/3 9:22 AM] Melissa Sider

This post was originally published by CTR. CTR was acquired by AST in January 2023.