AWS S3 is a key storage solution for a wide array of use cases, from backups to static website hosting. Managing secure read-only access to S3 buckets via an SSH proxy is a challenge for many teams, as configuring an access layer that’s reliable and secure often feels complex. This post will break down a straightforward approach to configuring an SSH access proxy for AWS S3 read-only roles to ensure your data stays secure while still being easily accessible.
Let’s walk through everything you need to know to set it up efficiently.
Why Use an SSH Access Proxy for AWS S3?
An SSH proxy acts as an intermediary between clients and AWS resources. When used with read-only S3 roles, it ensures that access is tightly scoped, logged, and controlled:
- Scalable Access Management: By centralizing access through an SSH proxy, you manage permissions efficiently across teams.
- Enhanced Security: Eliminates direct public access to your S3 buckets.
- Achieves Principle of Least Privilege: Strictly enforces read-only restrictions as defined by AWS policies.
- Simplified Governance: Provides audit logs of who accessed what and when, aligning with compliance needs.
This solution is ideal for organizations that need secure, temporary, or read-only access to AWS S3 data without exposing buckets to broader risks.
Follow these steps to implement your access flow:
1. Set Up an S3 Read-Only IAM Role
To ensure secure access, start by creating an Identity and Access Management (IAM) role with a read-only policy.
- Use the AWS Management Console or CLI.
- Attach the AmazonS3ReadOnlyAccess managed policy or your own specific bucket policy for tighter scoping.
Example Policy for a Single Bucket:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::your-s3-bucket-name/*"
}
]
}
This ensures only specific data is exposed, keeping access controlled.
2. Set Up an SSH Proxy Server
Deploy an SSH proxy server that your team can use as a gateway to AWS S3. A lightweight instance running in an isolated security group is sufficient for this.
- OpenSSH: Use it to tunnel traffic and forward requests.
- Bastion Servers: If you already use one for EC2 access, consider extending it for S3 traffic.
Ensure the instance is configured with strict inbound rules—only allowing connections from your trusted IP ranges—and it should host keys securely.
3. Federate Access Using IAM Role Credentials
For secure role assumption:
- Set up an AssumeRole operation through AWS STS (Security Token Service).
- Map users accessing the SSH proxy to assumed credentials.
Example Command:
aws sts assume-role --role-arn "arn:aws:iam::account-id:role/ReadOnlyS3Role"\
--role-session-name "SSHProxySession"
Ensure the default session policy limits actions strictly to readonly S3. Generate the session tokens dynamically and pass them through your SSH server.
Integrate an automation layer to simplify workflows for your team. Use scripts to authenticate with AWS, fetch temporary credentials, and enable secure S3 access for read-only roles when running commands locally.
Here’s an example Bash script to automate these steps:
#!/bin/bash
ROLE_ARN="arn:aws:iam::account-id:role/ReadOnlyS3Role"
SESSION_OUTPUT=$(aws sts assume-role --role-arn "$ROLE_ARN"--role-session-name "SSHProxySession")
ACCESS_KEY=$(echo $SESSION_OUTPUT | jq -r '.Credentials.AccessKeyId')
SECRET_KEY=$(echo $SESSION_OUTPUT | jq -r '.Credentials.SecretAccessKey')
TOKEN=$(echo $SESSION_OUTPUT | jq -r '.Credentials.SessionToken')
export AWS_ACCESS_KEY_ID=$ACCESS_KEY
export AWS_SECRET_ACCESS_KEY=$SECRET_KEY
export AWS_SESSION_TOKEN=$TOKEN
echo "Temporary credentials set for S3 read-only access."
Finally, connect the dots by routing S3 CLI or SDK traffic through your SSH proxy.
Example SSH Config:
Modify your .ssh/config file:
Host s3-readonly-proxy
HostName your-bastion-ip
User ec2-user
IdentityFile ~/.ssh/your-key.pem
Port 22
ProxyJump none
After configuration, you can seamlessly connect your S3 toolchain through the proxy.
Best Practices for Securing the Flow
- Rotate IAM Credentials: Regularly rotate role keys and maintain short session times.
- Restrict Access: Limit proxy server access to approved IPs and ensure SSH keys are paired only with authorized users.
- Audit Traffic: Retain logs for S3 access requests and SSH proxy-related authentications for compliance purposes.
- Validate IAM Roles: Continuously inspect roles to verify they’re scoped with the principle of least privilege.
See It in Action
Looking to simplify role-based access to AWS S3 and other cloud resources like this? Hoop.dev makes it easy to set up secure and dynamic access layers like the configuration above. You can go from concept to working access policies in minutes.
Ready to streamline your workflows? Try it live and see how quickly you can manage secure S3 read-only roles.