A bastion server, also known as a jump box, is a hardened server placed in a public subnet or DMZ to allow administrators to access other servers on the network remotely. Thanks to features introduced by Amazon Web Services (AWS), we no longer need bastion servers in our AWS architectures.
In September 2018, AWS introduced AWS Systems Manager Session Manager, which provides remote access to EC2 instances. Using this service eliminates the need for a bastion server to support the management of EC2 instances.
In March 2021, AWS introduced ECS Exec, which provides remote access to Elastic Container Services (ECS) containers. This feature leverages AWS Systems Manager Session Manager to create a secure channel between the device you use to initiate the exec command and the target container. It can be used, like docker exec, to execute commands within a running container, including Fargate. These commands could be anything available to the container. A possible use would be to establish an interactive terminal on the running container.
Not only does using Session Manager instead of a Bastion host simplify your infrastructure and reduce the number of servers, but it reduces your attack surface as well. To use Session Manager (and ECS Exec), you do not need to allow any ports from the internet to access your infrastructure. Your servers only need HTTPS (port 443) outbound access to the following 3 AWS services (with [region] replaced with your region of choice), which can be done through the internet or even with VPC endpoints:
ECS Exec uses the same AWS components that previously enabled the Systems Manager Session Manager capability. So, there are no additional connectivity requirements for ECS Exec.
Access to Systems Manager Session Manager and ECS Exec is granted, like all AWS services, through AWS IAM. The EC2 instances and ECS Tasks running require an IAM role, giving them access to the AWS Systems Manager services.
The EC2 IAM Role needs to be able to be assumed by ec2.amazonaws.com and requires the following permissions:
The ECS Task Role needs to be able to be assumed by ecs-tasks.amazonaws.com and requires the following permissions:
The users who will be using Systems Manager Session Manager to manage their EC2 instances will require the following permissions on the user or role they use to access the resources. Systems Manager Session Manager is available for use via the CLI and Web Console.
The users who will be using ECS Exec to connect to their ECS containers will require the following permissions on the user or role they use to access the resources. Note that ECS Exec is currently only available via the AWS CLI. AWS reports that it will be available in the AWS Management Console at a later time.
Your servers need to have the SSM agent installed to use Systems Manager Session Manager or ECS Exec. If you are using Fargate for your ECS containers, this is already taken care of by AWS. The most popular AMIs from AWS include the SSM agent. ECS Exec currently supports Linux Containers. There is nothing additional to be installed within the containers. The SSM agent is bind-mounted at container start.
To use the AWS Command Line Interface (AWS CLI) to connect to an instance with the session manager or ECS Exec, you must have the latest AWS CLI, and the Session Manager plugin (https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-install-plugin.html) installed on your workstation.
Connecting to an EC2 instance with session manager provides a terminal to that instance. Through the AWS CLI tooling, you can also establish a port forwarding session to use whichever local tools you would like on your laptop to interact with the EC2 instance.
In conclusion, I hope this high-level overview introduced you to some great features AWS has provided us that enable us to simplify and secure our infrastructure.