---
source_url: "https://www.rkon.com/articles/github-actions-on-aws-how-to-implement-identity-federation/"
title: "GitHub Actions on AWS: How to Implement Identity Federation"
mirrored_at: 2026-08-30T01:02:43.010Z
host: www.rkon.com
cited_in_42a: true
mirror_canonical: "https://index.42a.ai/www.rkon.com/articles/github-actions-on-aws-how-to-implement-identity-federation/index"
---

> **Original source:** https://www.rkon.com/articles/github-actions-on-aws-how-to-implement-identity-federation/

![](https://www.rkon.com/wp-content/uploads/2026/01/image-4.png "image")

## Configuring OIDC for GitHub Actions on AWS

GitHub Actions offers a feature that allows workflows to generate signed OpenID Connect tokens, which has exciting implications for anyone using GitHub Actions to manage resources in AWS.

This feature allows secure and seamless integration with AWS IAM and eliminates the need to store and rotate long-term AWS credentials in GitHub.

### GitHub Actions for AWS Workloads: Then & Now

GitHub Actions is a popular and lightweight way to build automation into your software development workflow. Instead of maintaining a [Jenkins](https://www.jenkins.io/) cluster or a [CodeBuild](https://aws.amazon.com/codebuild/) pipeline, developers can put a YAML workflow definition in a [known location](https://docs.github.com/en/actions/quickstart#creating-your-first-workflow) in their repo and be off and running.

Most build jobs finish by publishing an artifact of some kind – be it a compiled executable, a Docker image, or an AMI. Many will also deploy it to a running environment. Below we see an example of a job that builds a Docker image and publishes it to Amazon’s [Elastic Container Registry](https://aws.amazon.com/ecr/) (ECR).

![](https://www.rkon.com/wp-content/uploads/2026/01/build-job-docker-image-to-ecr-Jul-19-2023-09-56-30-9869-AM.webp "build-job-docker-image-to-ecr-Jul-19-2023-09-56-30-9869-AM")

Publishing a Docker image to ECR, or updating a running [ECS](https://aws.amazon.com/ecs/) service, or dropping a compiled binary in S3, or any other action touching AWS resources requires proper credentials. The job must be authenticated and authorized to perform these actions.

Until now, it was necessary to generate long-term credentials and store them somewhere accessible to the build job in GitHub. This often leads to checking AWS credentials into GitHub repos directly through sheer laziness/convenience (please, please [don’t do this](https://www.forbes.com/sites/runasandvik/2014/01/14/attackers-scrape-github-for-cloud-service-credentials-hijack-account-to-mine-virtual-currency/?sh=2638c8963196)).

GitHub [provides a way to store encrypted secrets securely](https://docs.github.com/en/actions/security-guides/encrypted-secrets), but even then – these are long-lived static credentials. Who’s rotating them and how often? I bet you aren’t.

![](https://www.rkon.com/wp-content/uploads/2026/01/github-encrypted-secrets-Jul-19-2023-09-56-31-3416-AM.webp "github-encrypted-secrets-Jul-19-2023-09-56-31-3416-AM")

### The Old Way: IAM Users with Static Credentials

The old approach to generating long-term credentials for GitHub Actions jobs is:

-   Create an [IAM](https://aws.amazon.com/iam/) User for the build job
-   Generate static credentials for that user (the AWS access key / secret key pair)
-   Store them in GitHub (hopefully securely)
-   Retrieve them at build time and set them as environment variables in the build job

Even fairly recent [tutorials](https://medium.com/cloud-recipes/configuring-github-actions-to-access-aws-efb9fe13d722) on the subject promote this approach and automate it for ease of use. This approach does involve some IAM best practices – e.g., having the GitHub User assume-role to acquire permissions, and automating the configuration with code, but it still requires you to generate and store keys.

![](https://www.rkon.com/wp-content/uploads/2026/01/the-old-way-iam-users-with-static-credentials-Jul-19-2023-09-56-30-1177-AM.webp "the-old-way-iam-users-with-static-credentials-Jul-19-2023-09-56-30-1177-AM")

If you’re used to working with security in AWS, you should have some reservations about the big-picture design. IAM [Users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) are generally reserved for living, breathing human beings, whereas we prefer to use IAM Roles for machines and applications.

IAM Users can have web console access and MFA tokens. These are not qualities we generally associate with build jobs. The [documentation for IAM Roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) sums up the distinction nicely:

> …instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it. Also, a role does not have standard long-term credentials such as a password or access keys associated with it. Instead, when you assume a role, it provides you with temporary security credentials for your role session.

### The New Way: GitHub OIDC Identifty Federation

Since GitHub added OpenID Connect (OIDC) support for GitHub Actions (as documented [here](https://github.com/github/roadmap/issues/249 "GitHub added OpenID Connect (OIDC) support for GitHub Actions") on the GitHub Roadmap), we can securely deploy to any cloud provider that supports OIDC (including AWS) using short-lived keys that are automatically rotated for each deployment.

The primary benefits are:

-   No need to store long-term credentials and plan for their rotation
-   Use your cloud provider’s native IAM tools to configure least-privilege access for your build jobs
-   Even easier to automate with Infrastructure as Code (IaC)

![](https://www.rkon.com/wp-content/uploads/2026/01/the-new-way-oidc-identity-federation-Jul-19-2023-09-56-29-3998-AM.webp "the-new-way-oidc-identity-federation-Jul-19-2023-09-56-29-3998-AM")

Now, your GitHub Actions job can acquire a JWT from the GitHub OIDC provider, which is a signed token including various details about the job (including what repo the action is running in).

If you’ve configured AWS IAM to trust the GitHub OICD provider, your job can exchange this JWT for short-lived AWS credentials that let it assume an IAM Role. With those credentials, your build job can use the AWS CLI or APIs directly to publish artifacts, deploy services, etc.

### How to Implement Identity Federation Using GitHub OIDC Actions on AWS

Enough talk. Let’s see some code. Here’s some IaC to help you implement this solution yourself.

#### Step 1: Add the Identity Provider to AWS

You’ll need to configure IAM in your AWS account to trust tokens presented by the GitHub OIDC provider before your jobs can trade them for AWS credentials. AWS provides documentation for setting this up with the web console [here](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html), but we want to do this with code:

##### Terraform

##### CloudFormation

Note that in both flavors of the configuration, we specify the `ClientIdList` as `sts.amazonaws.com` – this will be the “audience” claim presented in the JWT when we use the [official action](https://github.com/aws-actions/configure-aws-credentials) to obtain credentials later on.

#### Step 2: Configure an Assume-Role Policy

Now that IAM is configured to trust tokens presented by the GitHub OIDC provider, we now need to create an IAM Role for our build jobs to use and tell IAM that it can be assumed by anyone with a valid token from that provider.

##### Terraform

##### CloudFormation

Note how in both configuration blocks, we put a condition on the assume-role policy that the `token.actions.githubusercontent.com:sub` claim must match a string with our GitHub org and repo in it.

This claim will be present in the JWT with a format like `repo:my-org/my-repo:ref:refs/heads/my-branch`. Adding this condition ensures that only jobs running in your own GitHub repos can assume this role. Without it, any valid token from any GitHub action could get these AWS credentials.

You can further narrow scope with this condition to ensure that specific jobs can only be run by GitHub actions in specific repos, or specific branches. See additional information about hardening this configuration in the [official docs from GitHub](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services).

#### Step 3: Assume-role in GitHub Actions

GitHub provides an [official Action](https://github.com/aws-actions/configure-aws-credentials) that we can use to assume a specific AWS IAM role in a workflow. The syntax is as simple as:

Here’s an example workflow that assumes the GitHubActionsRole we defined and uses the AWS CLI to prove that it has acquired valid credentials.

Here we just use `aws sts-get-caller-identity` as proof that the assume-role flow worked, but you can substitute anything your assumed role has permission to do. e.g., if you’ve granted permission to write to S3, you could:

#### Step 4: Profit

If you’ve set everything up correctly, you should see output like the following in the GitHub Actions console when you run the proof of concept job above.

-   Restrict specific actions to a specific identity
    -   Some actions may be restricted to ensure only specific identities, such as an IAM role are able to perform given actions in your Organization.
    -   For example, to allow only your Terraform Pipeline’s IAM role to create and delete VPCs:

![](https://www.rkon.com/wp-content/uploads/2026/01/github-actions-console-output-Jul-19-2023-09-56-29-8113-AM.webp "github-actions-console-output-Jul-19-2023-09-56-29-8113-AM")

### Learn More About AWS Cloud Solutions From RKON

Hopefully, this has been a useful example of how to configure your GitHub Actions build jobs to securely and seamlessly use IAM Roles in AWS. If you’re using another cloud provider like Google Cloud Platform (GCP) or Microsoft Azure, or if you want to integrate it with HashiCorp Vault – check the official GitHub documentation [here](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments).

If you’re looking for a cloud security and compliance expert to help lead the charge, [connect with our team at RKON](https://scalesec.com/connect/ "Connect with our team at ScaleSec"). We specialize in cloud security engineering and cloud compliance, so we’re happy to guide you through any complex cloud challenges you encounter.