# AWS without Access Keys

DevFeed: [AWS without Access Keys](<https://devfeed.tech/articles/aws-without-access-keys-1712.md>)

Original publisher: [Read original article](<https://fly.io/blog/oidc-cloud-roles/>)

Published: 2024-06-19T00:00:00Z

Content type: tutorial

Language: en

Sources: [The Fly Blog](<https://devfeed.tech/sources/the-fly-blog.md>)

Topics: [AWS IAM](<https://devfeed.tech/topics/aws-iam.md>), [Amazon S3](<https://devfeed.tech/topics/amazon-s3.md>)

Tags: [aws](<https://devfeed.tech/tags/aws.md>), [aws-iam](<https://devfeed.tech/tags/aws-iam.md>), [cdn](<https://devfeed.tech/tags/cdn.md>), [close-to-users](<https://devfeed.tech/tags/close-to-users.md>), [cloud-security](<https://devfeed.tech/tags/cloud-security.md>), [deploy-app-servers](<https://devfeed.tech/tags/deploy-app-servers.md>), [docker](<https://devfeed.tech/tags/docker.md>), [elixir](<https://devfeed.tech/tags/elixir.md>), [fly](<https://devfeed.tech/tags/fly.md>), [fly-io](<https://devfeed.tech/tags/fly-io.md>), [heroku-alternative](<https://devfeed.tech/tags/heroku-alternative.md>), [heroku-competitor](<https://devfeed.tech/tags/heroku-competitor.md>), [hosting](<https://devfeed.tech/tags/hosting.md>), [i](<https://devfeed.tech/tags/i.md>), [identity](<https://devfeed.tech/tags/identity.md>), [networking](<https://devfeed.tech/tags/networking.md>), [postgresql-clusters](<https://devfeed.tech/tags/postgresql-clusters.md>), [s3](<https://devfeed.tech/tags/s3.md>), [secrets](<https://devfeed.tech/tags/secrets.md>), [servers](<https://devfeed.tech/tags/servers.md>)

## AI overview

A tutorial on using OIDC to establish limited trust between Fly.io and AWS IAM, allowing Fly Machines to access an S3 bucket without distributing AWS access keys.

## Source excerpt

It's dangerous to go alone. Fly.io runs full-stack apps by transmuting Docker containers into Fly Machines: ultra-lightweight hardware-backed VMs. You can run all your dependencies on Fly.io, but sometimes, you'll need to work with other clouds, and we've made that pretty simple. Try Fly.io out for yourself; your Rails or Node app can be up and running in just minutes. Let's hypopulate you an app serving generative AI cat images based on the weather forecast, running on a g4dn.xlarge ECS task in AWS us-east-1. It's going great; people didn't realize how dependent their cat pic prefs are on barometric pressure, and you're all anyone can talk about. Word reaches Australia and Europe, but you're not catching on, because the... latency is too high? Just roll with us here. Anyways: fixing this is going to require replicating ECS tasks and ECR images into ap-southeast-2 and eu-central-1 while also setting up load balancing. Nah. This is the O.G. Fly.io deployment story; one deployed app, one versioned container, one command to get it running anywhere in the world. But you have a problem: your app relies on training data, it's huge, your giant employer manages it, and it's in S3. Getting this to work will require AWS credentials. You could ask your security team to create a user, give it permissions, and hand over the AWS keypair. Then you could wash your neck and wait for the blade. Passing around AWS keypairs is the beginning of every horror story told about cloud security, and security team ain't having it. There's a better way. It's drastically more secure, so your security people will at least hear you out. It's also so much easier on Fly.io that you might never bother creating a IAM service account again. Let's Get It out of the Way We're going to use OIDC to set up strictly limited trust between AWS and Fly.io. In AWS: we'll add Fly.io as an Identity Provider in AWS IAM, giving us an ID we can plug into any IAM Role. Also in AWS: we'll create a Role, give it access to