The Power of AWS Session Manager (SSM) with EC2 Instances

re you looking for an alternative method for connecting to your EC2 instances within AWS? Are you tired of manipulating your security group rules to restrict SSH connectivity to your EC2 instances for security purposes? If so, you’ve found the right article to help you solve these issues.

In this blog post, we’ll discuss leveraging the AWS Systems Manager (SSM) Session Manager to connect securely to any EC2 instances within your account.

What is AWS Systems Manager?

AWS Systems Manager (SSM) is a secure end-to-end management solution for resources within AWS and multi-cloud and hybrid environments. The beautiful thing about this service is its extensibility and the number of features it provides. Within AWS, you can create logical groups of resources such as applications, different layers of an application stack, or production versus development environments. You can also select a resource group and view its recent API activity, resource configuration changes, related notifications, operational alerts, software inventory, and patch compliance status from a central place within AWS.

For more information about the list of features for SSM, feel free to visit: https://aws.amazon.com/systems-manager/features/

Session Manager Explained

I know you’re probably asking, what exactly is SSM Session Manager? Session Manager allows you to manage your EC2 instances, virtual machines (VMs), and other devices or servers via the command line locally or within the AWS Console. The Session Manager provides a safe and secure way of interacting with our instances. And it does it beautifully without any need to modify security groups or to maintain SSH keys or bastion hosts. (Session Manager User Guide)

From an operational standpoint, Session Manager eliminates the overhead of managing network-level access and restrictions on each node. If you have a large fleet of instances or servers, you can easily set up Session Manager for each EC2 instance to manage the access control and access from a single location (console or CLI). It makes our life a bit easier, don’t you agree?

Using Session Manager with EC2 Instances

With this fundamental understanding of Session Manager, let’s walk through an example of setting up a Session Manager on an EC2 instance.

In this account, DigitalForensicsAccount-912, a forensic investigator would like to leverage Session Manager to perform some analysis on the newly designated server AssetAnalysisServer. As the number of investigators grows, they’ll want to create new instances in this account that leverage Session Manager.

So, the question is, how exactly do we enable SSM for this single EC2 instance? Also, how can we ensure that this approach scales moving forward? Well, there is a straightforward approach that I will discuss with you that will simplify configuring Session Manager in the future.

Step 1: Install the SSM Agent

If you have an EC2 instance configured, you will want to install the SSM agent. The SSM agent allows the EC2 instance to communicate with the service within the AWS console. In this particular case, the AssetAnalysisServer will be using a Linux AMI.

Use the below command to install the agent:

# x86_64 Linux Command
$ sudo yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm

# ARM64
sudo yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_arm64/amazon-ssm-agent.rpm

Once you’ve installed it, ensure that the agent is in an active state. You can verify it using the Linux command highlighted below:

$ sudo systemctl status amazon-ssm-agent

If it hasn't been started or enabled, enabled it with this command:

$ sudo systemctl start amazon-ssm-agent

If you’d like to install the agent on any other supported OS within AWS, please look at the installation documentation: https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-manual-agent-install.html

Note:If you’re using Amazon Linux 2 or 3, the agent is installed by default.

Step 2: Create a service role with SSM Permissions

It is the most significant and often overlooked step. For the SSM agent on the EC2 instance to communicate with SSM, create an IAM role with the correct permissions.

In this case, you must log into the AWS console and create a new service role that the AmazonSSMManagedInstanceCore managed policy attached to it. Since it is an EC2 instance service role, ensure that your trust policy allows EC2 service access to assume it. Here is an example of the IAM role for the AssetAnalysisServer:

Service Role Trust Policy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "ec2.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

Step 3: Attach this role to the EC2 Instance IAM Profile

Now that you’ve created the IAM role, attach the IAM role to the EC2 instance. If you’re a console person, navigate to the EC2 Instances dashboard, highlight the instance, and click on the following:

Actions > Security > Modify IAM Role

Once you’ve done that, click the dropdown menu, find your role, click it, and then finalize the change by clicking the button “Update IAM role”.

Step 4: Test the Session via the CLI (because it’s better)

Now that you’ve attached the modified instance profile to use the IAM role for SSM, try and connect to the instance using Session Manager using the CLI. To do so, open a terminal and enter the command below (assuming you’re on a Linux machine):

$ aws ssm start-session --target instance_id --reason “testing ssm”

Note: If you haven’t already, be sure to install the SessionManagerPlugin on your local, as it is a requirement to use the terminal or CLI to connect to the node via SSM. You can follow the instructions located here: https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-install-plugin.html

Once you’ve entered the modified command and executed it, your terminal should have changed a bit. An example of this is highlighted below:

$ aws ssm start-session --target i-03f2d862272bc78db --reason “testing ssm”

Starting session with SessionId: damien-07a461d54b7160527
sh-5.2$ bash
[ssm-user@ip-172-31-84-176 bin]$

We have followed all the steps necessary to connect AssetAnalysisServer to the SSM Session Manager.

If you take a look at the diagram above, we can see that the AssetAnalysisServer’s instance profile is associated with the ec2-ssm-service-role IAM resource, which has the AmazonSSMManagedInstanceCore managed policy attached to it. Since we’re using the Linux AMI, there wasn’t a need to install the SSM agent onto the system. As a result, the investigator was able to connect to the instance via SSM.

If you wish to scale this to multiple instances within a single region, the easiest way to go about this is to:

1. Attach the existing role (ec2-ssm-service-role) to the newly created instance profile.
2. Ensure that the SSM agent is installed, updated, and running. Best way is to, always use the latest Amazon Linux AMI.

Benefits of using Session Manager

Now that we’ve covered how to leverage Session Manager with our EC2 instances, let’s discuss its benefits.

1. Improved Node (Instance) Security

We don’t have to worry about exposing our instances to the internet or opening ports like port 22 (ssh), which prevents the node from being compromised. In addition, you can customize the session to restrict privileged access with root through the SSM agent.

2. Managed access with IAM policies

Because you have to have IAM service roles attached to the instance, it allows the administrator to customize permissions for each user. A great example of this is enforcing multi-factor authentication for each session and restricting sessions based on instance names, tags, and IDs.

3. Centralized Logging and Monitoring

All of the instance activity is logged via CloudTrail and CloudWatch. The SSM agent is essentially responsible for tracking all of the behavior on the instance. It includes commands that have been executed (as root or not) and the duration of the session. For more information about logging and monitoring, visit this link: https://docs.aws.amazon.com/systems-manager/latest/userguide/logging-and-monitoring.html

Conclusion

Simply put, this is the power of the Session Manager. If you’re using SSH keys and manually manipulating your security groups for your instances, consider migrating over to leveraging Session Manager. This service can be set up to simplify instance management in a scalable way with centralized logging and monitoring, IAM service roles and policies, and several other features that I may not have mentioned in this blog post (compliance, resilience, fault-tolerance, etc..).

If you follow the steps for setting it up, you too could witness the power of the Session Manager firsthand. Cheers!

References:

https://aws.amazon.com/systems-manager/

https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html