Giters

heroku / roadmap

This is the public roadmap for Salesforce Heroku services.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Allow dynos to assume an AWS IAM role without using an access key

langsharpe opened this issue · comments

commented

Required Terms

What service(s) is this request for?

Heroku dynos

Tell us about what you're trying to solve. What challenges are you facing?

Amazon recommends avoiding using long-term credentials like access keys for security reasons. It's best practice to rotate these credentials frequently. This is an administrative overhead.

We regularly set an AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY secret in each application to allow it to perform actions in our AWS account.

Can we find a way to authorise dynos in our AWS account without requiring static secrets?

Other systems allow us to let them assume a role in our AWS account. We create a role with the trust policy that allows a user in their AWS account to assume the role.

In this hypothetical implementation:

  • Heroku would provide the AWS Account ID and an External ID that we would use to set up a role in our AWS account.
  • We would add the role ARN to our Heroku applications configuration.
  • On dyno startup, Heroku would retrieve temporary credentials and supply them to the running process.

I wonder if this is technically feasible. I note that AssumeRole has a maximum duration of 12 hours, which would limit the length of time a dyno would be able to run.

commented

I would love heroku to provide a AWS Account as a heroku addon. This would allow us to have review apps with their s3 bucket created in a dedicated space and automatically cleared.

commented

We are going through some trials with a proof-of-concept feature that would solve for this issue of long-term credentials, and without having to manually rotate them. More news to come on this work. Thank you for the roadmap submission.

commented

I would love to see this done using OpenID Connect. The major cloud providers (AWS, Azure, GCP) already support something known as "workload identity federation" which maps OpenID Connect ID tokens to service accounts. If Heroku generated ID tokens signed with a private key and made them available to dynos, the dynos could exchange them for access tokens with their respective cloud providers.

For reference, GitHub has documentation on how their OpenID Connect ID tokens can be used to authenticate with various cloud providers: https://docs.github.com/en/actions/deployment/security-hardening-your-deployments