Other Articles

How to Use OIDC for Secure AWS Deployment with GitHub Actions?

Support > AWS > CI/CD & Security

March 20, 2026

Overview

This article explains how to securely deploy applications to AWS using OpenID Connect (OIDC) with GitHub Actions. OIDC eliminates the need to store long-lived AWS credentials by enabling GitHub to request temporary access tokens during deployment.

This approach improves security, reduces the risk of credential exposure, and ensures that deployments follow modern DevOps best practices.

Prerequisites

  • You have an active AWS account with access to IAM
  • You have a GitHub repository with GitHub Actions enabled
  • You have permissions to create IAM roles and identity providers in AWS
  • You understand your deployment target (ECR, ECS, EC2, or S3)
  • Your application is ready for deployment via CI/CD

What OIDC Enables

OIDC enables secure authentication without storing long-lived credentials.
  • Authenticate GitHub workflows directly with AWS
  • Use short-lived credentials instead of static access keys
  • Restrict access to specific repositories and branches
  • Perform secure deployments to AWS services
  • Maintain auditability through AWS logs

Steps to Configure OIDC for AWS Deployment

Step 1: Create OIDC Identity Provider in AWS

  • Go to IAM → Identity Providers
  • Click Add provider
  • Select OpenID Connect
  • Provider URL: https://token.actions.githubusercontent.com
  • Audience: sts.amazonaws.com

Step 2: Create IAM Role for GitHub

  • Go to IAM → Roles → Create role
  • Select Web identity
  • Choose the Identity provider
  • Choose the Audience
  • Enter GitHub Organization name
  • Enter GitHub repository (recommended for security)
  • Enter GitHub branch (recommended to restrict deployments)
  • Ensure you restrict access to a specific repository and branch to prevent unauthorized deployments
  • Click Next
  • In the "Add Permission Policies" step, select the following:
    • Avoid attaching full access policies such as AmazonS3FullAccess or AmazonECS_FullAccess
    • Create custom IAM policies with only required permissions
    • Grant access only to specific resources (e.g., specific S3 bucket, ECR repository, or ECS service)
    • Follow the principle of least privilege
  • Click Next
  • Enter Role name
  • Create Role
Note: As a security best practice, always restrict the IAM role to a specific GitHub repository and branch using conditions in the trust policy. This ensures that only authorized workflows can assume the role.

Example: Instead of full S3 access, allow only required actions:

{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject"
],
"Resource": "arn:aws:s3:::your-bucket-name/\*"
}

Example: Trust Policy Restriction:

"Condition": {
  "StringEquals": {
    "token.actions.githubusercontent.com:sub": "repo:your-username/your-repo:ref:refs/heads/main"
  }
}

Step 3: Configure GitHub Actions Workflow

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::<ACCOUNT_ID>:role/<ROLE_NAME>
  aws-region: ap-south-1

This step allows GitHub Actions to securely assume the IAM role using OIDC without storing AWS credentials.

Step 4: Deploy to AWS

  • Build and push Docker images to Amazon ECR
  • Deploy applications to ECS or EC2
  • Upload files to S3

After the Setup

  • Secure authentication without stored credentials
  • Use of temporary AWS credentials
  • Controlled access via IAM conditions
  • Audit logs available in AWS

Security Best Practices

  • Always restrict IAM roles to specific GitHub repositories and branches using trust policy conditions
  • Follow the principle of least privilege by avoiding full access policies
  • Grant access only to required AWS resources instead of using wildcard (*) permissions
  • Rotate and review IAM roles and policies regularly
  • Monitor activity using AWS CloudTrail

Troubleshooting

  • OIDC not working: Ensure id-token: write is set
  • Access denied: Check IAM trust policy
  • Deployment fails: Verify permissions
  • Incorrect role ARN: Ensure correct role is used