A Bastion Host (also known as a "Jump Server" or "Jump Box") is a special-purpose EC2 instance designed to be the primary access point for a private network. It acts as a secure gateway that allows you to connect to your private instances (like database servers) without exposing them to the public internet.
In a secure cloud architecture, your backend servers should never have public IP addresses. But how do you SSH into them to run updates or check logs? You "jump" through the Bastion Host.
Architecture: How It Works
The architecture relies on the separation of Public and Private subnets.
1. Public Subnet: The Bastion Host lives here. It has a Public IP address and is reachable from the internet (restricted to your IP).
2. Private Subnet: Your application and database servers live here. They have only private IP addresses. They cannot be reached directly from the internet.
3. The Flow:
- You SSH into the Bastion Host (Public).
- From the Bastion Host, you SSH into the Private Instance (Private).
Why Use a Bastion Host?
- Security: It reduces the "attack surface." Instead of protecting 50 servers from the internet, you only need to harden and protect ONE server (the Bastion).
- Logging: It provides a central point for logging access. You can track exactly who logged in and when.
- Network Isolation: It allows you to keep your critical workloads in private subnets, meeting compliance requirements (HIPAA, PCI-DSS).
How Bastion host work?
Bastion host basically provides an entry point into the private networks, which are to be connected to the external network, securing them from attacks. A bastion host has both internal and external IP addresses. If users want to connect the internal instance without using external IP addresses, then they can connect to a Bastion host and then connect to your internal instances from that Bastion host. While using the Bastion service, you have to log in first to your Bastion host and then be directed to the private instances. The following diagram can explain how it actually works.
The Following describes the architecture of the Bastion host. If the users have preexisting AWS infrastructure it becomes easier to deploy the Bastion host.
- There is a requirement of a VPC configured which have both public and private subnets which provide users with their own virtual network on the AWS infrastructure.
- There is a requirement of a gateway that acts as a bridge for access of internet. It allows the bastion host to receive and send the traffic of the private network.
- An architecture that can span up to two availability zones.
- There is a need for a cluster of Amazon EC2 auto-scaling instances.
- There will be a requirement of the number of the elastic IP addresses to match the number of bastion host instances.
- Amazon Cloudwatch will also be required in order to store the history of the bastion host shell logs.
- Security groups play a vital role in maintaining the security and look upon the factor that the bastion host doesn't fail at all. Security groups are created so that it allows the users to connect the bastion host to the private instances.
Setting Up a Bastion Host (Best Practices)
Setting up a bastion is more than just launching an EC2 instance. You must configure it securely.
1. Security Group Rules
- Bastion SG: Inbound: Allow SSH (Port 22) ONLY from your specific IP address (e.g., 203.0.113.5/32). Never allow 0.0.0.0/0.
- Private Instance SG: Allow SSH (Port 22) ONLY from the Bastion Security Group ID. This ensures that only the Bastion can talk to your private servers.
2. SSH Agent Forwarding (The "Secret Sauce")
Problem: You need your private key (my-key.pem) to log into the private instance. But you should NEVER copy your private key to the Bastion Host. If the Bastion is compromised, your key is stolen.
Solution: Use SSH Agent Forwarding. This allows the Bastion to "pass through" your local credentials without storing the key on the server.
Must Read