5 secure ways to connect AWS resources

How you access AWS resources from on-premises also define your security posture and cloud security principles.

What is the best way to connect securely from on-premises OR local machine.

Few questions to ask yourself :-

• Are bastion host security groups wide open ?
• What if SSH RSA pub/priv keypair is leaked OR not rotated AND if key team member leaves your organization ?
• Do you need centralized SSH logs for auditing purposes ?
• Can you deploy it as a centralized solution for whole Organization ?
• Can you apply service control policy/ IAM policy and allow only specific users to get access via session manager.
• Do you want SSH login notifications based on security events ?

5 ways to connect to AWS resources securely :

1. Bastion host in public Subnet
2. Deploy on-premises jumphost and connect via IPSEC from on-premises (over internet OR Directconnect)
3. Session Manager (CLI and Browser based session)
4. Access via Serial Console
5. EC2 Connect

Bastion host in public Subnet :

If you have no connectivity back to on-premises from cloud (IPSEC or directconnect) and if we would like to access ec2/rds in private subnets from on-premises or local machine.

This is traditional way of connecting and have few caveats:

Cons:

• Publicly exposed Ec2 instance.
• Manage ec2 security groups whitelisting.
• Manage bastion host OS/Update security patches and make sure it’s highly available.
• Share pem files (public/private keypair) with team members.
• SSH logging needs to be exported to Cloudwatch/S3 bucket for analysis.

Pros:

• Easy to setup.

Source — AWS

Deploy on-premises jumphost and connect via IPSEC from on-premises (over internet OR Directconnect)

It’s a good practice to expose certain set of IP addresses from on-premises to cloud over port 22 and have all logs in centralized jumphost.

Pros:

• Centralized setup with private IP address only.
• Logging can be enabled for auditing purposes and forward to your local SIEM/logging solution.

Cons:

• Manage High Availability/OS/Security patches of jump hosts.
• You have to distribute ssh pem files with team to connect to compute etc.
• Manage ec2 security groups and allow on-premises jumphost.

Session Manager (CLI and Browser based session)

This is the best and recommended approach to connect to ec2 instances or use local port forwarding to access RDS or other AWS resources.

Pros:

• No need to distribute SSH RSA pem file to team members.
• No need to manage ingress security groups. Only egress to port 443 is needed.
• Logging session logs to Cloudwatch/S3 buckets.
• Monitoring session activity using AWS EventBridge for notifications.
• No need to manage additional virtual machines.
• One click access to managed nodes and browser based sessions also possible.
• Use IAM temporary credentials for login purposes.
• You can connect to multiple Operating systems using same tool (Windows/Linux/Mac).

Cons:

• You need to work on setting up session manager installation in your ec2 nodes and make sure IAM role attached to ec2 instance.
• Work on IAM or Service control policy to make sure only specific users should have access to ec2 instances.
• You need to fetch instance ID before login.

aws ec2 describe-instances --filters "Name=tag:Name,Values=test" --query "Reservations[].Instances[].InstanceId"

How-to-install (Steps):

• Pre-Requisite :
• SSM agent installation steps : https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-prerequisites.html
• IAM Role attachment to EC2 instance → AmazonSSMManagedInstanceCore
• Allow Port 443 outbound for HTTPS
• Setup Privatelink to setup VPC endpoint for session manager so that traffic remains local. https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started-privatelink.html
• Install AWS CLI —> https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html
• Session manager installation ( on your local )→ https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-install-plugin.html

Login to ec2 instance:

# aws ssm start-session - target <instance-ID>

Local Port Forwarding example (Remote port is 443 and local port is 56789):

aws ssm start-session \
— target instance-id \
— document-name AWS-StartPortForwardingSession \
— parameters ‘{“portNumber”:[“443”], “localPortNumber”:[“56789”]}’ — region <region-name>

How-it-works:

Session Manager:

Source — AWS

Port forwarding :

AWS

Access via Serial Console

You can also access ec2 via serial console.

Cons:

• Only certain ec2 instance types allowed.
• You need to create system user beforehand as login via serial console is combination of username + password.

EC2 connect

Amazon EC2 Instance Connect is a simple and secure way to connect to your instances using Secure Shell (SSH). It’s primarily meant for public ec2 instances.

Cons:

• Does need security groups ingress whitelisting for IP/Port 22.

Pros:

• You can also connect via browser based sessions.
• You just need to specify username to connect it.
• Logs all SSH activities in cloudtrail.

In general, ec2 instances should not be deployed in public subnets with port 22 access (unless there is some edge case/ business use-case).

Recommendations

My recommendation is to use Session Manager (CLI and Browser based session) . It’s a safe way to connect resources, ssh tunneling and also without pem keys distribution with authz/authn at AWS SSO level.

Also, you can connect private instances directly (without IPSEC or Directconnect) and enable logs to centralized S3 bucket for auditing purposes.

If this post was helpful, please click the clap 👏 button below a few times to show your support for the author 👇