Ephemeral Credentials

source: https://news.ycombinator.com/item?id=31987391 July, 2022

It’s essentially an access token with a very short expiry time. The other term of art is “dynamic secrets.” https://www.vaultproject.io/use-cases/dynamic-secrets

This is a discussion of why using ephemeral credentials (e.g. AWS STS/SSO) rather than static credentials (e.g. IAM Users).

Other related discussions on saml2aws and AWS SSO and more.

One of the major benefits of ephemeral tokens is that they become less attractive to put into the code, and more attractive to put in a config file/vault that’s easier to update and keep secret. This in itself is useful because it makes it less likely that it will be in some source file someone shows, or pushed to some remote repo that at some point has permissions allowed so people can see it.

We got rid of all IAM users used by applications and moved to role-based access. Nowhere in the application do you need to enter AWS credentials. AWS SDK will attempt to discover short-lived credentials for you and will assume the role specified at the infrastructure layer, e.g. in a task definition.

same here, but we still have IAM Users for service accounts. E.g. some customers have on premise infra that needs to talk to our services of infrastructure.

For my dev machine’s interactions with AWS, I use https://github.com/99designs/aws-vault

You add the long lived IAM user API key/secret to it and it stores it in a password protected storage (MacOS keychain or similar).

Then you invoke aws-vault with an IAM role and command, and it will handle obtaining short-lived credentials scoped to that role (including TOTP 2-factor code auth), and then run the command with those temporary credentials as env vars.

With the right AWS permissions on your user, it can also automatically rotate the IAM user API keys for you.

So far I used profiles extensively. AWS_PROFILE is your friend.

AWS best practices is to use AWS SSO, which accomplishes this same effect but without any long-lived local credentials. It works really well.

AWS SSO solves it better, and for any number of AWS accounts.

I still use aws-vault, though, when I’m not in a position to set up AWS SSO.

redentials should either be long lived with (very) limited scope or short lived with required scope.

For example, for AWS you can create long lived credentials for users which are scoped to only allow one operation, namely obtaining a short lived token (with the aid of a hardware token such as a Yubikey) with scope to perform other operations.

AWS guide here: https://aws.amazon.com/blogs/security/enhance-programmatic-access-for-iam-users-using-yubikey-for-multi-factor-authentication/