Connect to AWS RDS Securely Without SSH Keys
Raise your hand if you're already having trouble connecting to a remote database running in a Private Subnet. In almost every company, you will probably need to speak with the SysAdmin, share your SSH key to be inserted inside the bastion host machine, granting to you the permission to have the tunnel working and connect directly from your machine.
This article will help you to get rid of this problematic implementation and demonstrates how to have access over SSH in an EC2 Bastion instance having no previous SSH key installed on it, no ports opened and even no public IP address configured, using the AWS Systems Manager Agent.
Considering that you already have your Database and Private Subnet created, here is what we are going to use:
An EC2 instance using Amazon Linux as AMI. The Amazon Linux already came with the AWS SSM Client installed on it and we are going to need it. You should use another AMI but knowing that you will need to handle the agent installation. Besides it we need to guarantee that the InstanceProfile has permission to assume arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore policy role;
Create an IAM User with ssm:StartSession, ec2-instance-connect:SendSSHPublicKey and ec2:DescribeInstances permissions. We are going to output the Access and Secret Key value of this user to the SLS Pro Dashboard;
4x VPC Endpoints
As we are dealing with a Private Subnet, we are going to need 4 VPC's endpoints configured to make it work as expected. 3 of this endpoints have the type Interface powered by AWS PrivateLink. Creating Interface endpoints incurs additional costs and you can check the pricing here;
The last thing we should have is a exclusive Route Table configured for this service, associated to the same Private Subnet that we have the database running.
How it works
We are going to generate a temporary SSH key and inject it to the Bastion instance with the help of Amazon EC2 Instance Connect. And then for connecting the instance, we'll use AWS Systems Session Manager configuring SSH client with a specific proxy command.
If you want more information about it you should check these links:
- New Session Manager
- Getting Started with SSH Connections
- Introducing Amazon EC2 Instance Connect
- EC2 Instance Connect Methods
- SSH Proxy Command
Let's do this
You can get all the files used to get it done right here.
- You need to have AWS CLI already installed in your machine;
- You need to have AWS Credentials already configured in your machine;
- You need to have AWS Session Manager Plugin already installed in your machine; Docs
Update your ~/.ssh/config:
If you are using Windows and have git installed, the path is probably c:\\Program Files\\Git\\etc\\ssh\\ssh_config. Follow the instructions below.
Setup Variables in Serverless Pro Dashboard:
Deploy The Bastion
Bastion Connection Script
You are going to need to have one tab of your terminal opened exclusively for this execution.
This will make sure that your terminal is authenticated with the Serverless Pro Dashboard.
Next we need to make a connection to the RDS database.
There are a series of command line arguments being passed in. Below is a description about each one.
- --localport [ Your tunnel local port ]
- --rdsurl [ The RDS Endpoint, located at AWS Console -> RDS -> Databases -> Your Database -> Connectivity & security ]
- --rdsport [ The RDS Port, located at AWS Console -> RDS -> Databases -> Your Database -> Connectivity & security ]
- --slsorg [ Your Serverless Dashboard Pro Org name ]
- --slsapp [ Your Serverless Dashboard Pro App name ]
- --slsservice [ Your Serverless Dashboard Pro Service name ]
- --slsstage [ Your Serverless Dashboard Pro Org stage ]
If we pass the proper values, we should see the following result in our terminal.
To connect to the database you should use localhost as the Host name.
For the port, you should use the same port as you use set for the connect.sh script.
The credentials equal what you've configured for your RDS database in the IAC.
It's much safer and easier to share a connection script with your team and grant them access to your database instance via IAM credentials versus managing SSH keys. Besides the simplicity, you are also going to have all the EC2 instance connections logged to AWS CloudTrail so that you can audit them easily.
A common security issue in the past occurred when a .pem file was accidentally leaked. This allowed anyone with access to SSH into the EC2 instance that had connection with your private database.
All though the SSH Tunnel approach was more secure than the alternative public database, it still had issues.
With this pattern and this article you should no longer face these kind of issues and have peace of mind that you're connecting to RDS in a secure way.