Want to Make AWS Less Secure? Keep Ignoring Session Manager!

What Problem Are We Solving?

How often have you come across a security group with port 22 open to a broad range like 10.0.0.0/8 or even the infamous 0.0.0.0/0? If you’ve been around AWS setups, it’s probably too many times! But seriously, why are we still relying on SSH in 2024 when there are far better alternatives available?

As a security professional, I’ve spent countless hours advocating for more secure ways of working. Honestly, I often meet resistance. Why? Because people love shortcuts—quick and easy methods to get the job done. And hey, I can’t blame them! But the reality is that with the growing number of security breaches and incidents, we must adopt workflows where security is baked in by design.

The problem doesn’t end there. Watch a few tech tutorials on YouTube, and you’ll see examples of public-facing EC2 instances configured with SSH access limited to "My IP." While this is understandable for demonstration purposes, developers often internalize this as the only way to work with EC2 instances. When security teams propose more secure alternatives, resistance is almost inevitable.

So, how do we provide secure access to EC2 instances without using key pairs, public IPs, or poorly configured security groups, all while enhancing logging and improving security?

The answer lies in AWS Systems Manager and its powerful feature, Session Manager.

What Is AWS Systems Manager (SSM)?

AWS Systems Manager serves as the central hub for managing your AWS applications and resources, offering a secure and scalable solution for hybrid and multi-cloud environments.

Here are just a few features it provides:

What Is Session Manager?

Session Manager allows you to securely connect to EC2 instances through a one-click browser-based shell or the AWS CLI. It eliminates the need for inbound ports, bastion hosts, or managing SSH keys, while offering centralized, auditable, and secure node management.

Session Manager is not only convenient but also meets strict security and compliance requirements. With it, you can log and audit every session, ensuring complete visibility into activities performed on your EC2 instances.

Why Use Session Manager Instead of SSH?

Here’s why Session Manager outshines traditional SSH:

1. Centralized access control: Use IAM policies to manage permissions.

2. No open inbound ports: Eliminate the need for port 22 or 3389.

3. No SSH key management: Avoid the hassle of distributing and rotating SSH keys.

4. Enhanced logging and auditing: Record session activity in CloudTrail, CloudWatch, or S3.

The logging capabilities deserve special mention:

• Activity auditing: Sessions are logged in CloudTrail, enabling consistent activity auditing alongside other AWS services.

• Keystroke logging: All commands entered during a session can be captured and stored in CloudWatch or S3. This is particularly useful for meeting regulatory requirements or investigating security incidents.

High-Level Architectural Overview

Let’s look at a secure architecture for managing EC2 instances in a multi-account environment without relying on SSH:

Key Components:

1. Logging Account: A centralized account for storing logs in S3 and CloudWatch, with data encrypted using a KMS key.

2. VPC Endpoints: Configured in each workload account to ensure traffic remains internal to AWS.

3. EC2 Instances: Instances configured with an IAM profile to send logs to CloudWatch and S3 securely.

4. Session Manager Preferences: Centralized configuration for consistent logging to the appropriate destinations.

5. SIEM Integration (optional): Logs can be ingested into a Security Information and Event Management (SIEM) system for advanced threat detection and analysis.

Architectural Diagram:

Here’s an overview:

• EC2 instances in workload accounts send logs via VPC endpoints to centralized CloudWatch and S3 in the logging account.

• S3 and CloudWatch are encrypted using KMS keys for added security.

Pre-Requisites for Session Recordings

To set this up:

1. Use an AMI with the SSM agent pre-installed (e.g., Amazon Linux 2023).

2. Configure Systems Manager following the AWS guide.

3. Set up the necessary VPC endpoints for ec2messages, ssm, ssmmessages, kms, logs, and s3.

Terraform Configuration

Here’s how you can configure this setup using Terraform:

Creating the EC2 Instance

