# aws-actions/configure-aws-credentials: OIDC-first AWS access for GitHub Actions > The action replaces long-lived AWS keys in CI with short-lived credentials obtained through GitHub's OIDC provider, while still supporting static keys and STS AssumeRole for teams that cannot move yet. **aws-actions/configure-aws-credentials** — Configure AWS credential environment variables for use in other GitHub Actions. - Repository: https://github.com/aws-actions/configure-aws-credentials - Stars: 3,011 · Forks: 586 - Language: TypeScript - License: MIT - Published: 2026-09-24 · Updated: 2026-09-24 · Language: en - Canonical page: https://hysenlabs.com/projects/aws-actions-configure-aws-credentials ## The problem: AWS keys in CI that never expire A GitHub Actions workflow that needs to call S3, push to ECR or read a secret has to present AWS credentials somehow. The oldest way is to paste an access key ID and secret access key into repository secrets and export them as environment variables. Those keys do not expire, they are copied into every job that needs them, and rotating them means touching every repository that stores them. The action exists to remove that pattern. Its README states the goal plainly: authenticate to AWS in GitHub Actions, with OIDC listed as the recommended quick start. The intended audience is workflow authors who already run AWS CLI or SDK commands inside a job and want the credential to be temporary and scoped to that job. It is not a secrets manager, not a deployment tool, and not useful outside a runner environment where the AWS SDK can pick up environment variables. ## How the action resolves credentials and where it writes them The action is a Node.js program bundled from TypeScript into dist/index.js, and it depends on @aws-sdk/client-sts and @aws-sdk/credential-provider-node. That dependency choice explains the behaviour: the README says that because the action uses the AWS JavaScript SDK, it always follows the credential resolution flow for Node.js, and that depending on the inputs it may override parts of that flow. The README publishes a table mapping each input combination to an identity. Supplying role-to-assume alone selects GitHub OIDC. Supplying aws-access-key-id alone means an IAM user with no AssumeRole. Supplying both means AssumeRole with static credentials. Adding web-identity-token-file switches to AssumeRoleWithWebIdentity, and adding role-chaining switches to AssumeRole using credentials already present in the environment. The README also notes that role-chaining is not always required, and suggests enabling it when the SDK reports that loaded credentials do not match. aws-region is always required, regardless of which path you take. The resolved credentials are then exported as environment variables so later steps and the AWS CLI see them without further configuration. A second bundle, dist/cleanup/index.js, is built from src/cleanup, which indicates the action registers a post step to remove what it exported, though the README excerpt does not describe that cleanup behaviour in detail. ## Installing and running the OIDC quick start There is nothing to install locally. The action is consumed by reference from a workflow file, and the README pins the example to a released tag rather than a branch. The first step is an IAM OIDC identity provider for token.actions.githubusercontent.com, followed by a role whose trust policy uses sts:AssumeRoleWithWebIdentity. The README supplies this trust policy, with the condition keys that matter: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam:::oidc-provider/token.actions.githubusercontent.com" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com", "token.actions.githubusercontent.com:sub": "repo:@/@:ref:refs/heads/" } } } ] } ``` The sub claim is the part people get wrong. The README warns that its value changes with the workflow and environment, that repositories created before 15 July 2026 omit the @ and @ suffixes unless opted in, and that jobs running in GitHub environments add an environment: stanza. The workflow side needs id-token: write, which the README's example sets at the top level, and then a step that references the action by tag: ```yaml permissions: id-token: write jobs: run_job_with_aws: runs-on: ubuntu-latest steps: - name: Configure AWS Credentials uses: aws-actions/configure-aws-credentials@v6.3.0 with: role-to-assume: aws-region: - name: Additional steps run: | aws sts get-caller-identity ``` What you should see is the assumed role's identity printed by aws sts get-caller-identity, which confirms the environment variables were populated before the step ran. If the trust policy's sub does not match the token, that command fails with an access denied error from STS rather than a missing-credentials error, which is the usual signal that the claim string is wrong. ## The five authentication paths and when OIDC is the wrong one The README lists five supported methods: OIDC via core.getIDToken(), re-exporting existing long-lived keys, static keys used to AssumeRole, a web identity token file, and AssumeRole using credentials already in the action environment. The last two exist for cases OIDC cannot cover, such as a workflow that must assume a role in a second account after already holding credentials, or a job that receives a web identity token from somewhere other than GitHub. The honest limitation is that OIDC only works where GitHub can mint an ID token. A self-hosted runner that is not connected to GitHub's OIDC endpoint, a pipeline on another CI system, or a developer's laptop cannot use this action at all, and the README's note about GitHub Enterprise Server, which says examples may need adjusting for that environment, hints at the same boundary. There is a second, subtler failure mode. The README's security section advises setting translate-env-variables to false when AWS environment variables or the action's own input variables on the runner are written by other processes, because otherwise the action's exports can collide with what is already there. That is a real risk on shared or self-hosted runners where a previous job left AWS_PROFILE or AWS_ACCESS_KEY_ID behind. The README also flags pull_request_target workflows and non-ephemeral environments as places to be careful, since those can expose credentials to code you did not write. ## How this differs from aws-actions/amazon-ecr-login and from running aws configure Two comparisons are worth making. The first is aws-actions/amazon-ecr-login, which appears in the same search results and is maintained under the same organisation. That action does one job: it authenticates Docker to an Amazon ECR registry so you can push or pull images. It does not export general-purpose AWS credentials, and it cannot assume an arbitrary role for an SDK call. If your workflow only pushes an image, the ECR login action is the narrower tool. If your workflow then needs to tag a resource, read a parameter or invoke Lambda, you need credentials in the environment, which is what configure-aws-credentials provides. The second comparison is the manual approach of running aws configure or writing a credentials file in a setup step. That writes long-lived keys to disk and leaves them there for the remainder of the job, and it does not integrate with GitHub's OIDC token at all. The action's advantage is that the credential is obtained at job time and, based on the presence of the cleanup bundle, removed at the end. The trade-off is that you now depend on the action's release cadence and on the Node.js runtime GitHub ships for JavaScript actions. ## Maintenance, version pinning and the MIT licence The repository is not archived and its last push was on 2026-09-22, two days before this writing, with v6.3.0 released on 2026-09-15 and v6.2.4 and v6.2.3 before that. That is a fast release cadence for a credential action, and it is also the main upgrade cost: the README's own example pins @v6.3.0, so a floating major tag is a choice you make, not one the documentation makes for you. The package.json declares engines.node as >= 16.3.0, while the build script bundles with esbuild targeting node24, so the runtime the action actually executes on is determined by GitHub's runner image rather than by that engine field. The release tooling is release-please, visible from .release-please-manifest.json and release-please-config.json, and the changelog is generated, which means breaking changes surface in CHANGELOG.md rather than in the README. On licensing: the repository is MIT, and the build includes a license generation step that produces a THIRD-PARTY file from the bundled dependencies, so the distributed dist/index.js carries third-party notices. That matters if you vendor or mirror the action internally. Nothing here is legal advice; if you redistribute the bundle, read LICENSE and THIRD-PARTY yourself. ## Conclusion Adopt it if your workflows need AWS access and you can create an IAM OIDC identity provider plus a role whose trust policy matches your repository's sub claim; the action is small, MIT licensed and released frequently, with v6.3.0 tagged on 2026-09-15 and the repository's last push on 2026-09-22. Skip it if your jobs run outside GitHub Actions, or if you need a credential broker that works across GitLab, Jenkins and local machines, where a CLI-based assume-role step fits better. Before rolling it out, verify the exact sub claim your repository emits, because the README notes that repositories created before 15 July 2026 omit the @ and @ suffixes unless opted in, and set translate-env-variables to false if other processes already write AWS environment variables on the runner. ## FAQ ### How do I configure AWS credentials in GitHub Actions with aws-actions/configure-aws-credentials? The README's quick start has you create an IAM OIDC identity provider for GitHub, create a role with a trust policy using sts:AssumeRoleWithWebIdentity, then add a step that uses aws-actions/configure-aws-credentials with role-to-assume and aws-region. The job needs id-token: write permission, and a following step can run aws sts get-caller-identity to confirm the credentials work. ### Does aws-actions/configure-aws-credentials support OIDC? Yes. OIDC is the first and recommended method in the README, and it is selected by supplying role-to-assume without static access keys. The action calls core.getIDToken() to obtain the token and exchanges it with STS. ### How do I configure AWS credentials for GitHub Actions v4 of the action? The README does not document version-specific behaviour for v4. Its example pins aws-actions/configure-aws-credentials@v6.3.0 and the documented inputs are role-to-assume and aws-region for the OIDC path; the inputs and their effects table applies to the current release line. ### How do I configure AWS credentials in the AWS CLI, and is that the same as this action? No. The action configures AWS credential environment variables for steps inside a GitHub Actions job. The README points to the AWS SDK for JavaScript credential resolution flow for the Node.js side, and it does not document a local aws configure workflow. ### What are AWS credentials in the context of aws-actions/configure-aws-credentials? In this action they are the values the workflow steps use to call AWS: either temporary credentials obtained through OIDC or STS AssumeRole, or long-lived IAM access key ID and secret access key re-exported as environment variables. The README recommends temporary credentials and OIDC in particular. ## Sources - [aws-actions/configure-aws-credentials on GitHub](https://github.com/aws-actions/configure-aws-credentials) - [Issues](https://github.com/aws-actions/configure-aws-credentials/issues) - [License: MIT](https://github.com/aws-actions/configure-aws-credentials/blob/main/LICENSE) - [README](https://github.com/aws-actions/configure-aws-credentials/blob/main/README.md) - [Releases](https://github.com/aws-actions/configure-aws-credentials/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/aws-actions-configure-aws-credentials