GitHub Actions OIDC Integration with AWS: Eliminating Long-Lived Credentials in CI/CD

Continuous integration and continuous deployment (CI/CD) pipelines are central to modern software delivery. As organisations scale their use of GitHub Actions to deploy workloads on AWS, the question of how these pipelines authenticate with cloud services becomes critically important. Traditionally, this has been handled through long-lived IAM access keys stored as GitHub secrets, an approach that introduces significant security risk.

OpenID Connect (OIDC) integration between GitHub Actions and AWS offers a fundamentally better model. By replacing static credentials with short-lived, automatically rotated tokens, OIDC eliminates an entire category of credential management challenges.

The Problem with Long-Lived Credentials

In a traditional setup, deploying to AWS from GitHub Actions requires creating an IAM user, generating an access key and secret, and storing those values as repository or organisation secrets. While functional, this approach carries well-documented risks:

• Credential exposure: Long-lived access keys can be inadvertently leaked through logs, error messages, or misconfigured repositories. Once exposed, they provide persistent access until manually revoked.
• Manual rotation burden: Security best practices dictate regular key rotation. In practice, this is frequently neglected, leaving stale credentials active for months or years.
• Broad access scope: IAM users with access keys often accumulate permissions over time, violating the principle of least privilege.
• Audit complexity: Tracing which pipeline run used which credential, and what actions it performed, becomes difficult when multiple workflows share the same static keys.
• Revocation lag: When a team member departs or a repository is archived, the associated credentials may not be promptly deactivated, creating an extended window of risk.

These challenges are not theoretical. Credential leakage from CI/CD pipelines is a recurring theme in cloud security incidents.

What Is OIDC and How Does It Work with GitHub Actions?

OpenID Connect (OIDC) is an identity layer built on top of the OAuth 2.0 protocol. It enables one service (the identity provider) to assert the identity of a user or workload to another service (the relying party) without sharing credentials directly.

In the context of GitHub Actions and AWS, the flow operates as follows:

1. GitHub as Identity Provider: GitHub Actions acts as the OIDC identity provider. Each workflow run receives a unique, short-lived JSON Web Token (JWT) issued by GitHub.
2. Token contents: The JWT contains claims that describe the workflow context, including the repository, branch, environment, workflow name, and the actor who triggered the run.
3. AWS as Relying Party: An IAM role in AWS is configured to trust GitHub’s OIDC provider. The role’s trust policy specifies which repositories, branches, or environments are permitted to assume the role.
4. Token exchange: During the workflow run, the GitHub Actions runner presents its JWT to AWS Security Token Service (STS). AWS validates the token against GitHub’s OIDC provider, verifies the claims match the trust policy conditions, and issues temporary AWS credentials.
5. Scoped, short-lived access: The temporary credentials are valid only for the duration of the workflow run and carry only the permissions defined in the IAM role’s policy.

At no point are long-lived credentials stored, transmitted, or managed manually. The entire authentication lifecycle is automated and ephemeral.

Benefits of OIDC Integration

Elimination of Static Credentials

The most immediate benefit is the removal of long-lived access keys from the CI/CD pipeline entirely. There are no secrets to store, rotate, or risk leaking. This addresses the single largest attack surface in traditional GitHub Actions-to-AWS authentication.

Stronger Security Posture

OIDC enables precise control over which workflows can access which AWS resources. Trust policies can be scoped to:

• A specific repository (repo:organisation/repository)
• A specific branch (ref:refs/heads/main)
• A specific GitHub environment (environment:production)
• A specific workflow file

This granularity ensures that only authorised pipeline runs, from authorised contexts, can assume the associated IAM role. A feature branch workflow cannot assume a production deployment role unless explicitly permitted.

Simplified Credential Management

With OIDC, there are no IAM users to create, no access keys to generate, and no secrets to distribute across repositories. This reduces operational overhead and eliminates a common source of configuration drift, where different repositories reference different credentials with inconsistent permission sets.

Improved Auditability

