As the adoption of GitHub Actions for CI/CD pipelines grows, one of the most critical concerns developers face is the secure management of AWS credentials within their workflows. Storing static credentials, such as access and secret keys, in GitHub’s secrets can expose your AWS environment to potential security risks. Fortunately, AWS provides a more secure way to handle this with GitHub’s OpenID Connect (OIDC), eliminating the need for static credentials.

Introduction to Avoiding Static Credentials in GitHub Workflows

Using static credentials in GitHub workflows poses significant risks, as these credentials are long-lived and can be exploited if compromised. Moreover, manually rotating these credentials becomes cumbersome, especially when working across multiple repositories and environments.

In this guide, we’ll walk you through setting up secure AWS integration for GitHub workflows, utilizing AWS temporary credentials and role assumptions to enhance security.

Understanding Temporary Credentials and Role Assumptions in AWS

Temporary credentials are short-lived and automatically expire, making them a secure alternative to static keys. AWS provides these credentials through IAM roles and services like AWS Security Token Service (STS). With temporary credentials, developers can assume specific roles with pre-defined permissions, minimizing the risks associated with static credentials.

Users, applications, and services can assume AWS roles. When integrated with GitHub, workflows can automatically request and receive temporary credentials, limiting the exposure of sensitive AWS resources.

The Challenge of External Deployments Without Static Keys

Before the introduction of OIDC, deploying applications or infrastructure to AWS from external platforms (such as GitHub) required access and secret keys, which were static and vulnerable to leakage. Maintaining multiple sets of keys across environments also introduced complexity and potential security gaps.

The introduction of OIDC solves this problem by allowing trusted external platforms like GitHub to request access to AWS resources without managing or storing static keys. This approach grants GitHub workflows temporary AWS credentials by assuming a pre-configured role.

Introducing GitHub OIDC for Secure Credential Management

GitHub OIDC (OpenID Connect) is a security protocol that allows GitHub Actions to authenticate directly with AWS using a secure token exchange process. With OIDC, GitHub can request temporary credentials dynamically, making your workflows more secure.

This method reduces the need for static credentials by allowing GitHub to act as an OIDC provider. It requests AWS credentials when needed, creating a more streamlined and secure way to authenticate without hardcoding sensitive information in your repositories.

Configuring GitHub as an OIDC Provider in AWS

To configure GitHub as an OIDC provider in AWS, follow these steps:

  1. Create an OIDC Identity Provider in AWS IAM:
    • Navigate to AWS IAM and select “Identity Providers.”
    • Choose to add a new OIDC provider and input GitHub’s URL (https://token.actions.githubusercontent.com).
    • Add GitHub’s OIDC client ID (sts.amazonaws.com).
    • Save the OIDC provider to your AWS account.
  2. Create a Policy for GitHub to Assume Roles:
    • Define a policy that allows GitHub to assume specific IAM roles within your AWS account.
    • Limit the scope of this policy to ensure least-privilege access.

Setting Up IAM Roles and Assume-role Policies

With the OIDC provider in place, you need to create IAM roles that GitHub workflows can assume to access AWS resources:

  1. Create an IAM Role:
    • Go to IAM and choose “Create Role.”
    • Select the Web Identity provider (GitHub’s OIDC provider).
    • Choose the specific GitHub repository or repositories that will assume this role.
    • Attach a permissions policy (e.g., S3, Lambda, or EC2) to define the role’s actions.
  2. Create an Assume-role Policy:
    • Create a policy that defines which entities (GitHub repositories) can assume the role.
    • Use GitHub repository identifiers in the policy’s Condition field to ensure only trusted repositories can assume the role.

Integrating AWS Role Assumption in GitHub Actions

To integrate role assumption into your GitHub workflows, update your GitHub Actions workflow YAML file to reference the OIDC provider and assume the role in AWS:

jobs:

  deploy:

    runs-on: ubuntu-latest

    steps:

    – name: Configure AWS Credentials

      uses: aws-actions/configure-aws-credentials@v2

      with:

        role-to-assume: arn:aws:iam::123456789012:role/github-actions-role

        aws-region: us-west-2

This step will configure your workflow to assume the IAM role dynamically via OIDC, avoiding the need for static credentials.

Testing and Verifying the Workflow Setup

Once you’ve configured your IAM roles and GitHub workflows, it’s crucial to test and verify the setup:

  1. Check Role Assumption: Ensure that the GitHub Action assumes the correct role successfully.
  2. Monitor Logs: Use AWS CloudTrail to monitor for successful role assumption and identify any issues during execution.
  3. Validate Permissions: Ensure that the workflow only has access to the resources defined by the attached policies.

Testing is critical to ensuring that your role assumption works as expected and that the necessary permissions are in place.

Conclusion: Enhancing Security in GitHub Workflows

Eliminating static credentials from GitHub workflows is an essential step in bolstering the security of your CI/CD pipelines. You can securely manage AWS resources without exposing sensitive keys by leveraging temporary credentials, OIDC, and role assumption. This method simplifies credential management and enhances the overall security of your deployment processes.

References

Integrating with GitHub Actions – CI/CD pipeline to deploy a Web App to Amazon EC2

Use IAM roles to connect GitHub Actions to actions in AWS