Totally agree re: complexity. My goal is that a few config steps in a GitHub repository and AWS makes a GitHub action able to do a wide variety of things (such as accessing multiple accounts) with very little upstart work.

Storing Secrets in GitHub isn't technically insecure, and it's awesome it's provided as a free feature, but it's tedious and fragile. Someone (or something has to do various clicks and copy/pastes or API calls) to upload an access key into GitHub Secrets. It gets even worse if you have multiple accounts and then your Action Workflow file gets really gnarly if you simply pull credentials from ${{ secrets.* }}.

Also, if you need to rotate your AWS access tokens, you open up a whole new can of worms, so why not remove credentials all together!

Thanks for the question nodesocket, let me know if you have more questions or comments!

Having IAM keys in your secrets isn't insecure.

However you now have long-lived keys.

They tend to get used across multiple projects, and despite the best practice being to rotate keys frequently, it's rarely done.

You also have no idea who has them, and without the use of, say, Cloudtrail, you don't know if anyone is using them (even Cloudtrail might not pick up on everything)

The approach here is to get short-lived keys, when they are needed.

It becomes an anti-pattern when there are more SAML-like, short-lived access approaches available.

Do you rotate your keys in secrets regularly?

hey hatware!

is that a question/comment for me?

Why does a third party need access to your AWS credentials?

One of many reasons is pushing containers from GitHub Actions automation to AWS ECR (registry).

To do stuff in your AWS account.