Forem: Chinedu Oji

Authenticating GitHub Actions to AWS using IAM Roles

Chinedu Oji — Tue, 03 Feb 2026 23:50:17 +0000

We've all been there: creating AWS access keys for authentication, worrying about keeping them safe, and trying to remember to rotate them periodically.
But do we really need to use long-lived access keys for every situation? For GitHub Actions, the answer is no.
In this article, you'll learn how to authenticate a GitHub Actions workflow to AWS using IAM roles and OpenID Connect (OIDC). This approach lets you eliminate access keys and avoid manually rotating them.

✅Prerequisites:

You need the following:

An AWS account with sufficient IAM permissions.
A GitHub repository

🔐Step 1: Create an OpenID Connect Provider in your AWS account

An IAM identity provider (IdP) enables AWS to trust identities that originate outside AWS. In this step, you create an OpenID Connect (OIDC) provider that allows GitHub Actions to request temporary AWS credentials.

Go to the IAM Console
Click Identity Providers in the left navigation menu
Click Add Provider and select OpenID Connect as the provider type
For Provider URL, enter token.actions.githubusercontent.com
For Audience enter: sts.amazonaws.com
Click Add provider to create the Identity Provider

🧩Step 2: Create an IAM role

The IAM role defines what GitHub Actions can access in your AWS account. You will also scope the role's trust policy so that only a specific GitHub organisation, repository, and branch can assume the role.

Select the Identity Provider you just created
Click the Assign Role button and choose Create a new role
For the Trusted entity type, Web Identity is already pre-selected, and the Identity provider field is populated with the IdP you just created
In the Audience list, select sts.amazonaws.com
Fill in the GitHub Organisation, Repository, and Branch according to your needs and click Next
For the permissions, we will add them after we have created the role, so click Next
On the Review page, add a role name GitHub-Actions-Role and optionally add a description
Click Create role after reviewing the role details

🔑Step 3: Assign Permissions to the role

For this example, the workflow uploads files to Amazon S3, so the role requires S3 permissions.

In the dashboard of the newly created role, select Add permissions → Create inline policy
Change the view from Visual to JSON
Paste the following policy and click Next

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:PutObjectAcl",
                "s3:GetObject"
            ],
            "Resource": "arn:aws:s3:::your-bucket-name/*"
        }
    ]
}

Name the policy S3-permissions and click Create policy.

⚙️Step 4: Create your GitHub Action

In this step, we will create a GitHub Actions workflow that will authenticate to AWS and upload a file to S3.
Create a file in your repository at .github/workflows/s3-upload.yml

name: Upload File to S3

on:
  push:
    branches: [ main ]

env:
  AWS_REGION: us-east-1 #Change to reflect your Region

jobs:
  upload:
    runs-on: ubuntu-latest

    # This allows the actions to get temporary credentials
    permissions:
      id-token: write
      contents: read

    steps:
    - name: Checkout code
      uses: actions/checkout@v4

    - name: Configure AWS credentials
      uses: aws-actions/configure-aws-credentials@v5
      with:
        role-to-assume: arn:aws:iam::YOUR-ACCOUNT-ID:role/YOUR-ROLE-NAME
        aws-region: ${{ env.AWS_REGION }}

    - name: Upload files to S3
      run: |
        aws s3 cp ./your-file s3://your-bucket-name/

Replace the following values:

YOUR-ACCOUNT-ID with your AWS Account ID
YOUR-ROLE-NAME with the name of the role you created
your-file with the file you want to upload
your-bucket-name with your s3 bucket name

📌Summary

You have now configured GitHub Actions to authenticate to AWS using an IAM role and OIDC, eliminating the need for long-lived access keys.

🛠️Troubleshooting

If the workflow fails, verify the following:

The IAM role has the required permissions.
The GitHub organisation, repository, and branch values in the role trust policy are correct.
The workflow includes the id-token: write permission.

Tackling the Cloud Resume Challenge

Chinedu Oji — Wed, 12 Jun 2024 15:47:47 +0000

Introduction

In this article, I give an overview of the steps and challenges I underwent to complete the Cloud Resume Challenge.
After learning much about AWS and various DevOps tools, I decided it was time to build real projects so I started searching for good projects to implement. While searching, I came across the Cloud Resume Challenge by Forrest Brazeal and decided to try it out.
The Cloud Resume Challenge is a hands-on project designed to help bridge the gap from cloud certification to cloud job. It incorporates many skills that real cloud and DevOps engineers use daily.
This challenge involves hosting a personal resume website with a visitor counter on Amazon s3, configuring HTTPS and DNS, and setting up CI/CD for deployment. Sounds easy right? That's an oversimplification of the project. In reality, it involves interacting with a lot of tools and services. As a DevOps Engineer, all interactions with AWS should be done with IaC.
I will divide this post into 3 sections;

