In this article, you will learn how to connect your GitHub Actions to AWS using OpenID Connect rather than storing your AWS Secret and Access Keys in Github Actions secrets and will know why it is a secure way to go through this process. The use of OIDC allows for secure authentication and authorization when accessing AWS resources, while Github Actions provides a streamlined way to automate the deployment process.

What is OpenID Connect??

GitHub Actions workflows are often designed to access a cloud provider (such as AWS, Azure, GCP, or HashiCorp Vault) in order to deploy software or use the cloud’s services. To access cloud resources, it will supply credentials, such as a password or token, to the cloud provider. These credentials are usually stored as a secret in GitHub, and the workflow presents this secret to the cloud provider every time it runs.

However, using hardcoded secrets requires you to create credentials in the cloud provider and then duplicate them in GitHub as a secret.

In AWS, OpenID Connect (OIDC) is a protocol that allows a user to authenticate with an identity provider (IdP) such as Google or Facebook and then obtain a token that can be used to authenticate with AWS resources. OIDC allows for secure authentication and authorization when accessing AWS resources, such as Amazon S3 or Amazon EC2. Users can use the OIDC-compatible identity provider of their choice and use the token obtained from the IdP to assume an AWS Identity and Access Management (IAM) role, which grants them permissions to access specific resources in AWS. This allows for a more secure way for users to access AWS resources, as it eliminates the need to use long-term AWS credentials.

Benefits of using OIDC

By updating your workflows to use OIDC tokens, you can adopt the following good security practices:

• Secure authentication: OIDC allows for secure authentication of users by using an identity provider (IdP) such as Google or Facebook. This eliminates the need for users to manage long-term AWS credentials, which can be a security risk.
• Single Sign-On (SSO): OIDC enables Single Sign-On (SSO) for users, allowing them to authenticate once with an IdP and then access multiple applications and services without having to re-enter their credentials.
• User information: OIDC provides additional user information such as the user’s name and email address, which can be used by applications to personalize the user experience and provide customized access.
• Better Access Control: OIDC allows for a more fine-grained access control to resources by providing the capability to use IAM roles to grant users access to specific resources based on their authentication and authorization status.
• Integration: OIDC is built on top of the OAuth 2.0 framework, which is widely supported by many identity providers and applications, making it easy to integrate with existing systems.
• Compliance: OIDC meets several industry standards and regulatory requirements for user authentication and authorization, such as SOC 2, HIPAA, and PCI DSS.
• No cloud secrets: You won’t need to duplicate your cloud credentials as long-lived GitHub secrets. Instead, you can configure the OIDC trust on your cloud provider, and then update your workflows to request a short-lived access token from the cloud provider through OIDC.
• Authentication and authorization management: You have more granular control over how workflows can use credentials, using your cloud provider’s authentication (authN) and authorization (authZ) tools to control access to cloud resources.
• Rotating credentials: With OIDC, your cloud provider issues a short-lived access token that is only valid for a single job, and then automatically expires.

Getting started with OIDC

So, when you run a job with an action : configure-aws-credentials . Github Actions takes the role which is mentioned in role-to-assume and request for a token from AWS cloud. It requests an OIDC token from GitHub’s OIDC provider, which responds with an automatically generated JSON web token (JWT) that is unique for each workflow job where it is generated. When the job runs, the OIDC token is presented to the cloud provider. To validate the token, the cloud provider checks if the OIDC token’s subject and other claims are a match for the conditions that were preconfigured on the cloud role’s OIDC trust definition. If all validations are correct then AWS generates a temporary token and sends to github actions so that it can use to deploy resources in AWS Cloud.

The JWT contains all parameters like repo name, branch name , owner of repository.

Step by Step process of creating OpenID Connect in AWS

Go to AWS Console , then go to IAM > Identity providers > Choose OpenID Connect > Add Provider URL of Github Actions

https://token.actions.githubusercontent.com and click on Thumbprint

and add audience as “sts.amazonaws.com” and click create.

Then create a role assuming the identity role created just now

Then choose Web Identity and choose the identity provider and audience from the dropdown and click Next

Add Admin policy which you want to give access to Github Actions . For now I have added “AdministratorAccess”.

Then edit the trust policy and inside conditions add “StringLike” which is used with a wildcard operator to allow any branch, pull request merge branch, or environment from the “Devopshublab/github-actions-openid-connect” organization and repository to assume a role in AWS. You need to add the repository name in the “token.actions.githubusercontent.com:sub” field.

Here ”repo: Devopshublab /github-actions-openid-connect:*” means any branch or merge branch can use this role for deploying resources . If you want to use any specific branch to assume the role then add “repo: Devopshublab /github-actions-openid-connect:ref:refs/heads/branchName”.

Then add the role name and description and create the role.

This block of code we are adding into the Github workflow pipeline to connect Github with AWS.

– name: Connecting GitHub Actions To AWS Using OIDC – Roles
uses: aws-actions/configure-aws-credentials@v1
with:
aws-region: us-east-1
role-to-assume: arn:aws:iam::<account-id>:role/github-actions-openid-role
role-session-name: github-actions-session

Here, we are going to add aws-region where you are going to deploy or create your resources and in role-to-assume, we will be adding the role arn that we created and role-session we can put any name.