GitHub - aws-actions/configure-aws-credentials: Configure AWS credential environment variables for use in other GitHub Actions. (original) (raw)

Configure AWS Credentials for GitHub Actions

Configure your AWS credentials and region environment variables for use in other GitHub Actions.

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.

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 guidelineson 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.

AWS SDKs and Tools look for your credentials in standardized environment variables. In essence, this Action runs through the standard credential resolution flow, and at the end, exports environment variables for you to use later.

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.

For more information on how to do that, read on.

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, pleaselet us know.

Security recommendations

We recommend followingAmazon IAM best practicesfor the AWS credentials used in GitHub Actions workflows, including:

• Do not store credentials in your repository's code.
• Grant least privilegeto 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 activityof 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)

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.

We recommend using the first option above: GitHub's OIDC provider. This method uses OIDC to get short-lived credentials needed for your actions. See OIDC for more information on how to setup your AWS account to assume a role with OIDC.

The following table describes which method we'll use to get your credentials based on which values are supplied to the Action:

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.

Options

See action.yml for more detail.

Credential Lifetime

The default session duration is 1 hour.

If you would like to adjust this you can pass a duration torole-duration-seconds, but the duration cannot exceed the maximum that was defined when the IAM Role was created.

External ID

If your role requires an external ID to assume, you can provide the external ID with the role-external-id input

Session tagging and name

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.runid }}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 tothe tag requirements. Particularly, GITHUBWORKFLOW will be truncated if it's too long. IfGITHUBACTOR or GITHUBWORKFLOW 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 #419for more information.

You can skip this session tagging by providingrole-skip-session-tagging as true in the action's inputs:

  uses: aws-actions/configure-aws-credentials@v4
  with:
    role-skip-session-tagging: true

Session policies

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.

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:

  uses: aws-actions/configure-aws-credentials@v4
  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.1.0
  with:
     inline-session-policy: >-
      {
       "Version": "2012-10-17",
       "Statement": [
        {
         "Sid":"Stmt1",
         "Effect":"Allow",
         "Action":"s3:List*",
         "Resource":"*"
        }
       ]
      }

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:

  uses: aws-actions/configure-aws-credentials@v4.1.0
  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.1.0
  with:
     managed-session-policies: |
      arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
      arn:aws:iam::aws:policy/AmazonS3OutpostsReadOnlyAccess

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-idinput 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 theAWS 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 andretry-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

We recommend using GitHub's OIDC providerto 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

1. Configure your workflow to use the id-token: write permission.
2. Configure your audience, if required.
3. In your AWS account, configure IAM to trust GitHub's OIDC identity provider.
4. Configure an IAM role with appropriate claim limits and permission scope.
   Note: Naming your role "GitHubActions" has been reported to not work. See#953.
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:

permissions:
  id-token: write
  contents: read

OIDC Audience

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.1.0
  with:
    audience: sts.amazonaws.com.cn
    aws-region: us-east-3
    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 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.

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.

You can copy the template below, or load it from here:https://d38mtn6aq9zhn6.cloudfront.net/configure-aws-credentials-latest.yml

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

Claims and scoping permissions

To align with the Amazon IAM best practice of granting least privilege, the assume role policy document should contain aConditionthat specifies a subject (sub) allowed to assume the role. GitHub also recommendsfiltering for the correct audience (aud). See AWS IAM documentationon 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. SeeExample subject claimsfor specific details on what the subject value will be depending on your workflow. You can also customize your subject claimif 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 theactions-oidc-debuggeraction 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 OIDC

For further information on OIDC and GitHub Actions, please see:

• AWS docs: Creating OpenID Connect (OIDC) identity providers
• AWS docs: IAM JSON policy elements: Condition
• GitHub docs: About security hardening with OpenID Connect
• GitHub docs: Configuring OpenID Connect in Amazon Web Services
• GitHub changelog: GitHub Actions: Secure cloud deployments with OpenID Connect

Self-Hosted Runners

If you run your GitHub Actions in aself-hosted runner 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 thedefault methods for the AWS SDK for Javascript.

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:

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:

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 usingAmazon EKS IRSA. 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:

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:

Your environment configuration

HTTP_PROXY="http://companydomain.com:3128"

Use with the AWS CLI

This workflow does not install the AWS CLIinto your environment. Self-hosted runners that intend to run this action prior to executing aws commands need to have the AWS CLIinstalledif it's not already present. Most GitHub hosted runner environmentsshould include the AWS CLI by default.

Examples

AssumeRoleWithWebIdentity (recommended)

- name: Configure AWS Credentials
  uses: aws-actions/configure-aws-credentials@v4.1.0
  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 rolearn:aws:iam::123456789100:role/my-github-actions-role with the session nameMySessionName.

AssumeRole with role previously assumed by action in same workflow

- name: Configure AWS Credentials
  uses: aws-actions/configure-aws-credentials@v4.1.0
  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.1.0
  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 rolearn: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.

AssumeRole with static IAM credentials in repository secrets

- name: Configure AWS Credentials
  uses: aws-actions/configure-aws-credentials@v4.1.0
  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 likearn: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.

Retrieving credentials from step output, AssumeRole with temporary credentials

- name: Configure AWS Credentials 1
  id: creds
  uses: aws-actions/configure-aws-credentials@v4.1.0
  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.1.0
  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 ifoutput-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

This code is made available under the MIT license.

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 instructionshere or email AWS security directly.