Are you tired of dealing with key pairs? Maybe tired of securing them with KeyPass? Or configuring SSH daemon for ease of use? Don’t worry, Systems Manager – Session Manager is here to save you from all these.
Session Manager is announced on 11 September 2018 with this blog post. Seriously, I remember being excited like potatoes thrown into hot oil. Because the process for connecting RDS Instances via Bastion Hosts were literal pain in our workplace. All those SSH private keys, security of them, jumping one from another for again, security reasons… All I can say is, it was taking long.
At this point, you might say, “Why aren’t you using a third party UI such as Bastillion EC2 for connecting Instances?” That’s because there are intermediate EC2 Instances involved with jump process. Complexity is already high, no need to increase it.
Now, you might also say, “But you know you can use a tool to add people’s IP to the security group of the Instances when they try to connect? Then let’s say, after 12 hours, you might remove the IPs from the security group.” For curious cats, it is explained in this Medium Story. That’s an option for sure, but I don’t like the idea of changing the state of a resource that much. Needlessly to say, we want immutable infrastructure in the end, right?
Now, let’s think about Session Manager solution. Session Manager is an EC2 Instance just like a Bastion Host, but the key difference is, you can access it from AWS Console and also with CLI API(However, I’m going to talk about the Console way). Imagine the possibilities. Another important difference is, it doesn’t require any ingress security group rules since you won’t be using SSH, in other words, your IP. Only an egress rule with 0.0.0.0/0 is needed if you want to download any package later on.
Now, the process is no-brainer after provisioning your EC2 Instance. You open your console, go to Systems Manager, click Session Manager tab, select your SSM Instance and voila! Now you can access every resource in your VPC as long as their security group allows your connection protocol and port. Let’s do a hands-on presentation!
Provision Session Manager Instance
- Select an AMI which has pre-installed SSM Agent. I choose ami-07f1aa69c7c7b01c9 since it satisfies my requirements. Notice that this AMI belongs to eu-central-1(Frankfurt).
- I choose t2.micro as Instance type since we are experimenting. On some operations, you might want to provision more powerful machines. These operations include, taking DB dumps, restoring DBs, data processing etc. which need more IOPS, CPU and network power.
- Next, we choose our VPC, private subnet and IAM role for the Instance. Role is important here, because without required permissions, you can’t start a session and each operation done in SSM Instance has its own permission, as you can guess.
- Now, I configure bootstrap script to set region to eu-central-1, install psql package, and upgrade awscli.
- Skipping volume step…
- Adding “Name” tag,
- Now, the best part. I only add one egress rule for Internet Access. Nothing else is needed. This allows better security than opening port 22 for SSH’ing your bastion.
- I don’t create or choose any key-pairs since this is only experiment and we shouldn’t need any keys to access our SSM Instance. Of course, you can create one if you want to.
Testing SSM Instance
As I mentioned before, open your console, go to Systems Manager, click Session Manager tab, click on Start Session, select our Instance “TestSSM” and click on Start Session again.
You should now see a shell inside your browser! Let’s try to connect to one of our PostgreSQL RDS Instances.
As you can see, you have your own secure, easy to configure, easy to use bastion at this point.
Monitoring and Auiditing SSM Bastion
At this point, you might ask, can I log who’s using this SSM Bastion and what they are doing? Of course you can. Under “Preferences” section in “Session Manager” tab, you can stream SSM Bastion’s activities to your specified CloudWatch Logs Stream or S3 Bucket.
References & Documentation: