---
title: "AWS without Access Keys"
description: "The post describes how Fly Machines can access AWS resources such as an S3 bucket without distributing long-lived AWS access keys. It uses OpenID Connect (OIDC): AWS IAM trusts Fly.io’s OIDC identity provider, a role grants narrowly scoped permissions, and the app receives the role ARN as an environment variable. At boot, Fly’s Rust init requests a machine-specific OIDC token through the /.fly/api Unix socket, writes it to /.fly/oidc_token, and sets AWS_WEB_IDENTITY_TOKEN_FILE and AWS_ROLE_SESSION_NAME so the AWS SDK can call STS AssumeRoleWithWebIdentity. AWS verifies the token, issues short-lived credentials, and evaluates the role’s IAM policy before serving the requested object. The trust policy can constrain tokens by audience and subject, including an organization, Fly App, or machine; the same pattern can authenticate against other OIDC-compliant providers, although Azure and GCP lack equivalent init integration."
---

# AWS without Access Keys

[Fly.io](https://yomu.fyi/company/fly-io) · Jun 19, 2024

**Type:** Problem & solution

## Summary

The post describes how Fly Machines can access AWS resources such as an S3 bucket without distributing long-lived AWS access keys. It uses OpenID Connect (OIDC): AWS IAM trusts Fly.io’s OIDC identity provider, a role grants narrowly scoped permissions, and the app receives the role ARN as an environment variable. At boot, Fly’s Rust init requests a machine-specific OIDC token through the /.fly/api Unix socket, writes it to /.fly/oidc\_token, and sets AWS\_WEB\_IDENTITY\_TOKEN\_FILE and AWS\_ROLE\_SESSION\_NAME so the AWS SDK can call STS AssumeRoleWithWebIdentity. AWS verifies the token, issues short-lived credentials, and evaluates the role’s IAM policy before serving the requested object. The trust policy can constrain tokens by audience and subject, including an organization, Fly App, or machine; the same pattern can authenticate against other OIDC-compliant providers, although Azure and GCP lack equivalent init integration.

## Context

An app running on Fly.io needs access to large training data stored in an AWS S3 bucket, but distributing AWS user keypairs is presented as a serious cloud-security risk.

## Approach / What changed

Configure AWS IAM to trust Fly.io’s OIDC identity provider and create a role with S3 permissions and token conditions. Set the role ARN as AWS\_ROLE\_ARN in the Fly App; Fly init obtains a machine-specific OIDC token and configures the AWS SDK to exchange it through STS for temporary credentials.

## Takeaways

- AWS STS credentials are generated dynamically, expire in minutes, rotate themselves, and fail closed, limiting the blast radius compared with stored AWS keypairs.
- The IAM trust policy can restrict access by token audience and subject, including an organization, a specific Fly App, or an individual Fly Machine.
- Fly’s OIDC support accepts arbitrary audience strings, allowing authentication to other OIDC-compliant cloud providers, though Azure and GCP do not have equivalent init integration described here.

**Tags:** [AWS](https://yomu.fyi/topic/aws), [Fly Machines](https://yomu.fyi/topic/fly-machines), [OIDC](https://yomu.fyi/topic/oidc)

- Source: [Fly.io](https://fly.io/blog/oidc-cloud-roles)
- Source URL: https://fly.io/blog/oidc-cloud-roles
- Ingested by Yomu: 2026-09-03T01:25:14.823Z

[Read original post](https://fly.io/blog/oidc-cloud-roles)