FrontEnd
Backend
IaC and CI/CD

FrontEnd

The FrontEnd part of the project involved the following steps;

Designing the FrontEnd with HTML and CSS
To design the FrontEnd, I took HTML and CSS crash courses to understand the fundamentals which helped me design a basic resume page. I am not a designer by any means or someone with an artistic eye, so my original design was as horrible as expected.

After seeing how ugly and bland the site was, I decided to go with an already made template. Deciding to use this template brought about a problem later on in the project which I will get into in the IaC section.
After making the necessary edits to the template, my site was ready, and it was time to move to the next step.
Hosting on Amazon S3 as a static website
To interact with AWS, I created an IAM user specifically for the project and gave that user access to only the required tools to enhance security. I created an S3 bucket and manually uploaded the files for my website, configured the bucket to host a static website and got the output URL. That was okay for hosting the site, but the project requires you to go further by using a custom domain name.
Configuring HTTPS and DNS
I registered my domain name with Whogohost, a local Hosting and Domain Registration Company and used Amazon Certificate Manager to request an SSL/TLS certificate for my domain. I also set up a CloudFront distribution to cache content and improve security by redirecting HTTP traffic to HTTPS. After doing all that, my domain name still wasn't pointing to my resume site so I did some digging and found that you have to create a CNAME record with your DNS provider that points that domain to the CloudFront distribution.
images of Cloudfront and ACM

My website https://resume.chxnedu.xyz was finally accessible and online.
The result of the FrontEnd section is a static resume website with an HTTPS URL that points to a CloudFront Distribution.

BackEnd

The BackEnd section of the project involves setting up a DynamoDB table to store and update the visitor count, setting up an API as an intermediary between the web app and the database, writing Python code for a lambda function that will save a value to the DynamoDB table, and writing tests to ensure the API is always functional. The steps I took;

Setting up the DynamoDb table
The DynamoDB table was simple. It just needs to hold the value of the visitor count. I used the AWS Console to create the table, then created an item and gave it a number attribute with the value of 1.
Setting up the Lambda function and writing Python code
Lambda is an event-driven, serverless computing platform provided by AWS. It is perfect for this use case because it only needs to run when the website is visited which will trigger the visitor counter. I created a lambda function and used Python to write the code. The Python code updates the visitor counter's value by 1 and displays the new value as output. After testing the code and confirming it works as expected, I needed to find the right trigger for the lambda function.
Placing an API Gateway in front of the lambda function
Having the javascript code directly communicate with the DynamoDB table is not a good practice, and that's why we created the Lambda function to update the table. Instead of having the javascript code directly trigger the lambda function, an API is implemented. This API ensures that a call to an endpoint by the javascript code triggers the lambda function to run and outputs the new value of the visitor counter. I used AWS API Gateway to create the API and configured an /update_count endpoint, which when called, triggers the Lambda function to run.
Setting up alarms and Writing a good test for the API
As an engineer, you always need to know when your code encounters an issue, and you can't be checking your deployment every minute of the day. Some tools will monitor your deployment and alert you when errors are encountered. To monitor my deployment I used AWS CloudWatch because of how it easily integrates with AWS services. The metrics I configured CloudWatch to alert me about;
- The function invocation crashes or throws an error
- The latency or response time is longer than usual
- The Lambda function is invoked many times in a short period. I set the three alarms up on CloudWatch and tested the first metric by changing my code a bit, and it worked.
Writing Javascript code for the visitor counter
To write the Javascript code, I took a crash course and did a lot of research. I wrote a short javascript code that fetches the current visitor count from the API endpoint and displays it on the website.

After I completed those steps, the FrontEnd and the BackEnd were seamlessly integrated, and a visit to the website will update the visitor counter and display the current count.

IaC and CI/CD

All my interactions with AWS have been through the web console, and as a DevOps engineer that is unacceptable.
I created separate repositories to store my FrontEnd and Backend files and configured GitHub Actions in each repository to run Terraform and a Cypress test. Terraform Cloud was used for the backend because of the seamless integration with my GitHub repository.
While writing Terraform configurations for my resources, I encountered the problem mentioned earlier in the article.
After creating an S3 bucket with Terraform, the files need to be uploaded to the bucket and that is done so by creating a Terraform resource for each file. Now I have a whole file tree that I need to upload, which meant I would have to do that manually for each file and folder. After some research and digging, I found a blog post that shows how to upload file trees cleverly using some Terraform functions. I implemented this method and had the whole file tree uploaded to the S3 bucket.
Using GitHub Actions, a push to each repository triggers a run that applies my Terraform configuration and runs a Cypress test.

With all these setups, I successfully implemented the Cloud Resume Challenge with a DevOps spin.