No More AWS Keys in GitHub Secrets: Here’s Why?

Introduction:

GitHub Actions workflows often need to access cloud providers like AWS, Azure, GCP, or HashiCorp Vault to deploy software. They usually use credentials stored as GitHub secrets. But this requires duplicating credentials in both GitHub and the cloud provider.

With OpenID Connect (OIDC), workflows can request short-lived access tokens directly from the cloud provider, eliminating the need for duplicated credentials. The cloud provider must support OIDC and a trust relationship controlling which workflows can request tokens. Providers supporting OIDC include AWS, Azure, Google Cloud, and HashiCorp Vault.

💡 In this blog, you will get to know about GitHub OIDC in AWS to enhance security and eliminate the need for long-term key storage which allows our GitHub Actions workflows to access AWS resources, without needing to store the AWS credentials as long-lived GitHub secrets.

This can be called keyless authentication to access AWS resources. This can be achieved by:

1. To create an OIDC provider in your AWS account, use the URL https://token.actions.githubusercontent.com and the audience sts.amazonaws.com. This action will prompt AWS to fetch the signing keys according to the OIDC specification from https://token.actions.githubusercontent.com/.well-known/jwks. This URL uses the well-known OIDC discovery URL to automatically retrieve certificate information, which is essential for verifying signed tokens.
2. You can add the OIDC provider to the trust policy of an IAM role as follows:

// ...
"Principal": {
  "Federated": "arn:aws:iam::123456123456:oidc-provider/token.actions.githubusercontent.com"
},
// ...

3. Adding a condition on the token.actions.githubusercontent.com:sub and token.actions.githubusercontent.com:aud condition keys, which correspond to the sub (subject) and aud (audience) claims of the JWTs. Both of these are claims in the JWT generated for all Github Actions:

// ...
"Condition": {
  "StringLike": {
    "token.actions.githubusercontent.com:sub": "repo:octo-org/octo-repo:*"
  },
  "StringEquals": {
    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
  }
}
// ...

The final step defines the GitHub repository that can assume the IAM role. Without it, any GitHub Action can assume the role and access credentials. However, many IAM roles lack this condition, making them susceptible to unauthorized GitHub Actions. This vulnerability may stem from a misunderstanding of OIDC flows and the influence of insecure guides, despite both GitHub and AWS providing secure instructions.

ℹ️ To create a GitHub OIDC in your AWS account using Terraform, please refer to this link: https://github.com/saugat86/terraform-aws-github-oidc

Problem with storing keys for long term

This solution addresses the security risk associated with the long-term storage of AWS access keys and secret keys in GitHub secrets. If these keys are compromised, they could be misused. The risk is further increased due to the extended storage duration of these keys.

These keys will be used in the GitHub workflow as follows:

name: Terraform Plan | Apply
on:
  push:
    branches:
      - main
jobs:
  terraform-plan-apply:
    runs-on: ubuntu-latest
    steps:
      - name: Check terraform code
        uses: actions/checkout@v3
        
      - name: Configure aws credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-1
            
      - name: Set up terraform
        uses: hashicorp/setup-terraform@v2
        
      - name: Verify Terraform version
        run: terraform --version

      - name: Terraform Initialize
        run: terraform init 

      - name: Terraform validation
        run: |
                    terraform validate

      - name: Terraform plan
        run: |
          cd ${{ env.working_dir }}
          terraform plan -var-file dev.tfvars          

      - name: Terraform apply
        run: |
                    terraform apply -var-file dev.tfvars --auto-approve 

This workflow triggers when there’s a push to the main branch of the repository.

It starts by checking the Terraform code, configuring AWS credentials, and setting up Terraform. AWS credentials are obtained from GitHub secrets, which should be replaced with an OIDC token for better security.

Using GitHub OIDC

The step of configuring AWS credentials can be replaced with an AWS OIDC, improving security by eliminating long-term AWS access keys and secret keys storage in GitHub secrets. A token, invalid after a specified session duration, is generated during the workflow. GitHub’s Open ID Connect allows this connection to AWS, removing the need for long-term storage of keys. The default session duration is 1 hour.

Once you update the trust policy (as shown above), you can update the step Configure AWS credentials in GitHub workflow as below. You can see that we’ve removed usage of access key and secret key and it can removed safely from GitHub secrets as well.

- name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          role-to-assume: arn:aws:iam::<your-aws-account-number>:role/github_oidc
          aws-region: us-east-1

Conclusions

In conclusion, the use of GitHub OIDC in AWS is a more secure way for GitHub Actions workflows to access resources in AWS. It eliminates the need for long-term storage of AWS access keys and secret keys in GitHub secrets, reducing the risk of these keys being compromised. By replacing the AWS credentials with an OIDC token, we can improve the security of our workflows and reduce the risk of unauthorized access to our AWS resources.

References:

https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services?ref=cloudtechsimplified.com https://github.blog/changelog/2023-06-27-github-actions-update-on-oidc-integration-with-aws/

Stay tuned for more. Let’s connect on Linkedin and explore my GitHub for future insights.