Automating AWS Bastion Hosts with AWS CLI & Ansible

Introduction

In cloud environments, securing access to private networks is crucial. A Bastion Host serves as a controlled entry point for administrators to access instances within a private subnet securely. Instead of exposing all instances to the public internet, you configure a single bastion server to act as an intermediary, reducing attack surfaces.

Why Do We Need a Bastion Host?

A Bastion Host provides enhanced security by limiting SSH access to a single, well-protected instance. Without a bastion, administrators might have to expose multiple instances to the public internet, increasing the risk of unauthorized access or brute-force attacks. By funneling all remote access through a bastion, organizations can centralize security controls and monitoring.

Controlled access is another key benefit. Administrators can define strict access policies, allowing only certain trusted IPs or users to connect to the bastion. This ensures that only authorized personnel can reach private instances, significantly reducing the risk of intrusion.

Using a Bastion Host also helps to minimize the attack surface. Since only one instance is exposed, it becomes easier to harden and monitor that instance against potential threats. Security measures such as disabling root access, enforcing strong authentication methods, and using fail2ban can be implemented more effectively.

Additionally, a Bastion Host improves auditability. Since all access to internal resources goes through a single point, organizations can maintain better logs, track activity, and enforce compliance requirements. This can be particularly useful in regulated industries where access control and logging are mandatory.

Deploying the Bastion Host

We automate the deployment of a Bastion Host using an AWS CLI script, which performs the following:

First, the script creates a security group that allows SSH access only from a trusted IP address. Security groups act as virtual firewalls, restricting network access to only approved sources. By specifying a single trusted IP (such as an administrator's office or VPN IP), the attack surface is minimized.

Next, the script launches an EC2 instance using a specified AMI, instance type, and key pair. The AMI (Amazon Machine Image) defines the operating system and pre-installed software for the instance. The instance type determines the CPU, memory, and networking capabilities. The key pair is used for secure SSH authentication, ensuring that only authorized users can access the bastion.

After launching the instance, the script retrieves the public IP of the bastion server. This is the IP address that administrators will use to connect to the bastion via SSH. The script outputs this information so users can easily locate their new bastion host.

AWS CLI Deployment Script

#!/bin/bash

# Set AWS Region
AWS_REGION="us-east-1"
INSTANCE_TYPE="t3.micro"
AMI_ID="ami-0c55b159cbfafe1f0"  # Update based on your region
KEY_NAME="your-key-pair"  # Replace with your actual key pair
SECURITY_GROUP_NAME="bastion-sg"
ALLOWED_IP="YOUR_IP/32"  # Replace with your IP

# Create Security Group
SECURITY_GROUP_ID=$(aws ec2 create-security-group \
  --group-name $SECURITY_GROUP_NAME \
  --description "Allow SSH from trusted IPs" \
  --region $AWS_REGION \
  --query 'GroupId' --output text)

# Allow SSH Access
aws ec2 authorize-security-group-ingress \
  --group-id $SECURITY_GROUP_ID \
  --protocol tcp --port 22 --cidr $ALLOWED_IP \
  --region $AWS_REGION

# Launch EC2 Instance
INSTANCE_ID=$(aws ec2 run-instances \
  --image-id $AMI_ID \
  --instance-type $INSTANCE_TYPE \
  --key-name $KEY_NAME \
  --security-group-ids $SECURITY_GROUP_ID \
  --region $AWS_REGION \
  --query 'Instances[0].InstanceId' --output text)

# Wait for Instance to Start
aws ec2 wait instance-running --instance-ids $INSTANCE_ID --region $AWS_REGION

# Retrieve Public IP
INSTANCE_IP=$(aws ec2 describe-instances \
  --instance-ids $INSTANCE_ID \
  --query 'Reservations[0].Instances[0].PublicIpAddress' --output text --region $AWS_REGION)

echo "Bastion Host is running at: $INSTANCE_IP"

Example Output

Bastion Host is running at: 33.111.44.66

Securing the Bastion Host

Once deployed, we use Ansible to enforce security best practices. This involves installing critical security tools, disabling unnecessary access, and configuring security policies.

One of the first security measures is to install fail2ban, a tool that helps prevent brute-force attacks by banning IPs that exhibit suspicious login behavior. By doing so, we reduce the risk of automated attacks attempting to gain unauthorized access to the bastion.

Next, we disable root login over SSH. Allowing direct root access is a common security risk, as it provides attackers with a high-privilege entry point if they manage to guess the credentials. Instead, users should log in with a lower-privilege account and escalate their privileges when necessary.

We also set up an SSH banner to display a security warning upon login. This banner informs users that unauthorized access is prohibited and that activity is monitored. While this does not provide direct security benefits, it acts as a legal deterrent.

Ansible Playbook for Security Hardening

---
- name: Secure and Configure Bastion Host
  hosts: bastion
  become: yes

  tasks:
    - name: Install required security tools
      yum:
        name:
          - fail2ban
          - vim
        state: present

    - name: Disable root SSH login
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: "^PermitRootLogin"
        line: "PermitRootLogin no"
      notify: restart ssh

    - name: Set up an SSH banner
      copy:
        content: "Unauthorized access is prohibited!"
        dest: /etc/issue.net
        owner: root
        group: root
        mode: '0644'

    - name: Ensure banner is enabled in SSH
      lineinfile:
        path: /etc/ssh/sshd_config
        line: "Banner /etc/issue.net"
      notify: restart ssh

  handlers:
    - name: restart ssh
      service:
        name: sshd
        state: restarted

Complete GitHub Repository

Check the full code here

Conclusion

When to Use This Approach?

Using AWS CLI and Ansible is best for quick, flexible configurations without the need for complex infrastructure management. This approach is ideal for teams that want to deploy and secure a bastion host rapidly. On the other hand, although I am not too familiar with Terraform, I believe it is better suited for large-scale infrastructure deployments that require consistent state management and automation of multiple resources beyond just a bastion host.

Future Improvements

One possible improvement is enabling CloudWatch logging for SSH activity, which would enhance monitoring and security auditing. Another enhancement would be implementing IAM roles to allow for more granular access control without relying solely on SSH keys. Additionally, extending the solution to multiple AWS regions would improve availability and scalability.

With this automation, you can quickly set up a secure bastion host while maintaining flexibility and control.