How to Stop Using Access Keys and Keep Them from Leaking

What Are Access Keys?

Let's quickly review what access keys are. AWS documentation: Access keys

An access key is a credential tied to an IAM user, made up of a pair: an access key ID and a secret access key. You use them to operate AWS from the AWS CLI or SDKs.

Pros

• Work anywhere, and the mechanism is simple
• Easy to get started

Cons

• No expiration
• Rotation is manual
• A leak leads directly to abuse

And here's the reality waiting for you when one does leak.

• A leaked access key gets used to spin up crypto mining or huge amounts of resources, resulting in a bill of hundreds of thousands to millions of dollars
• Depending on the permissions, the contents of S3 or your database get scraped clean, leaking personal data
• The breach gets reported, you're stuck apologizing, and the trust you've built up collapses in an instant
• Once information or a leaked access key is out on the internet, you can never fully take it back

"It's just one access key" can turn into something this big. That's why I say access keys are scary.

Scenarios and Alternatives

So you want to stop using access keys. What should you use instead? There's an alternative prepared for each scenario.

Let's go through them one by one.

Developers Use aws login

This is the case for us developers. What you use is aws login. AWS CLI reference: login

Once you authenticate in the browser, it automatically sets up temporary credentials for you. It works with the same feel as aws sso login, which you use in environments that have IAM Identity Center. It's a good fit for environments where "setting up IAM Identity Center is overkill." With this, running your operations without access keys becomes easy to achieve.

CI/CD Uses OIDC

This is the case for CI/CD like GitHub Actions. Instead of registering an access key in Secrets, you use OIDC. AWS documentation: OIDC providers

It ties GitHub and an IAM role together and issues access permissions temporarily, so you can access AWS without any access key.

AWS Resources Use IAM Roles

This is the case for AWS resources like EC2, Lambda, and ECS. Instead of embedding an access key, you use an IAM role. AWS documentation: IAM roles

When you attach a role, temporary credentials are handed over automatically, so you don't need to hold an access key.

On-Prem and External Servers Use IAM Roles Anywhere

This is the case for operating from on-prem or servers outside AWS. Instead of distributing an access key, you use IAM Roles Anywhere. AWS documentation: IAM Roles Anywhere

It establishes trust with X.509 certificates and lets you obtain temporary credentials, so you can operate servers outside AWS without handing out access keys either.

The Common Idea

When you line them up like this, you notice a shared idea. Unlike long-term credentials with no expiration such as access keys, every one of them uses temporary credentials with an expiration. Shifting over to temporary credentials like this is what matters.

If You Still Have to Use Them

"So is there even any scenario left where you'd use an access key?" you might think. If anything is left, it's roughly the stuff that can't be migrated. For example:

• Old tools that don't support roles or OIDC and only accept access keys
• Environments that can't manage certificates and can't set up IAM Roles Anywhere
• Legacy apps that can't be modified
• One-off, throwaway testing

These are the "no way around it" situations. If you can't stop using them, then harden your defenses.

Keeping Them from Leaking

This "keeping them from leaking" isn't only for people who keep using access keys. Secrets aren't just access keys. Database passwords and API tokens leak the same way. Even if you stop using access keys, "keeping secrets from leaking" follows you for life.

This Is How Secrets Leak

So, how do you think secrets actually leak? Let me group it into three broad categories.

Sharing and Handoff

• Committing to Git and pushing
• Pasting into Slack, chat, or email to share
• Showing up in slide decks, blog posts, or screenshots
• Sharing or uploading .env or credentials files as-is

Embedded in Distributables

• Embedded in frontend JS or mobile apps
• Left in a Docker image layer and shipped
• Mixed into build artifacts or installers meant for distribution

Environment and Operations

• Printed in CI/CD build logs
• Pulled out after a local PC gets infected with malware
• Carried off by someone who leaves the company

Defense in Three Layers

Leaks happen in all sorts of ways, but what they share is that "careless mistakes" vastly outnumber "malicious attacks." Let's stop those careless mistakes with mechanisms. Specifically, defense in three layers: prevention, mitigation, and detection.

Note that the following uses the most common case, mixing secrets into code (Git), as the example. The idea applies to other leak paths too.

Prevention

Stop it before you leak it, right at the entrance. There are two places to stop it: the client and the server.

• On the client: gitleaks. Set up a pre-commit hook, and it rejects secrets the moment you try to commit.
• On the server side: GitHub's Push Protection. It blocks changes that contain secrets at the moment you push. GitHub documentation: About push protection

Mitigation

Even if something leaks, minimize the damage.

• With a least-privilege policy, narrow down what that access key can do.
• With IAM policy Conditions (like aws:SourceIp), limit where access can come from.
• Rotate regularly so old credentials don't linger.

Detection

Even if something leaks, notice it quickly. There are two things to watch.

• Whether a secret has been mixed into your code. By building gitleaks into CI and running it on every push, you can catch any contamination immediately.
• Whether a leaked access key is being used. GuardDuty analyzes sources like CloudTrail and detects abnormal credential usage, such as use from outside AWS.

If It Does Leak

If it does leak, the first response is what counts.

🚨 If a secret leaks, revoke it immediately, before you even think about deleting the commit. Git keeps history, so deleting the commit is meaningless. Once you revoke it, the value left in the history can no longer be used.

Summary

• There are alternatives for getting off access keys
• There are also situations where you can't stop using them
• Defend against leaks with three layers

Security is the foundation of business. That said, don't overthink it. Just start with aws login right at hand.