{"slug": "how-to-stop-using-access-keys-and-keep-them-from-leaking", "title": "How to Stop Using Access Keys and Keep Them from Leaking", "summary": "A developer explains how to stop using AWS access keys and prevent leaks by switching to temporary credentials. Alternatives include AWS CLI login, OIDC for CI/CD, IAM roles for AWS resources, and IAM Roles Anywhere for on-premises servers. The key principle is using temporary credentials with expiration instead of long-term access keys.", "body_md": "This article was translated with the help of AI.\n\nAre you issuing access keys just to use the AWS CLI?\n\nI used to do exactly that. Access keys are convenient, aren't they?\n\nOnce you set them up with `aws configure`\n\n, they keep working forever.\n\nBut behind that convenience lies a scary story.\n\nA leak can mean a bill of tens of thousands of dollars, leaked data, and lost trust. And once it's out, you can't take it back.\n\nThis article covers how to deal with access keys, how to stop using them, and how to keep them from leaking.\n\nLet's quickly review what access keys are.\n\n[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html)\n\nAn access key is a credential tied to an IAM user, made up of a pair: an access key ID and a secret access key.\n\nYou use them to operate AWS from the AWS CLI or SDKs.\n\nAnd here's the reality waiting for you when one does leak.\n\n\"It's just one access key\" can turn into something this big.\n\nThat's why I say access keys are scary.\n\nSo you want to stop using access keys. What should you use instead?\n\nThere's an alternative prepared for each scenario.\n\n| Scenario | Access key | Alternative |\n|---|---|---|\n| Developer | Set up with `aws configure`\n|\n`aws login` / `aws sso login`\n|\n| CI/CD (GitHub Actions, etc.) | Register in Secrets | OIDC |\n| AWS resources (EC2/Lambda/ECS) | Embed in the resource | IAM role |\n| On-prem / external servers | Distribute to servers | IAM Roles Anywhere |\n\nLet's go through them one by one.\n\nThis is the case for us developers.\n\nWhat you use is `aws login`\n\n.\n\n[https://docs.aws.amazon.com/cli/latest/reference/login/](https://docs.aws.amazon.com/cli/latest/reference/login/)\n\nOnce you authenticate in the browser, it automatically sets up temporary credentials for you.\n\nIt works with the same feel as `aws sso login`\n\n, which you use in environments that have IAM Identity Center.\n\nIt's a good fit for environments where \"setting up IAM Identity Center is overkill.\"\n\nWith this, running your operations without access keys becomes easy to achieve.\n\nThis is the case for CI/CD like GitHub Actions.\n\nInstead of registering an access key in Secrets, you use OIDC.\n\n[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html)\n\nIt ties GitHub and an IAM role together and issues access permissions temporarily, so you can access AWS without any access key.\n\nThis is the case for AWS resources like EC2, Lambda, and ECS.\n\nInstead of embedding an access key, you use an IAM role.\n\n[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)\n\nWhen you attach a role, temporary credentials are handed over automatically, so you don't need to hold an access key.\n\nThis is the case for operating from on-prem or servers outside AWS.\n\nInstead of distributing an access key, you use IAM Roles Anywhere.\n\n[https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html)\n\nIt 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.\n\nWhen you line them up like this, you notice a shared idea.\n\nUnlike long-term credentials with no expiration such as access keys, every one of them uses temporary credentials with an expiration.\n\nShifting over to temporary credentials like this is what matters.\n\n\"So is there even any scenario left where you'd use an access key?\" you might think.\n\nIf anything is left, it's roughly the stuff that can't be migrated.\n\nFor example:\n\nThese are the \"no way around it\" situations. If you can't stop using them, then harden your defenses.\n\nThis \"keeping them from leaking\" isn't only for people who keep using access keys.\n\nSecrets aren't just access keys.\n\nDatabase passwords and API tokens leak the same way.\n\nEven if you stop using access keys, \"keeping secrets from leaking\" follows you for life.\n\nSo, how do you think secrets actually leak?\n\nLet me group it into three broad categories.\n\n`.env`\n\nor credentials files as-isLeaks happen in all sorts of ways, but what they share is that \"careless mistakes\" vastly outnumber \"malicious attacks.\"\n\nLet's stop those careless mistakes with mechanisms.\n\nSpecifically, defense in three layers: prevention, mitigation, and detection.\n\nNote that the following uses the most common case, mixing secrets into code (Git), as the example. The idea applies to other leak paths too.\n\nStop it before you leak it, right at the entrance. There are two places to stop it: the client and the server.\n\nOn the client, gitleaks.\n\nSet up a pre-commit hook, and it rejects secrets the moment you try to commit.\n\n[https://github.com/gitleaks/gitleaks](https://github.com/gitleaks/gitleaks)\n\nOn the server side, GitHub's Push Protection.\n\nIt blocks changes that contain secrets at the moment you push.\n\n[https://docs.github.com/en/code-security/secret-scanning/introduction/about-push-protection](https://docs.github.com/en/code-security/secret-scanning/introduction/about-push-protection)\n\nEven if something leaks, minimize the damage.\n\nWith a least-privilege policy, narrow down what that access key can do.\n\nWith IAM policy Conditions (like `aws:SourceIp`\n\n), limit where access can come from.\n\nRotate regularly so old credentials don't linger.\n\nEven if something leaks, notice it quickly. There are two things to watch.\n\nOne is whether a secret has been mixed into your code.\n\nBy building gitleaks into CI and running it on every push, you can catch any contamination immediately.\n\nThe other is whether a leaked access key is being used.\n\nGuardDuty analyzes sources like CloudTrail and detects abnormal credential usage, such as use from outside AWS.\n\n[https://aws.amazon.com/guardduty/](https://aws.amazon.com/guardduty/)\n\nIf it does leak, the first response is what counts.\n\n🚨 If a secret leaks, revoke it immediately, before you even think about deleting the commit.\n\nGit keeps history, so deleting the commit is meaningless.\n\nOnce you revoke it, the value left in the history can no longer be used.\n\nSecurity is the foundation of business. That said, don't overthink it. Just start with `aws login`\n\nright at hand.", "url": "https://wpnews.pro/news/how-to-stop-using-access-keys-and-keep-them-from-leaking", "canonical_source": "https://dev.to/aws-builders/how-to-stop-using-access-keys-and-keep-them-from-leaking-2k9a", "published_at": "2026-07-21 13:02:07+00:00", "updated_at": "2026-07-21 13:24:48.721185+00:00", "lang": "en", "topics": ["developer-tools", "ai-infrastructure"], "entities": ["AWS", "GitHub Actions", "IAM", "EC2", "Lambda", "ECS", "IAM Roles Anywhere"], "alternates": {"html": "https://wpnews.pro/news/how-to-stop-using-access-keys-and-keep-them-from-leaking", "markdown": "https://wpnews.pro/news/how-to-stop-using-access-keys-and-keep-them-from-leaking.md", "text": "https://wpnews.pro/news/how-to-stop-using-access-keys-and-keep-them-from-leaking.txt", "jsonld": "https://wpnews.pro/news/how-to-stop-using-access-keys-and-keep-them-from-leaking.jsonld"}}