Stop Using Access Keys: Securing CI/CD with GitHub Actions and AWS OIDC

In the world of DevOps, managing secrets is often the proverbial elephant in the room. For years, the standard practice for connecting GitHub Actions to Amazon Web Services (AWS) involved generating an IAM User, downloading the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY, and stuffing them into GitHub Secrets. While this works, it creates a significant security liability: long-lived credentials.

Long-lived keys are static targets. If they are accidentally committed to a repository, logged in a build artifact, or compromised via a developer's machine, your cloud infrastructure is immediately at risk. The industry solution? Going keyless.

At Nohatek, we prioritize security-first architecture. In this guide, we explore how to eliminate static credentials by leveraging OpenID Connect (OIDC). This allows GitHub Actions to request short-term, temporary credentials from AWS, significantly reducing your attack surface and simplifying credential management.

The Problem with Long-Lived Credentials

Before diving into the solution, it is vital for CTOs and Lead Developers to understand why the traditional method is flawed. When you use IAM User Access Keys in your CI/CD pipeline, you are essentially creating a permanent backdoor into your AWS environment.

• Rotation Fatigue: Security best practices dictate that keys should be rotated every 90 days. In a microservices architecture with dozens of repositories, manually rotating keys becomes an operational nightmare that teams often ignore.
• The Leakage Risk: A static key is valid until explicitly revoked. If a key leaks on a Friday night, attackers have the entire weekend to exploit resources before an admin notices.
• Lack of Granularity: Often, keys are associated with generic IAM users that accumulate permissions over time ('permission creep'), granting the CI/CD pipeline more access than it needs.

'Static credentials are the number one cause of cloud security breaches. Moving to ephemeral credentials isn't just a trend; it's a necessity for modern compliance.'

By shifting to OIDC, we move from 'what you have' (a static key) to 'who you are' (a trusted identity verified by GitHub).

How OIDC Works: The Digital Handshake

OpenID Connect (OIDC) is an identity layer on top of the OAuth 2.0 protocol. In this context, it allows GitHub to act as an Identity Provider (IdP) that AWS trusts. Instead of storing a key, you create a trust relationship.

Here is the workflow of a keyless authentication process:

1. Initiation: When your GitHub Action job starts, it requests a JSON Web Token (JWT) from GitHub's OIDC provider.
2. The Token: This token contains claims—specific details about the job, such as the repository name, the branch (e.g., main), and the workflow triggering the event.
3. Exchange: The GitHub Action sends this token to AWS Security Token Service (STS).
4. Verification: AWS validates the token's signature against GitHub's public keys and checks if the claims match the IAM Trust Policy you defined.
5. Access Granted: If everything matches, AWS issues temporary, short-lived credentials (valid for only one hour by default) to the runner.

Once the job finishes, those credentials expire automatically. There is nothing to rotate, nothing to revoke, and nothing to steal.

Step-by-Step Implementation Guide

Let's get practical. Implementing this requires two main components: configuring AWS to trust GitHub, and updating your GitHub Actions workflow.

1. Configure AWS Identity Provider

First, you need to tell AWS that GitHub is a trusted entity. You can do this via the AWS Console (IAM > Identity providers) or via Infrastructure as Code (IaC). Here is how you do it in Terraform:

resource "aws_iam_openid_connect_provider" "github" {
  url             = "https://token.actions.githubusercontent.com"
  client_id_list  = ["sts.amazonaws.com"]
  thumbprint_list = ["6938fd4d98bab03faadb97b34396831e3780aea1"]
}

2. Create the IAM Role and Trust Policy

Next, create an IAM Role that the GitHub Action will assume. The critical part is the Trust Policy. You must lock this down to your specific repository to prevent other GitHub users from assuming your role.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::ACCOUNT_ID:oidc-provider/token.actions.githubusercontent.com"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringLike": {
                    "token.actions.githubusercontent.com:sub": "repo:YourOrg/YourRepo:*"
                }
            }
        }
    ]
}

Note: The sub (subject) claim is your security boundary. Always restrict it to your specific organization and repository.

3. Update GitHub Actions Workflow

Finally, update your YAML file. You need to grant the workflow permission to request the ID token using permissions: id-token: write.

name: Deploy to AWS

on: [push]

permissions:
  id-token: write # Required for requesting the JWT
  contents: read  # Required for actions/checkout

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          role-to-assume: arn:aws:iam::123456789012:role/GitHubActionRole
          aws-region: us-east-1

      - name: Run AWS Commands
        run: aws s3 ls

With this configuration, the configure-aws-credentials action handles the heavy lifting of the OIDC handshake automatically.

Strategic Benefits for Enterprise Architecture

For CTOs and decision-makers, the shift to OIDC is not just a technical upgrade; it is a strategic compliance move. Adopting keyless authentication directly supports several pillars of the AWS Well-Architected Framework.

• Auditability: CloudTrail logs will now show the specific IAM Role being assumed, and the userIdentity will include the GitHub repository and workflow details. This makes forensic auditing significantly easier compared to seeing a generic user action.
• Compliance Readiness: Frameworks like SOC2, ISO 27001, and HIPAA rigorously check for credential management. Eliminating long-lived keys removes a major item from your risk register.
• Scalability: Onboarding new microservices becomes templated. You define the IAM role via Terraform, and the repository is ready to deploy. There is no manual step of generating keys and pasting them into secrets managers.

At Nohatek, we integrate these patterns into our client's foundational infrastructure. Whether you are building AI pipelines or standard web applications, security should be intrinsic to the pipeline, not an afterthought.

Transitioning to keyless authentication with GitHub Actions and AWS OIDC is one of the highest-value security improvements you can make in your CI/CD pipeline. It eliminates the operational burden of key rotation, mitigates the risk of credential leakage, and provides granular control over who—and what—can access your cloud resources.

Security is an evolving landscape. If your organization is looking to modernize its DevOps practices, secure its cloud infrastructure, or accelerate development with AI-driven solutions, Nohatek is here to help. Let's build something secure, scalable, and exceptional together.