OIDC Integration between GitHub and AWS
If you think security is paramount, stop using hard-coded cloud provider credentials in your CI/CD pipeline. In this blog, I discuss the steps to integrate GitHub as an OIDC provider in AWS.
Does your GitHub Actions CI/CD pipeline have hard-coded, long-lived cloud-provider credentials for communicating with various cloud services?
Using hardcoded secrets requires creating credentials in the cloud provider and then duplicating them in GitHub as a secret.
On the other hand, OpenID Connect allows your workflows to exchange short-lived tokens directly from your cloud provider.
How it works
Figure1: OIDC Integration between GitHub and AWS
Action Items
Configure GitHub as an OIDC provider in AWS
Figure2: OIDC Provider
Create an IAM policy; here, I give an example of uploading objects to my s3 bucket.
Figure3: IAM Policy
Create an IAM Role of type web Identity. To create a trust policy, you must provide details like GitHub organization, repository(optional) and branch(optional).
Figure4: IAM Role
Copy the Role ARN and create it as a GitHub secret.
Once you've done this, use this official action from the GitHub marketplace: https://github.com/marketplace/actions/configure-aws-credentials-action-for-github-actions. This action uses tokens to authenticate to AWS and access resources.
OIDC Flow
Last, every time a job runs, GitHub’s OIDC Provider auto-generates an OIDC token. The job requires a permissions setting with id-token: write to allow GitHub’s OIDC provider to create a JSON Web Token for every run.
Figure5: OIDC Flow
In your cloud provider, create an OIDC trust between your cloud role and your GitHub workflow(s) that need access to the cloud.
Every time your job runs, GitHub’s OIDC Provider auto-generates an OIDC token. This token contains multiple claims to establish a security-hardened and verifiable identity about the specific workflow that is trying to authenticate.
You could include a step or action in your job to request this token from GitHub’s OIDC provider, and present it to the cloud provider.
Once the cloud provider successfully validates the claims presented in the token, it then provides a short-lived cloud access token that is available only for the duration of the job.
