aws-actions/configure-aws-credentials
1
0
Fork 0
mirror of https://github.com/aws-actions/configure-aws-credentials.git synced 2026-06-08 21:17:06 +00:00
Code Issues Projects Releases Packages Wiki Activity

chore: Revise readme

Browse source
This commit is contained in:
kellertk 2025-07-28 16:31:53 -07:00 • committed by Tom Keller
commit b09a246f74
1 changed files with 209 additions and 295 deletions
Download patch file Download diff file Expand all files Collapse all files

492
README.md
View file

@ -1,98 +1,130 @@
## Configure AWS Credentials for GitHub Actions
Configure your AWS credentials and region environment variables for use in other
GitHub Actions.
Configure AWS Credentials
=========================
Autenticate to AWS in GitHub Actions! Works especially well with [AWS Secrets
Manager](https://github.com/aws-actions/aws-secretsmanager-get-secrets).
This action implements the AWS JavaScript SDK credential resolution chain
and exports session environment variables for your other Actions to use.
Environment variable exports are detected by both the AWS SDKs and the AWS CLI
for AWS API calls.
Quick Start (OIDC, recommended)
-------------------------------
1. Create an IAM Identity Provider in your AWS account for GitHub OIDC. (See
[OIDC configuration](#oidc-configuration) below for details.)
2. Create an IAM Role in your AWS account with a trust policy that allows GitHub
Actions to assume it:
<details>
<summary>GitHub OIDC Trust Policy</summary>
## Overview
API calls to AWS need to be signed with credential information, so when you use
one of the AWS SDKs or an AWS tool, you must provide it with AWS credentials and
and AWS region. One way to do that in GitHub Actions is to use a repository
secret with IAM credentials, but this doesn't follow [AWS security
guidelines](https://docs.aws.amazon.com/IAM/latest/UserGuide/security-creds.html)
on using long term credentials. Instead, we recommend that you use a long term
credential or JWT to fetch a temporary credential, and use that with your tools
instead. This GitHub Action facilitates just that.
```json
{
"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>"
}
}
}
]
}
```
</details>
3. Attach permissions to the IAM Role that allow it to access the AWS resources
you need.
4. Add the following to your GitHub Actions workflow:
<details>
<summary>Example Workflow</summary>
AWS SDKs and Tools look for your credentials in standardized environment
variables. In essence, this Action runs through the standard [credential
resolution flow](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html),
and at the end, exports environment variables for you to use later.
```yaml
# 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
```
</details>
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).
We support five methods for fetching credentials from AWS, but we recommend that
you use GitHub's OIDC provider in conjunction with a configured AWS IAM
Identity Provider endpoint.
Security Recommendations
------------------------
* Use temporary credentials when possible. OIDC is recommended because it
provides temporary credentials and it's easy to set up.
* Do not store credentials in your repository's code. Consider using
[git-secrets](https://github.com/awslabs/git-secrets) to prevent committing
secrets to your repository.
* [Grant least privilege](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)
to your workflows. Grant only those permissions that are necessary for the
workflow to run.
* [Monitor the activity](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#keep-a-log)
of the credentials used in workflows.
* Periodically rotate any long-lived credentials that you use.
* Store sensitive information in a secure way, such as using
[AWS Secrets Manager](https://aws.amazon.com/secrets-manager/) or
[GitHub Secrets](https://docs.github.com/en/actions/security-guides/encrypted-secrets).
For more information on how to do that, read on.
Other Authentication Scenarios
------------------------------
This action supports five different authentication methods that are configured
by specifying different inputs.
### Note about GHES
Some of this documentation may be inaccurate if you are using GHES (GitHub
Enterprise Server), please take note to review the GitHub documentation when
relevant.
For example, the URL that the OIDC JWT is issued from is different than the
usual `token.actions.githubusercontent.com`, and will be unique to your
enterprise server. As a result, you will need to configure this differently when
you create the Identity Provider.
We do not presently have a GHES testing environment to validate this action. If
you are running in GHES and encounter problems, please
[let us know](https://github.com/aws-actions/configure-aws-credentials/issues/new/choose).
## Security recommendations
We recommend following
[Amazon IAM best practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
for the AWS credentials used in GitHub Actions workflows, including:
* Do not store credentials in your repository's code.
* [Grant least privilege](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)
to the credentials used in GitHub Actions workflows. Grant only the
permissions required to perform the actions in your GitHub Actions workflows.
Do not assume overly permissive roles, even for testing.
* [Monitor the activity](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#keep-a-log)
of the credentials used in GitHub Actions workflows.
* Use temporary credentials when possible.
* Periodically rotate any long-term credentials you use.
## Using this action
There are five different supported ways to retrieve credentials:
- Using GitHub's OIDC provider (`AssumeRoleWithWebIdentity`)
- Proceeding as an IAM user (No STS call is made)
- Using access keys as action input (`AssumeRole`)
- Using a WebIdentity Token File (`AssumeRoleWithWebIdentity`)
- Using existing credentials in your runner (`AssumeRole`)
1. Use a `core.getIDToken()` call to authenticate via OIDC.
2. Re-export existing long-lived IAM credentials (access key ID and secret
access key) as environment variables.
3. Use static credentials stored in GitHub Secrets to fetch temporary
credentials via STS AssumeRole.
4. Use a Web Identity Token to fetch temporary credentials via STS
AssumeRoleWithWebIdentity.
5. Use credentials stored in the Action environment to fetch temporary
credentials via STS AssumeRole.
Because we use the AWS JavaScript SDK, we always will use the [credential
resolution flow for Node.js](https://docs.aws.amazon.com/sdk-for-javascript/v3/developer-guide/setting-credentials-node.html).
Depending on your inputs, the action might override parts of this flow.
We recommend using the first option above: [GitHub's OIDC provider](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services).
This method uses OIDC to get short-lived credentials needed for your actions.
See [OIDC](#OIDC) for more information on how to setup your AWS account to
assume a role with OIDC.
<details>
<summary>Inputs and their effects on the credential resolution flow</summary>
The following table describes which method we'll use to get your credentials
based on which values are supplied to the Action:
| **Identity Used** | `aws-access-key-id` | `role-to-assume` | `web-identity-token-file` | `role-chaining` | `id-token` permission
| --------------------------------------------------------------- | ------------------- | ---------------- | ------------------------- | - | - |
| [✅ Recommended] Assume Role directly using GitHub OIDC provider | | ✔ | | | ✔ |
| IAM User | ✔ | | | | |
| Assume Role using IAM User credentials | ✔ | ✔ | | | |
| Assume Role using WebIdentity Token File credentials | | ✔ | ✔ | | |
| Assume Role using existing credentials | | ✔ | | ✔ | |
| **Identity Used** | `aws-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.*
</details>
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.*
Additional Options
------------------
### Options
See [action.yml](./action.yml) for more detail.
<details>
<summary>Options list and descriptions</summary>
| Option | Description | Required |
|---------------------------|---------------------------------------------------------------------------------------------------|----------|
@ -118,25 +150,67 @@ See [action.yml](./action.yml) for more detail.
| 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 |
</details>
#### Credential Lifetime
The default session duration is **1 hour**.
#### Adjust the retry mechanism
You 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.
If you would like to adjust this you can pass a duration to
`role-duration-seconds`, but the duration cannot exceed the maximum that was
defined when the IAM Role was created.
#### Mask account ID
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.
#### External ID
If your role requires an external ID to assume, you can provide the external ID
with the `role-external-id` input
#### Unset current credentials
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.
#### Session tagging and name
#### Use an HTTP proxy
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.
<details>
<summary>Proxy configuration</summary>
Manually configured proxy:
```yaml
uses: aws-actions/configure-aws-credentials@v4.1.0
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:
```bash
# Your environment configuration
HTTP_PROXY="http://companydomain.com:3128"
```
</details>
#### 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](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-troubleshooting.html#tshoot-signature-does-not-match).
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.
Session Naming and Policies
---------------------------
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 }}`
*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._
run.*
The session will be tagged with the
following tags: (Refer to [GitHub's documentation for `GITHUB_` environment
@ -158,21 +232,7 @@ 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 during role assumption, unless
you follow our recommendation and are assuming a role with a WebIdentity. For
WebIdentity role assumption, the session tags have to be included in the encoded
WebIdentity token. This means that tags can only be supplied by the OIDC
provider, and they cannot set during the AssumeRoleWithWebIdentity API call
within the Action. See [#419](https://github.com/aws-actions/configure-aws-credentials/issues/419)
for more information.
You can skip this session tagging by providing
`role-skip-session-tagging` as true in the action's inputs:
```yaml
uses: aws-actions/configure-aws-credentials@v4
with:
role-skip-session-tagging: true
```
The action will use session tagging by default unless you are using OIDC.
### Session policies
Session policies are not required, but they allow you to limit the scope of the
@ -183,7 +243,11 @@ session policy by its ARN.
#### Inline session policies
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 like this:
line.
<details>
<summary>Inline session policy examples</summary>
```yaml
uses: aws-actions/configure-aws-credentials@v4
with:
@ -206,11 +270,16 @@ Or we can have a nicely formatted JSON as well:
]
}
```
</details>
#### Managed session policies
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. You can pass a single managed policy like this:
the role.
<details>
<summary>Managed session policy examples</summary>
```yaml
uses: aws-actions/configure-aws-credentials@v4.1.0
with:
@ -224,38 +293,10 @@ And we can pass multiple managed policies likes this:
arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
arn:aws:iam::aws:policy/AmazonS3OutpostsReadOnlyAccess
```
</details>
### Misc
#### Adjust the retry mechanism
You can now configure retry settings for when 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.
#### Mask account ID
Your account ID is not masked by default in workflow logs since it's not
considered sensitive information. However, you can set the `mask-aws-account-id`
input to `true` to mask your account ID in workflow logs if desired.
#### Unset current credentials
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.
#### 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](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-troubleshooting.html#tshoot-signature-does-not-match).
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.
## OIDC
OIDC Configuration
-------------------
We recommend using [GitHub's OIDC
provider](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services)
to get short-lived AWS credentials needed for your actions. When using OIDC, you
@ -274,15 +315,6 @@ To get this to work
5. Specify that role's ARN when setting up this action.
First, in order for this action to create the JWT, your workflow file must have
the `id-token: write` permission:
```yaml
permissions:
id-token: write
contents: read
```
### OIDC Audience
When the JWT is created, an audience needs to be specified. Normally, you would
@ -301,75 +333,25 @@ You can specify the audience through the `audience` input:
```
### Configuring IAM to trust GitHub
To use GitHub's OIDC provider, you must first set up federation
with the provider as an IAM IdP. The GitHub OIDC provider only needs to be
created once per account (i.e. multiple IAM Roles that can be assumed by the
GitHub's OIDC can share a single OIDC Provider). Here is a sample CloudFormation
template that will configure this trust for you.
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:
- **Provider Type**: OIDC
- **Provider URL**: `https://token.actions.githubusercontent.com`
- **Audience**: `sts.amazonaws.com` (or your custom audience if you specified
one in the `audience` input)
Note that the thumbprint below has been set to all F's because the thumbprint is
not used when authenticating `token.actions.githubusercontent.com`. This is a
special case used *only when GitHub's OIDC is authenticating to IAM*. IAM uses
its library of trusted CAs to authenticate. The value is still the API, so it
must be specified.
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 copy the template below, or load it from here:
https://d38mtn6aq9zhn6.cloudfront.net/configure-aws-credentials-latest.yml
You can also create the IAM Identity Provider using the AWS CLI:
```yaml
Parameters:
GitHubOrg:
Description: Name of GitHub organization/user (case sensitive)
Type: String
RepositoryName:
Description: Name of GitHub repository (case sensitive)
Type: String
OIDCProviderArn:
Description: Arn for the GitHub OIDC Provider.
Default: ""
Type: String
OIDCAudience:
Description: Audience supplied to configure-aws-credentials.
Default: "sts.amazonaws.com"
Type: String
Conditions:
CreateOIDCProvider: !Equals
- !Ref OIDCProviderArn
- ""
Resources:
Role:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Statement:
- Effect: Allow
Action: sts:AssumeRoleWithWebIdentity
Principal:
Federated: !If
- CreateOIDCProvider
- !Ref GithubOidc
- !Ref OIDCProviderArn
Condition:
StringEquals:
token.actions.githubusercontent.com:aud: !Ref OIDCAudience
StringLike:
token.actions.githubusercontent.com:sub: !Sub repo:${GitHubOrg}/${RepositoryName}:*
GithubOidc:
Type: AWS::IAM::OIDCProvider
Condition: CreateOIDCProvider
Properties:
Url: https://token.actions.githubusercontent.com
ClientIdList:
- sts.amazonaws.com
ThumbprintList:
- ffffffffffffffffffffffffffffffffffffffff
Outputs:
Role:
Value: !GetAtt Role.Arn
```bash
aws iam create-open-id-connect-provider \
--url https://token.actions.githubusercontent.com \
--client-id-list sts.amazonaws.com
```
### Claims and scoping permissions
@ -411,80 +393,10 @@ For further information on OIDC and GitHub Actions, please see:
* [GitHub docs: Configuring OpenID Connect in Amazon Web Services](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services)
* [GitHub changelog: GitHub Actions: Secure cloud deployments with OpenID Connect](https://github.blog/changelog/2021-10-27-github-actions-secure-cloud-deployments-with-openid-connect/)
## Self-Hosted Runners
Examples
--------
If you run your GitHub Actions in a
[self-hosted runner](https://help.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners) that already has access to AWS credentials, such as
an EC2 instance, then you do not need to provide IAM user access key credentials
to this action. We will use the standard AWS JavaScript SDK credential
resolution methods to find your credentials, so if the AWS JS SDK can
authenticate on your runner, this Action will as well.
If no access key credentials are given in the action inputs, this action will
use credentials from the runner environment using the
[default methods for the AWS SDK for Javascript](https://docs.aws.amazon.com/sdk-for-javascript/v3/developer-guide/setting-credentials-node.html).
You can use this action to simply configure the region and account ID in the
environment, and then use the runner's credentials for all AWS API calls made by
your Actions workflow:
```yaml
uses: aws-actions/configure-aws-credentials@v4.1.0
with:
aws-region: us-east-2
```
In this case, your runner's credentials must have permissions to call any AWS
APIs called by your Actions workflow.
Or, you can use this action to assume a role, and then use the role credentials
for all AWS API calls made by your Actions workflow:
```yaml
uses: aws-actions/configure-aws-credentials@v4.1.0
with:
aws-region: us-east-2
role-to-assume: my-github-actions-role
```
In this case, your runner's credentials must have permissions to assume the
role.
You can also assume a role using a web identity token file, such as if using
[Amazon EKS IRSA](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts-technical-overview.html). Pods running in EKS
worker nodes that do not run as root can use this file to assume a role with a
web identity.
### Proxy Configuration
If need use a HTTP proxy you can set it in the action manually.
Additionally this action will always consider the `HTTP_PROXY` environment
variable.
Manually configured proxy:
```yaml
uses: aws-actions/configure-aws-credentials@v4.1.0
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:
```bash
# Your environment configuration
HTTP_PROXY="http://companydomain.com:3128"
```
### Use with the AWS CLI
This workflow does _not_ install the [AWS CLI](https://aws.amazon.com/cli/)
into your environment. Self-hosted runners that intend to run this action prior
to executing `aws` commands need to have the AWS CLI
[installed](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)
if it's not already present.
Most [GitHub hosted runner environments](https://github.com/actions/virtual-environments)
should include the AWS CLI by default.
## Examples
### AssumeRoleWithWebIdentity (recommended)
### AssumeRoleWithWebIdentity
```yaml
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@v4.1.0
@ -565,12 +477,14 @@ 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.
## License Summary
License
-------
This code is made available under the MIT license.
## Security Disclosures
Security Disclosures
--------------------
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](https://aws.amazon.com/security/vulnerability-reporting/) or [email AWS
security directly](mailto:aws-security@amazon.com).
do not create a GitHub issue. Instead, please follow the instructions
[here](https://aws.amazon.com/security/vulnerability-reporting/) or
[email AWS security](mailto:aws-security@amazon.com) directly.