resource "aws_instance" "ssm_recording_example" {
  ami                    = data.aws_ami.amazon_linux_2023.id
  instance_type          = "t2.micro"
  iam_instance_profile   = aws_iam_instance_profile.ec2_ssm_instance_profile.name
  subnet_id              = data.aws_subnet.subnet.id
  vpc_security_group_ids = [aws_security_group.session_manager_security_group.id]

  metadata_options {
    http_endpoint               = "enabled"
    http_tokens                 = "required"
    http_put_response_hop_limit = 1
  }

  tags = {
    Name        = "Session Manager Demo"
    Environment = "Development"
  }
}

Setting Up Security Groups

resource "aws_security_group" "session_manager_security_group" {
  name        = "Session Manager Security Group"
  description = "No inbound ports"
  vpc_id      = data.aws_vpc.main.id

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

IAM Role and Instance Profile

resource "aws_iam_role" "ec2_ssm_role" {
  name = "ec2_ssm_role"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Principal = { Service = "ec2.amazonaws.com" }
        Action = "sts:AssumeRole"
      }
    ]
  })
}

KMS Key for Log Encryption

resource "aws_kms_key" "log_key" {
  description         = "KMS key for log encryption"
  enable_key_rotation = true
}

S3 Bucket for Logs

resource "aws_s3_bucket" "log_bucket" {
  bucket = var.bucket_name
}

resource "aws_s3_bucket_versioning" "log_bucket_versioning" {
  bucket = aws_s3_bucket.log_bucket.id
  versioning_configuration {
    status = "Enabled"
  }
}

Variables

Variables here are the name of the bucket, the organization ID, the account ID and the region. Some or perhaps all of these may not be needed in your terraform, depending on what is already in your terraform state. Similarly, you may choose to use alternative methods to input these values, to make the code more re-usable e.g. CI Pipeline variables.

When working with Terraform, variables play a crucial role in making your code flexible and reusable. Key variables you might encounter in AWS configurations include the bucket name, organization ID, account ID, and region. These values are foundational to setting up resources correctly and ensuring consistency across your deployments. However, depending on how your Terraform state is already structured, you may not need to explicitly define all of these variables. For instance, some values might already be pre-configured or available through your existing Terraform setup.

To enhance reusability and streamline processes, you can explore alternative methods for passing these variables. A great example is integrating them into your CI/CD pipeline as environment variables. This approach centralizes your configuration, reduces the risk of hardcoding sensitive information into your codebase, and makes it easier to adjust values without editing your Terraform files directly. It’s especially helpful when you have a team working across multiple environments, as it ensures consistency and reduces the chance of misconfigurations.

Drawing from AWS's secure practices, it’s essential to pair this approach with robust guardrails like Service Control Policies (SCPs) and permission boundaries. These guardrails help enforce compliance and ensure that only approved configurations are deployed. For example, using variables dynamically sourced from pipelines makes it easier to ensure that resources like EC2 instances always comply with predefined security requirements, such as having the correct IAM roles for Systems Manager.

Final Thoughts

Session Manager isn’t just a better alternative to SSH—it’s a secure, auditable, and scalable solution for managing EC2 instances. By leveraging tools like Terraform to automate your setup, you can ensure your architecture is not only secure but also developer-friendly.

One thing to keep in mind—this approach assumes your environment already has a solid foundation of consistency and guardrails. If you allow developers to spin up EC2 instances without the correct IAM roles, Systems Manager simply won’t function. To make it work, you’ll need to enforce controls like permission boundaries or Service Control Policies (SCPs) to ensure compliance. Without these in place, things can get messy fast.

You might even consider taking it a step further with Infrastructure as Code (IaC) scans. These can help catch non-compliant configurations before they’re deployed, ensuring that the necessary prerequisites for secure access are met from the start. With the right guardrails, tools like Session Manager become not just a convenience but a game-changing way to improve security without compromising workflow efficiency. Isn’t it time we moved away from open port 22 and embraced the future of secure AWS management?