AWS Service of the Week – SSM
Hello! I’m back again with another instalment of AWS services blog, and today I’d like to share with you SSM or its full name (which needs a rebrand IMO) of AWS Systems Manager Session Manager.
This is an amazing service which enables connectivity to EC2 instances or on-premises instances of Linux or Windows OS varieties, using your AWS IAM credentials, without the need to manage any SSH keys, Bastion Hosts, or inbound security group rules.
Let’s take a quick look at why this service came about before diving into the detail!
Historically most connections to AWS instances would have been through SSH (Linux), or RDP (Windows).
This had been a tried and tested method for many years for connectivity, but there are issues and concerns with these approaches. One issue is that there have been situations where a security group rule attached to an instance is too open and allows for brute force attacks.
The rule Port 22 (SSH) or Port 3389 (RDP), TCP, inbound, 0.0.0.0/0, means that anyone globally can see the instance and try to send traffic to it, this is not good practice, and is strongly discouraged! Another issue is the management of the SSH keys or passwords, and how you rotate these to restrict people that should no longer have access to those systems.
This is where SSM can be utilised.
SSM can be used on the command line (with the AWS plugin installed), and on the face of it works much in the same as SSH.
If I wanted to run the Linux command ‘ls -ll’ to list my current directory, I would connect to the instance with an ‘aws ssm start-session –target
Under the hood it is a different story, and for SSM to function correctly, we need a number of items setup.
The SSM Agent needs to be installed on the instance, an IAM instance profile set up with SSM permissions, and attached to the instance, and the instance security group needs to allow outbound HTTPS connections, as SSM uses this protocol for its communication with your command line.
Note you can also use SSM with instances on premise, or in private subnets, but there a few more setup stages to complete the task
So, can anyone access my Instances in AWS?
Assuming you do not have administrator access to AWS, you should create a policy to allow view, start, and terminate session actions on SSM, and attach this policy to the roles which you want the teams to have access too!
For example, the developer team have a role called developer. This means that any AWS user that can assume the role developer can access with SSM the instance.
However, you can take this one step further if you have many teams and use tagging conditions with SSM, for further control over access. I have seen projects use this method to great effect in the past, where you create a SSM policy per team, which gives them the access to view, start, and terminate sessions on the condition that the instance has a corresponding Tag that can be referenced against.
This is a far greater security aware approach which disables any user with the actions to access my instances via SSM
So, can I audit these interactions?
You most certainly can have an audit trail of every single session that was attempted, failed, and succeed to an instance, and have that sessions commands stored in S3
So, how can I add files to SSM from my local machine to the instance?
For a long time, the easiest option was to have a temporary S3 bucket and push object(s) to that, then from within the SSM session on the instance get the object(s) using the aws cli.
That is still an option, but SSM have recently announced support for the SCP (Secure Copy Protocol) which looks promising, and with agent being opensource you can get insiders information to all the latest updates coming from the community
Thanks again for reading along, and I hope you have seen the benefits that SSM can bring you including reducing bastion host cost overheads, administration of SSH keys, and utilising your IAM credentials to access instances. If you want more information, please don’t hesitate to get in touch