Enhanced Security - Safeguarding AWS Access in GitHub Actions ๐Ÿชช

ยท

2 min read

Enhanced Security - Safeguarding AWS Access in GitHub Actions ๐Ÿชช

The fastest way to access AWS infrastructure from a GitHub Actions workflow is by utilizing AWS_ACCESS_KEY and AWS_SECRET_ACCESS_KEY. This method requires manually storing the access keys as GitHub secrets.

While this method is quick, it poses challenges in collaborative environments, as someone (or an automated process) must handle these secrets, creating a potential vulnerability with direct access to the credentials.

Static credentials method โŒ:

A more secure method to authenticate to AWS is by implementing OIDC (OpenID Connect) authentication. This approach eliminates the need for static credentials and introduces a resilient and secure way to access AWS resources.

Evolution โœ…:

By leveraging OIDC authentication, we have control over which GitHub repositories can access and deploy to AWS directly from the IAM role.


In practice ๐Ÿ”ง

In this tutorial, we'll focus on how to enable OIDC and create a compatible IAM role using Terraform.

Create OIDC identity provider and IAM role in AWS

The code utilizes the tls_certificate data to retrieve the thumbprint of Github's Certificate Authority. This thumbprint is then used by the OIDC provider to verify the identity of the caller.

Create an IAM role that will be used by the workflow

The code creates an IAM role that trusts the Github OIDC provider for authentication. The above code allows access to all repositories in your GitHub organization/account. However, you can enhance security and be more granular by specifying a particular repository, for example: repo:Potato-Org/french-fries:*.

Use OIDC enabled role in GitHub Actions workflow ๐Ÿš€

For meaningful auditing through CloudTrail, it's a good idea to assign the GitHub repository's name as the session name role-session-name: ${{github.event.repository.name}}


Advanced configuration

You might encounter the following error OpenIDConnect provider's HTTPS certificate doesn't match configured thumbprint

Explanation
This issue is caused because we are relying on a single intermediary thumbprint from the Certificate Authority (CA) that GithHub Actions uses. As of 2023, there are two possible intermediary certificates the servers can return 1c58a3a8518e8759bf075b76b750d4f2df264fcd & 6938fd4d98bab03faadb97b34396831e3780aea1. To solve this, we need to trust both thumbprints in AWS.

Change the Terraform code that sets up the OIDC provider as follows:

Note: data.tls_certificate.github_actions will get one of the up-to-date thumbprint of the intermediate Certificate Authority. To avoid duplicates with local.github_actions_thumbprints, we use the distinct function to remove any repeated thumbprints when we concat the list of thumbprints.


Further reading ๐Ÿ“š

ย