Resources referenced within this lecture:

SSH Agent Forwarding

Transcript

In this section, I want to talk to you about bastion hosts. Now, consider a scenario where you might have EC2 instances sitting in a private subnet, but you want to be able to gain access to those instances from maybe your home office or from somewhere else on the internet. But because they're sitting in the private subnet, how can you do that? Well, one of the ways you can do this is via a bastion host. 

So let's draw out our VPC configuration to allow me to explain how this works. So here, we have our VPC. We're going to have a public subnet and we'll also have a private subnet as well. So this will be our public and this green one here will be our private. Now, obviously, we have an internet gateway attached as we have a public subnet, our IGW, and this connects out to the internet. We also have routes added to allow the subnets to talk to each other and also the public subnet to route out to the internet gateway as well. 

Now, also, in the outside world, we have an engineer. Now, this engineer might be sitting at home in their home office in front of their laptop and what they need to do is to connect to resources sitting within the private subnet over here. Now, in this private subnet, we're going to have a couple of EC2 instances. Now, we know it's not possible to initiate an outside request to connect through to the internet down through to the internet gateway of our VPC and then across to our private subnet. It's not possible. There aren't routes to enable us to do that. Access isn't allowed and it is private by design. 

However, this engineer here needs to gain access to the EC2 instances to perform some maintenance or updates to those resources. Now, to enable you to do this, you need to use a bastion host. Now, this bastion host sits within the public subnet and this is just another EC2 instance. Now, this instance, to follow best practices, needs to be very secure. It needs to be hardened and very robust, but effectively, it needs to be tightened down to remove any kind of vulnerabilities and loose access controls. 

Now, this EC2 instance is a part of a security group and this security group needs to be configured as shown. Now, what this security group shows is the inbound connectivity, and it allows SSH on port 22 from this IP address, which is from the engineer's IP. So it's being configured for this engineer over here. So this bastion host will essentially allow an SSH connection coming from our engineer over here. Now, that's great because this engineer can then gain access to the bastion host here. And then, what that engineer can do is then use this as like a jump server and connect from the bastion host through to our EC2 instances here. 

But before any of that can happen, we need to set up another security group for our EC2 instances here. So we'll have another security group around our EC2 instances and this will be configured as shown. Again, this is the inbound rule set, and we can see that SSH is allowed on port 22 from this source here. Now, this source is actually a security group. It is prefixed with sg, which is security group, and this security group is actually this one here. This is associated with the bastion host. So what this is saying is any instances associated to this security group allow inbound SSH from any resource sitting within this security group, which as we know, is associated to our bastion host. So that will just allow the bastion host SSH access to these instances. 

So now, we have our security groups set up and configured. However, let me just talk you through the connection process. So our engineer here will connect to our bastion host. Now, the engineer will be able to access the bastion host using the private key. So let's just follow this process through. So the engineer will SSH to our bastion host, so it'll connect via the internet. The connection will then come through the internet gateway. Let's assume that any net calls that we have allow the access and we come to the security group here. Now, this security group says, allow connection if it's an SSH connection from this IP address and this is the IP address of our engineer over here. So it allows access through. So now, this engineer has access to our bastion host. But now, our engineer needs to jump across to our private instances. Now, again, we're going to need a private key to do that. 

Now, one method would be to store the private keys on this bastion host and then run the command to SSH and access would be allowed, but that's not best practice at all. We really don't want to be installing private keys within the public subnet or on the bastion host because if this bastion host ever got compromised, then the malicious user will be able to use any private keys that are stored on the bastion host and connect to our private instances, which would be very bad. So how does this engineer SSH into our EC2 instances if he doesn't have the private key? 

Now, the best way to do this is to set up something called SSH agent forwarding. Now, what this allows us you to do is to store the private keys for the instances within the private subnet on your local client, so that when you connect through to the bastion host, you can then SSH, but using the private key to the EC2 instances that is stored on your client rather than storing it on the bastion host. Now, with that in mind, once you have connected to your bastion host, using the example that I just showed you, you can then SSH into your private instances, at which point, it will hit the private security group that allows any SSH access on port 22 from the security group associated with the bastion host and then there, you can gain access. 

So just to summarize exactly what we've done here. We started off by creating an EC2 instance within the public subnet marked as our bastion host. We then hardened that instance to try and protect it against as many security threats as possible and to lock down access to that instance. We then associated a security group that only allowed SSH inbound access from a particular IP address or a particular range of IP addresses. We then added a rule to the security group associated to our private instances that allowed SSH inbound access from the bastion host security group. You then need to ensure that SSH agent forwarding is configured on your client and then this allows you to firstly connect to your bastion host using the private key of the bastion host and then using that as the jump server to jump into your private subnet from your bastion host using the private instances, private key, which is also stored on your client PC. 

In the next section, I'm going to be coming away from the security aspects of VPC's list and I'm going to be focusing more on VPC connectivity.