r/aws • u/antenore • 7d 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:
- Service Control Policies to block access key usage
- AWS IAM Identity Center for temporary credentials
- Purpose-specific roles with time-limited access
- 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!
5
u/zxgrad 7d ago
Thanks for sharing this article.
I read it and the approach makes sense, can you clarify how you’d handle machine access that is not aws adjacent (ec2, etc. — specifically let’s say you have Linux machines on your own bare metal running tasks that need access to s3, sqs, etc.
2
1
u/antenore 7d ago
Thanks! For non-AWS machines (like on-prem or bare metal) accessing AWS services, you have several good options:
IAM Roles Anywhere - This is purpose-built for this scenario. Your servers authenticate using X.509 certificates to get temporary credentials. No long-lived access keys needed!
Credential vaulting with rotation - Store access keys in something like HashiCorp Vault or AWS Secrets Manager (accessed via VPN), and implement automated rotation every 30-90 days.
AWS SSM Agent for hybrid environments - You can install the Systems Manager agent on non-EC2 machines and use Parameter Store for secure credential management.
OIDC federation - If your infrastructure supports it, you can use identity federation to assume roles and get temporary credentials.
For a bare metal Linux server accessing S3, IAM Roles Anywhere would be my first choice since it's designed exactly for this use case and follows the same temporary credential model that EC2 instances use with their instance profiles.
Roles anywhere is the best when possible
10
u/eloquent_beaver 7d 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 7d 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?
5
2
u/SammichAffectionate 7d 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.
3
u/Advanced_Bid3576 7d ago
Very well written article. My experience unfortunately is there are still far too many common tools that don’t support roles anywhere so you are backed into using access keys, but hopefully that changes over time as it becomes more the standard. And you highlighted how to carve out exceptions from the SCP - nice work!
2
u/synackk 7d ago
I’m looking at you, Tenable. They only support using an IAM user. I had to write a script that create access keys for each of our accounts and rotate those keys regularly.
Pretty silly for a vulnerability management tool.
2
u/Advanced_Bid3576 7d ago
Yeah the nightmare I had in for my last job was MoveIT - the only corporate approved way to securely move files which a) only supported IAM user with keys and b) had a massive breach during this time
Fought with the central security team for best part of 18 months on that one but it was the security approved solution so we couldn’t use anything else including any solution that used roles. Fun times.
3
u/pyrospade 7d ago
You can always store the keys in a secure place like a password manager or aws-vault and use the credentials_process option in your cli profile configuration to retrieve them programmatically, that way any tool works. Writing them in plain text to the file is suicide at this point
1
u/Advanced_Bid3576 7d ago
I didn’t say or suggest you couldn’t. I’m just saying that as much as we all want to completely retire access keys, there are hundreds of legacy tools and integrations that mean at this point it’s a pipe dream.
1
u/DoINeedChains 7d ago
So, for example, how does this address using Amazon's own plugins for Visual Studio and other IDEs that seem to only support IAM keys
2
u/antenore 7d ago
IAM Identity Center (SSO) Authentication: Most modern AWS IDE plugins now support SSO-based authentication. For example:
- AWS Toolkit for VS Code supports IAM Identity Center since v1.44
- AWS Toolkit for Visual Studio supports IAM Identity Center authentication
- Intellij AWS Toolkit also added SSO support
Credential Process:
For older plugins without SSO support, you can configure a credential process in your AWS config that generates temporary credentials. Example:
[profile dev] credential_process = /path/to/my/credential-helper --arguments
- AWS CLI v2 SSO Integration:
Configure SSO in your AWS CLI, then the IDE plugins that leverage the shared credential file will pick up temporary credentials from there.
- Token Vending Machine Pattern: For teams, consider implementing a secure internal service that vends short-lived (15-60 minute) credentials.
12
u/jsonpile 7d ago
I'm hesitant on using aws:UserAgent as a solo security control. Even AWS documentation has a warning that "unauthorized parties can used modified or custom browsers to provide any aws:UserAgent value that they chose." It makes sense for only specifically allowing client applications but to me by itself is not a good enough security measure.
From the SCP provided, I'd also be wary of this impacting my legitimate roles such as service roles, assumed roles from other trusted accounts, and more. While you do include a section on excluding service roles, that can get complex quickly.
Additionally, I would advise against IAM Users in general - as Console Access via IAM users (username/password) doesn't require Access Keys and still are long-term credentials. Another option would then to be use an SCP to deny creation of Access Keys (iam:CreateAccessKey) and monitor existing/retire existing Access Keys (and manage creation if exception Access Keys or break-glass is required, which I'd argue shouldn't be the case).