Every role assumption through OIDC is logged in AWS CloudTrail with full context: the GitHub repository, branch, workflow, and run ID. This creates a clear, traceable link between a specific pipeline execution and the actions it performed in AWS, significantly simplifying compliance and incident investigation.

Reduced Blast Radius

Because temporary credentials expire automatically and are scoped to a single workflow run, the impact of any potential compromise is inherently limited. An attacker who gains access to a workflow’s credentials has a narrow window and a constrained set of permissions, in contrast to a long-lived access key that may grant broad access indefinitely.

Alignment with Zero Trust Principles

OIDC-based authentication aligns with Zero Trust security models by requiring verification of identity and context for every access request. No implicit trust is granted based on possession of a static credential. Each workflow run must independently prove its identity and satisfy the conditions defined in the trust policy.

Implementation Overview

Setting up OIDC integration between GitHub Actions and AWS involves three primary components:

1. Configure the OIDC Identity Provider in AWS

An OIDC identity provider is registered in AWS IAM, pointing to GitHub’s token endpoint (https://token.actions.githubusercontent.com). This establishes the trust relationship between AWS and GitHub as an identity issuer.

2. Create an IAM Role with a Trust Policy

An IAM role is created with a trust policy that specifies which GitHub repositories, branches, or environments are permitted to assume the role. The trust policy evaluates the claims in the JWT to enforce these conditions.

An example trust policy condition:

{
  "Condition": {
    "StringEquals": {
      "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
    },
    "StringLike": {
      "token.actions.githubusercontent.com:sub": "repo:your-org/your-repo:ref:refs/heads/main"
    }
  }
}

This ensures only the main branch of a specific repository can assume the role.

3. Update the GitHub Actions Workflow

The workflow is configured to request an OIDC token and use it to assume the IAM role. With the aws-actions/configure-aws-credentials action, the configuration is straightforward:

permissions:
  id-token: write
  contents: read

steps:
  - name: Configure AWS credentials
    uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsRole
      aws-region: eu-west-1

No access keys are referenced anywhere in the workflow. Authentication is handled entirely through the OIDC token exchange.

Best Practices

To maximise the security benefits of OIDC integration, consider the following:

• Scope trust policies narrowly. Restrict role assumption to specific repositories, branches, and environments rather than using broad wildcard patterns.
• Use GitHub Environments. Environments provide an additional layer of control, enabling approval gates and environment-specific trust policies for sensitive deployments such as production.
• Apply least-privilege IAM policies. The IAM role assumed via OIDC should carry only the permissions necessary for the specific deployment workflow.
• Monitor with CloudTrail. Regularly review role assumption events to detect unexpected access patterns or policy violations.
• Separate roles by environment. Maintain distinct IAM roles for development, staging, and production deployments, each with appropriately scoped permissions and trust conditions.
• Avoid overly permissive subject claims. Using repo:org/repo:* as a subject condition permits any branch or tag to assume the role. Prefer explicit branch or environment conditions where possible.

When to Adopt OIDC for GitHub Actions

OIDC integration is recommended for any organisation using GitHub Actions to deploy to AWS. The benefits are particularly significant for teams that:

• Manage multiple repositories deploying to shared or separate AWS accounts.
• Operate in regulated environments where credential management and auditability are subject to compliance requirements.
• Follow Zero Trust or defence-in-depth security strategies.
• Have experienced credential rotation challenges or secret sprawl across repositories.
• Are adopting or expanding the use of GitHub Environments for deployment governance.

For organisations currently relying on long-lived access keys in their CI/CD pipelines, migrating to OIDC represents one of the highest-impact, lowest-effort security improvements available.

Conclusion

OIDC integration between GitHub Actions and AWS addresses a fundamental weakness in traditional CI/CD authentication: the reliance on static, long-lived credentials. By leveraging short-lived tokens, scoped trust policies, and automated credential management, organisations can significantly strengthen their security posture while reducing operational complexity.

At Parsectix, we help organisations design and implement secure CI/CD pipelines on AWS, including OIDC-based authentication for GitHub Actions. Whether you are building new deployment workflows or hardening existing ones, our team can ensure your pipelines follow security best practices from the outset.