Authenticate to AWS in GitHub Actions! Works especially well with AWS Secrets Manager.
Quick Start (OIDC, recommended)Create an IAM Identity Provider in your AWS account for GitHub OIDC. (See OIDC configuration below for details.)
Create an IAM Role in your AWS account with a trust policy that allows GitHub Actions to assume it:
GitHub OIDC Trust Policy{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::<AWS_ACCOUNT_ID>: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:<GITHUB_ORG>/<GITHUB_REPOSITORY>:ref:refs/heads/<GITHUB_BRANCH>"
}
}
}
]
}Attach permissions to the IAM Role that allow it to access the AWS resources you need.
Add the following to your GitHub Actions workflow:
Example Workflow# Need ID token write permission to use OIDC
permissions:
id-token: write
jobs:
run_job_with_aws:
runs-on: ubuntu-latest
steps:
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@main # Or a specific version
with:
role-to-assume: <Role ARN you created in step 2>
aws-region: <AWS Region you want to use>
- name: Additional steps
run: |
# Your commands that require AWS credentials
aws sts get-caller-identity That's it! Your GitHub Actions workflow can now access AWS resources using the IAM Role you created. Other authentication scenarios are also supported (see below).
This action supports five different authentication methods that are configured by specifying different inputs.
core.getIDToken() call to authenticate via OIDC.Because we use the AWS JavaScript SDK, we always will use the credential resolution flow for Node.js. Depending on your inputs, the action might override parts of this flow.
Inputs and their effects on the credential resolution flow Identity Usedaws-access-key-id role-to-assume web-identity-token-file role-chaining [✅ Recommended] GitHub OIDC ✔ IAM User (no AssumeRole) ✔ AssumeRole using static IAM credentials ✔ ✔ AssumeWithWebIdentity use a token file ✔ ✔ AssumeRole using existing credentials ✔ ✔
Note: role-chaining is not always necessary to use existing credentials. If you're getting a "Credentials loaded by the SDK do not match" error, try enabling this option.
Additionally, aws-region is always required.
Note: If you use GitHub Enterprise Server, you must use the you may need to adjust examples here to match your environment.
See action.yml for more detail.
Options list and descriptions Option Description Required aws-region Which AWS region to use Yes role-to-assume Role for which to fetch credentials. Only required for some authentication types. No aws-access-key-id AWS access key to use. Only required for some authentication types. No aws-secret-access-key AWS secret key to use. Only required for some authentication types. No aws-session-token AWS session token to use. Used in uncommon authentication scenarios. No role-chaining Use existing credentials from the environment to assume a new role. No audience The JWT audience when using OIDC. Used in non-default AWS partitions, like China regions. No http-proxy An HTTP proxy to use for API calls. No mask-aws-account-id AWS account IDs are not considered secret. Setting this will hide account IDs from output anyway. No role-duration-seconds The assumed role duration in seconds, if assuming a role. Defaults to 1 hour (3600 seconds). Acceptable values range from 15 minutes (900 seconds) to 12 hours (43200 seconds). No role-external-id The external ID of the role to assume. Only needed if your role requires it. No role-session-name Defaults to "GitHubActions", but may be changed if required. No role-skip-session-tagging Skips session tagging if set. No inline-session-policy You may further restrict the assumed role policy by defining an inline policy here. No managed-session-policies You may further restrict the assumed role policy by specifying a managed policy here. No output-credentials When set, outputs fetched credentials as action step output. (Outputs aws-access-key-id, aws-secret-access-key, aws-session-token, aws-account-id, authenticated-arn, and aws-expiration). Defaults to false. No output-env-credentials When set, outputs fetched credentials as environment variables (AWS_REGION, AWS_DEFAULT_REGION, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN). Defaults to true. Set to false if you need to avoid setting/changing env variables. You'd probably want to use output-credentials if you disable this. (NOTE: Setting to false will prevent the aws-account-id from being exported as a step output). No unset-current-credentials When set, attempts to unset any existing credentials in your action runner. No disable-retry Disabled retry/backoff logic for assume role calls. By default, retries are enabled. No retry-max-attempts Limits the number of retry attempts before giving up. Defaults to 12. No special-characters-workaround Uncommonly, some environments cannot tolerate special characters in a secret key. This option will retry fetching credentials until the secret access key does not contain special characters. This option overrides disable-retry and retry-max-attempts. No use-existing-credentials When set, the action will check if existing credentials are valid and exit if they are. Defaults to false. No Adjust the retry mechanismYou can configure retry settings for if the STS call fails. By default, we retry with exponential backoff 12 times. You can disable this behavior altogether by setting the disable-retry input to true, or you can configure the number of times it retries with the retry-max-attempts input.
Your account ID is not masked by default in workflow logs. You can set the mask-aws-account-id input to true to mask your account ID in workflow logs if desired.
Sometimes, existing credentials in your runner can get in the way of the intended outcome. You can set the unset-current-credentials input to true to work around this issue.
If need use an HTTP proxy you can set it in the action manually. Additionally this action will always consider the HTTP_PROXY environment variable.
Manually configured proxy:
uses: aws-actions/configure-aws-credentials@v4.3.1 with: aws-region: us-east-2 role-to-assume: my-github-actions-role http-proxy: "http://companydomain.com:3128"
Proxy configured in the environment variable:
# Your environment configuration HTTP_PROXY="http://companydomain.com:3128"Special characters in AWS_SECRET_ACCESS_KEY
Some edge cases are unable to properly parse an AWS_SECRET_ACCESS_KEY if it contains special characters. For more information, please see the AWS CLI documentation. If you set the special-characters-workaround option, this action will continually retry fetching credentials until we get one that does not have special characters. This option overrides the disable-retry and retry-max-attempts options. We recommend that you do not enable this option unless required, because retrying APIs infinitely until they succeed is not best practice.
The default session name is "GitHubActions", and you can modify it by specifying the desired name in role-session-name.
Note: you might find it helpful to set the role-session-name to ${{ github.run_id }} so as to clarify in audit logs which AWS actions were performed by which workflow run.
The session will be tagged with the following tags: (Refer to GitHub's documentation for GITHUB_ environment variable definitions)
Note: all tag values must conform to the tag requirements. Particularly, GITHUB_WORKFLOW will be truncated if it's too long. If GITHUB_ACTOR or GITHUB_WORKFLOW contain invalid characters, the characters will be replaced with an '*'.
The action will use session tagging by default unless you are using OIDC.
Session policies are not required, but they allow you to limit the scope of the fetched credentials without making changes to IAM roles. You can specify inline session policies right in your workflow file, or refer to an existing managed session policy by its ARN.
An IAM policy in stringified JSON format that you want to use as an inline session policy. Depending on preferences, the JSON could be written on a single line.
Inline session policy examples uses: aws-actions/configure-aws-credentials@v4.3.1
with:
inline-session-policy: '{"Version":"2012-10-17","Statement":[{"Sid":"Stmt1","Effect":"Allow","Action":"s3:List*","Resource":"*"}]}'
Or we can have a nicely formatted JSON as well:
uses: aws-actions/configure-aws-credentials@v4.3.1
with:
inline-session-policy: >-
{
"Version": "2012-10-17",
"Statement": [
{
"Sid":"Stmt1",
"Effect":"Allow",
"Action":"s3:List*",
"Resource":"*"
}
]
}
The Amazon Resource Names (ARNs) of the IAM managed policies that you want to use as managed session policies. The policies must exist in the same account as the role.
Managed session policy examples uses: aws-actions/configure-aws-credentials@v4.3.1
with:
managed-session-policies: arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
And we can pass multiple managed policies likes this:
uses: aws-actions/configure-aws-credentials@v4.3.1
with:
managed-session-policies: |
arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
arn:aws:iam::aws:policy/AmazonS3OutpostsReadOnlyAccess
We recommend using GitHub's OIDC provider to get short-lived AWS credentials needed for your actions. When using OIDC, you configure IAM to accept JWTs from GitHub's OIDC endpoint. This action will then create a JWT unique to the workflow run using the OIDC endpoint, and it will use the JWT to assume the specified role with short-term credentials.
To get this to work
Configure your workflow to use the id-token: write permission.
Configure your audience, if required.
In your AWS account, configure IAM to trust GitHub's OIDC identity provider.
Configure an IAM role with appropriate claim limits and permission scope.
Note: Naming your role "GitHubActions" has been reported to not work. See #953.
Specify that role's ARN when setting up this action.
When the JWT is created, an audience needs to be specified. Normally, you would use sts.amazonaws.com, and this action uses this by default if you don't specify one. This will work for most cases. Changing the default audience may be necessary when using non-default AWS partitions, such as China regions. You can specify the audience through the audience input:
- name: Configure AWS Credentials for China region audience
uses: aws-actions/configure-aws-credentials@v4.3.1
with:
audience: sts.amazonaws.com.cn
aws-region: cn-northwest-1
role-to-assume: arn:aws-cn:iam::123456789100:role/my-github-actions-role Configuring IAM to trust GitHub
To use GitHub's OIDC provider, you must first set up federation in your AWS account. This involves creating an IAM Identity Provider that trusts GitHub's OIDC endpoint. You can create an IAM Identity Provider in the AWS Management Console by specifying the following details:
https://token.actions.githubusercontent.comsts.amazonaws.com (or your custom audience if you specified one in the audience input)Prior versions of this documentation gave instructions for specifying the certificate fingerprint, but this is no longer necessary. The thumbprint, if specified, will be ignored.
You can also create the IAM Identity Provider using the AWS CLI:
aws iam create-open-id-connect-provider \
--url https://token.actions.githubusercontent.com \
--client-id-list sts.amazonaws.com Claims and scoping permissions
To align with the Amazon IAM best practice of granting least privilege, the assume role policy document should contain a Condition that specifies a subject (sub) allowed to assume the role. GitHub also recommends filtering for the correct audience (aud). See AWS IAM documentation on which claims you can filter for in your trust policies.
Without a subject (sub) condition, any GitHub user or repository could potentially assume the role. The subject can be scoped to a GitHub organization and repository as shown in the CloudFormation template. However, scoping it down to your org and repo may cause the role assumption to fail in some cases. See Example subject claims for specific details on what the subject value will be depending on your workflow. You can also customize your subject claim if you want full control over the information you can filter for in your trust policy. If you aren't sure what your subject (sub) key is, you can add the actions-oidc-debugger action to your workflow to see the value of the subject (sub) key, as well as other claims.
Additional claim conditions can be added for higher specificity as explained in the GitHub documentation. Due to implementation details, not every OIDC claim is presently supported by IAM.
Further information about OIDCFor further information on OIDC and GitHub Actions, please see:
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@v4.3.1
with:
aws-region: us-east-2
role-to-assume: arn:aws:iam::123456789100:role/my-github-actions-role
role-session-name: MySessionName
In this example, the Action will load the OIDC token from the GitHub-provided environment variable and use it to assume the role arn:aws:iam::123456789100:role/my-github-actions-role with the session name MySessionName.
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@v4.3.1
with:
aws-region: us-east-2
role-to-assume: arn:aws:iam::123456789100:role/my-github-actions-role
role-session-name: MySessionName
- name: Configure other AWS Credentials
uses: aws-actions/configure-aws-credentials@v4.3.1
with:
aws-region: us-east-2
role-to-assume: arn:aws:iam::987654321000:role/my-second-role
role-session-name: MySessionName
role-chaining: true
In this two-step example, the first step will use OIDC to assume the role arn:aws:iam::123456789100:role/my-github-actions-role just as in the prior example. Following that, a second step will use this role to assume a different role, arn:aws:iam::987654321000:role/my-second-role.
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@v4.3.1
with:
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
aws-region: us-east-2
role-to-assume: ${{ secrets.AWS_ROLE_TO_ASSUME }}
role-external-id: ${{ secrets.AWS_ROLE_EXTERNAL_ID }}
role-duration-seconds: 1200
role-session-name: MySessionName
In this example, the secret AWS_ROLE_TO_ASSUME contains a string like arn:aws:iam::123456789100:role/my-github-actions-role. To assume a role in the same account as the static credentials, you can simply specify the role name, like role-to-assume: my-github-actions-role.
- name: Configure AWS Credentials 1
id: creds
uses: aws-actions/configure-aws-credentials@v4.3.1
with:
aws-region: us-east-2
role-to-assume: arn:aws:iam::123456789100:role/my-github-actions-role
output-credentials: true
- name: get caller identity 1
run: |
aws sts get-caller-identity
- name: Configure AWS Credentials 2
uses: aws-actions/configure-aws-credentials@v4.3.1
with:
aws-region: us-east-2
aws-access-key-id: ${{ steps.creds.outputs.aws-access-key-id }}
aws-secret-access-key: ${{ steps.creds.outputs.aws-secret-access-key }}
aws-session-token: ${{ steps.creds.outputs.aws-session-token }}
role-to-assume: arn:aws:iam::123456789100:role/my-other-github-actions-role
- name: get caller identity2
run: |
aws sts get-caller-identity
This example shows that you can reference the fetched credentials as outputs if output-credentials is set to true. This example also shows that you can use the aws-session-token input in a situation where session tokens are fetched and passed to this action.
This code is made available under the MIT license.
If you would like to report a potential security issue in this project, please do not create a GitHub issue. Instead, please follow the instructions here or email AWS security directly.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4