Sign in Subscribe
Concepts

Microservices Access Proxy with AWS S3 Read-Only Roles

Andrios Robert

• 3 min read

Setting up secure and efficient access for microservices often involves managing least-privilege permissions within cloud environments like AWS. When it comes to interfacing microservices with an S3 bucket, security, configurability, and simplicity are the top priorities. In this guide, we’ll discuss how to use an access proxy architecture to enable read-only access to AWS S3 buckets. Paired with AWS IAM roles, this approach ensures granular security while keeping developer workflows streamlined.

Why an Access Proxy for AWS S3?

Microservices often interact with external resources, such as S3 buckets, to either store or fetch data. However, granting them direct access can lead to security risks and operational challenges. By implementing an access proxy, teams gain a controlled intermediary that manages how requests from microservices are routed and authenticated. Here’s why this design pattern is essential:

  • Enhanced Security: The proxy limits exposure of S3 credentials or direct access endpoints.
  • Simplified Role Management: Using read-only IAM roles restricts the actions microservices can perform on S3 buckets.
  • Centralized Control: Teams monitor and audit permissions and requests without needing to dig into individual services.

How AWS S3 Read-Only Roles Work

AWS Identity and Access Management (IAM) provides the mechanism to define granular permissions for accessing cloud resources like S3. A read-only IAM role for S3 ensures microservices can only perform actions necessary for their function—e.g., listing bucket objects or fetching specific files.

A typical policy for an S3 read-only role looks something like this:

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": [
 "s3:GetObject",
 "s3:ListBucket"
 ],
 "Resource": [
 "arn:aws:s3:::example-bucket",
 "arn:aws:s3:::example-bucket/*"
 ]
 }
 ]
}

This policy gives permission to only retrieve files (GetObject) and list the contents of the bucket (ListBucket), ensuring no write or delete actions are allowed. Assigning this policy to an IAM role used exclusively by an access proxy ensures controlled and secure interactions.

Setting Up the Access Proxy

Step 1: Create the Read-Only Role

  1. In the AWS Management Console, navigate to IAM > Roles.
  2. Create a new role and choose the service application/EC2 instance as a trusted entity for the role, depending on your architecture.
  3. Attach a policy similar to the example above. (Ensure that example-bucket in the policy is replaced with your actual bucket name.)
  4. Save the role and take note of its ARN.

Step 2: Configure the Access Proxy

An access proxy typically acts as an intermediary between microservices and AWS S3. Depending on your development stack, you can use open-source tools or libraries to set up the proxy layer. For instance:

  • Node.js developers might configure an Express.js service to route S3 operations.
  • Golang teams might use AWS SDKs to build a lightweight intermediary.

Ensure that this proxy assumes the read-only role created in Step 1. Many development frameworks and AWS SDKs allow you to configure the proxy with temporary credentials retrieved by assuming the IAM role via sts:AssumeRole.

const AWS = require('aws-sdk');
const proxyIAMRoleArn = 'arn:aws:iam::123456789012:role/S3ReadOnlyRole';

const sts = new AWS.STS();
sts.assumeRole(
 {
 RoleArn: proxyIAMRoleArn,
 RoleSessionName: 'AccessProxySession'
 },
 (err, data) => {
 if (err) {
 console.error('Error assuming role:', err);
 } else {
 const s3 = new AWS.S3({
 accessKeyId: data.Credentials.AccessKeyId,
 secretAccessKey: data.Credentials.SecretAccessKey,
 sessionToken: data.Credentials.SessionToken
 });

 s3.getObject({ Bucket: 'example-bucket', Key: 'file.txt' }, (err, fileData) => {
 if (err) console.error('Error fetching file:', err);
 else console.log('File Data:', fileData.Body.toString());
 });
 }
 }
);

Best Practices for Access Proxy Design

  1. Use Temporary Credentials: Leverage short-lived credentials for added security when the proxy assumes a role.
  2. Restrict IP Access: Where possible, limit which IP addresses can reach your access proxy layer.
  3. Log All Access: Enable logging in the proxy for all S3 actions. Combine this with AWS CloudTrail for auditing.
  4. Validate Microservice Requests: The access proxy can validate incoming requests to ensure they align with business logic before making S3 calls.

Why this Approach Scales

As more microservices proliferate in your architecture, granting individual IAM roles for each service can lead to excessive policy sprawl. The access proxy pattern solves that by centralizing permissions while ensuring services only see what they need to see. Scaling becomes as simple as adding metadata for new services to the proxy’s configuration, instead of updating dozens of IAM policies.

See it Live with hoop.dev

Configuring microservices security can be time-consuming, but tools like Hoop make it seamless to deploy and manage key permissions at scale. Instead of manually crafting roles or configuring proxies, Hoop provides a unified interface tailored for modern microservice needs. Sign up now to explore how to secure access for your services in minutes.

This design strikes the right balance of security and efficiency, giving teams confidence that microservices are operating within controlled boundaries without imposing clunky processes. A well-configured access proxy, combined with read-only IAM roles, ensures protection without sacrificing speed. Deploy better-access controls today and simplify team workflows with scalable solutions like Hoop.

Sign up for more like this.

Enter your email
Subscribe