For security reasons you should not have your aws resources (e.g. ec2 instances) directly accessible via the internet unless it is necessary, i.e. keep your aws resources internal. However you still want to be able to access your VPCs, there’s a few ways to achieve this:
AnnouncementI have released my new course on Udemy, Kubernetes By Example. Sign up now to get free lifetime access!
- Setup bastion hosts
- setup vpn – covered later
- set up AWS Direct Connect – covered later
- A combination of the above.
A “bastion host” is a general concept and isn’t something specific to AWS. A bastion host is essentially an EC2 instance that sits inside a public subnet, which in turn resides inside a vpc. You can ssh into all the other ec2 instances inside this vpc, by first ssh’ing into the bastion host (since by design, all ec2 instances inside a vpc can communicate with each other via their internal ip’s irrespective of which public/private subnet they belong to).
A bastion host has the following characteristics:
- it resides inside a public subnet, therefore your vpc needs to contain at least one public subnet in order to have a bastion host.
- bastion host is configured with extra security at the os level, e.g. it has selinux enabled, it has firewalld running
- bastion host should only be configured to have the sshd service listening, best practice is to reconfigure away from default port 22, to another obscure port number. All other ports should be closed.
- Should have it’s own AWS security group which denies traffic on all ports apart from the port that ssh is listening on. This security group should also restrict source IP addresses to the range of your on-premise network.
- It should store any private ssh keys, instead you use ssh forwarding to seamlessly pass through the bastion host.
Also remember, after restarting your mac, and when you open up a new bash terminal, do:
a. $ ssh-add -l
b. $ ssh-add ~/.ssh/private.pem