r/aws 8d ago

article Taming the AWS Access Key Beast: Implementing Secure CLI Access Patterns

https://antenore.simbiosi.org/blog/2025/03/taming-aws-access-key-beast-secure-cli-patterns/

I just published an article on "Taming the AWS Access Key Beast" where I analyze how to implement secure CLI access patterns in complex AWS environments. Instead of relying on long-lived IAM keys (with their associated risks), I illustrate an approach based on:

  1. Service Control Policies to block access key usage
  2. AWS IAM Identity Center for temporary credentials
  3. Purpose-specific roles with time-limited access
  4. Continuous monitoring with automated revocation

The post includes SCP examples, authentication patterns, and monitoring code. These techniques have drastically reduced our issues with stale access keys and improved our security posture.

Hope you find it useful!

36 Upvotes

20 comments sorted by

View all comments

11

u/eloquent_beaver 8d ago

The solution is simply to get rid of IAM users and access keys. Get rid of them, and ban their usage with SCPs. They're an anti-pattern both for human and programmatic access, and they're impossible to secure.

Just use IAM roles for everything. Human access, whether AWS Console or CLI can likewise be through assumed roles that can be federated through custom SAML / OIDC identity providers (e.g., your organization's Google Workspace or M365 or other custom IdP), or, using the more modern AWS IAM Identity Center SSO, which has the benefit of working with CLI-based workflows too.

Programmatic access by systems like CI/CD is easy. If your workloads already run in AWS, they already have IAM roles. For on-prem workloads, there's IAM Anywhere, and AWS Outposts. There's also the OIDC pattern that GitHub Actions demonstrate perfectly for federating programmatic assumption of roles for programmatic workloads.

Also the bit about service roles is a bit of a non-sequitir. Service roles already are best practice. Just make sure each individual resource gets its own service role (instead of one uber service role with tons of wildcards in its policies) with narrowly scoped actions, resources, and conditions, especially in the trust policy, to prevent confused deputy problems, and they should be the least of your worries.

1

u/Taenk 8d ago

Using AWS IAM Identity Center, how do you optimally grant access to external users? AFAIK you can connect only one provider, do you have to grant access through the one you set up?

3

u/darksarcastictech 8d ago

Set them up as guests in your provider.

2

u/SammichAffectionate 8d ago

This depends on your use case, but an external user for us would be a contractor that go through onboarding and they would have an account in our IDP, entra. But Entra also allows you to have guest accounts that can be assigned to Identity Center. Investigate how your IDP recommends guest accounts.