AWS Snap Bastion

AWS recommends minimizing persistent access to your environments. Yet, engineers still need secure pathways to reach resources in private networks for their daily tasks. AWS Systems Manager Session Manager provides a secure way to connect to EC2 instances, however there are still scenarios where additional access solutions are required.

You might find yourself in one of these scenarios if you need to connect to a private endpoint from your local workstation. A private database is a common example, or if you need to hit a private API or if you need access to a vendor appliance with no SSM agent. For these scenarios, we usually appeal to our good and old bastion hosts.

While traditional bastion hosts have well served this purpose, their long-lived nature introduces security risks that can compromise the very environments they're designed to protect.

In this post, we introduce AWS Snap Bastion, an ephemeral bastion solution that provides secure, just-in-time access to private AWS resources, eliminating the risks of static jump servers.

The challenge with traditional bastion hosts

Traditional bastion hosts come with a bunch of security and operational headaches:

• Expanded attack surface: A permanently running bastion host presents a constant target for malicious actors.

• Credential management risks: Persistent hosts often accumulate SSH keys, access tokens, or other long-lived credentials.

• Maintenance overhead: Keeping static bastion hosts patched and compliant takes a lot of work. Configuration drift over time can lead to security gaps and vulnerabilities.

• Cost inefficiency: Running bastion hosts 24/7 incurs unnecessary costs when access is only needed intermittently.

Ephemeral bastion solution overview

Our AWS Snap Bastion solution provides the following benefits:

• Just-in-time access: Bastion hosts are created on demand and automatically terminated after use, minimizing the window of exposure.

• Identity-based authentication: The solution integrates with AWS IAM, eliminating the need to manage SSH keys.

• Comprehensive audit trail: All access requests and session activities are logged for compliance and security monitoring.

• Reduced attack surface: With no persistent instances, there are no static targets for attackers to probe or compromise.

• Cost optimization: You only pay for compute resources when they're actually being used for access.

• Standardized configuration: Each bastion instance is provisioned from an immutable template, ensuring consistent security controls and eliminating configuration drift.

Here's how it works:

1. An authorized user initiates the creation of an ephemeral bastion through a client-side script.

2. A temporary EC2 instance is provisioned in your VPC using Amazon Linux 2023 most recent AMI.

3. The user connects to the bastion through SSM Session Manager.

4. The bastion continuously monitors for activity and automatically shuts down after a period of inactivity.

The Client-Side Interface

A key component of this solution is the client-side Bash script that provides engineers with a simple, interactive interface to request and connect to ephemeral bastion hosts. This script handles everything from checking dependencies and parsing user input to invoke the SSM Automation document, wait until the bastion is ready and establishing the connection.

The main use case that drove the development of this solution was the ability to connect to private databases, so the script will look for RDS databases in your account and allow you to select one to connect to if you have any. However, you can still manually provide a private endpoint.

In the above example, I'm connecting to an internal ALB after the bastion creation process is completed. Notice we have the following comment in the script output:

Ensure Security Group attached to your remote target (e.g.: RDS, ALB) allows connection from the 'Ephemeral Bastion Security Group'

This is crucial step required to allow connectivity to your target from the ephemeral bastion.

How Port Forwarding works

AWS offers a SSM Automation Document that takes care of establishing a secure tunnel to the remote target: AWS-StartPortForwardingSessionToRemoteHost

StartEphemeralBastion SSM Automation Document

At the heart of this solution is a Systems Manager Automation document named StartEphemeralBastion. This document accepts parameters such as the instance type, VPC ID, subnet ID, and the identity of the requester. When invoked, it creates a temporary EC2 instance configured as a bastion host.

Let's walk through the key components of this SSM Automation document:

Input Parameters

• AutomationAssumeRole: The IAM role that allows Systems Manager to perform actions on behalf of the user

• InstanceType: The EC2 instance type to use for the bastion (default: t4g.micro)

• VPCId: The target VPC where the bastion will be deployed

• SubnetId: The subnet where the bastion will be deployed

• Invoker: The identity of the user requesting access

Main Automation Step

The document contains a single step named CreateInstance which executes a Python script performing the following:

1. Check if a bastion already exists for the invoker in the specified VPC

2. Create a security group for the bastion if one doesn't already exist

3. Launch an EC2 instance with appropriate tags and configuration

4. Wait for the instance to become ready and the SSM Agent to come online

Instance Configuration

The script configures the EC2 instance with a user data script that:

1. Updates the system packages

2. Creates a monitoring script that checks for idle sessions

3. Configures a systemd timer to run the monitoring script every 15 minutes

Auto-termination Logic

One of the most important security aspects of this solution is the automatic termination of idle instances. The bastion host includes a script that:

1. Checks for active SSM sessions to the instance

2. If no active sessions exist, checks when the last session ended

3. If the last session ended more than 90 minutes ago, the instance shuts itself down

4. The instance termination policy then ensures the EC2 is terminated after shutdown

Try it out yourself!

All the code and instructions are available on this GitHub repository

Conclusion

Ephemeral bastion hosts represent a significant improvement over traditional long-lived bastion servers. By creating just-in-time access paths that exist only while actively needed, you can dramatically reduce your attack surface while maintaining the operational capabilities your teams require.

This solution demonstrates how AWS services like Systems Manager and EC2 can be combined to implement security best practices in an automated, reliable, and cost-effective way. The ephemeral nature of these bastion hosts aligns with Zero Trust principles and modern cloud security practices, providing access only when necessary while maintaining comprehensive audit trails.

By implementing this solution, you can eliminate the security risks and maintenance overhead associated with permanent bastion hosts, while still providing secure access paths to your private resources.

Have feedback or ideas to improve AWS Snap Bastion? Open an issue or contribute on GitHub!