By Raeveen Pasupathy —

Goodbye Access Keys, Hello OIDC: Unleashing Secure CI/CD with AWS IAM Roles (OIDC)

Goodbye Access Keys, Hello OIDC: Unleashing Secure CI/CD with AWS IAM Roles (OIDC)

We all have been in a situation where we were worried what if our AWS Access Keys or Secret Access Keys got leaked. I mean, what can go wrong right? Well, let’s hold on our thoughts over here.

Let’s now assume we have 100 IAM Access Keys active currently, and rotating them could be nerve-wrecking because in order to rotate them — You must remember them first!w

It’s better to be safe than sorry. Exposing your AWS Access Keys or Secret Access keys are not fun!

Prerequisites

  • A GitHub Account
  • An AWS Account

Step 1: Create a new GitHub repository

You know the drill. Just create the repository you’d like to test this with on GitHub.

Alternatively, you can use any existing repositories!

Step 2: Login to your AWS Account

Head to https://console.aws.amazon.com and authenticate with your IAM User.

Note: If you are authenticating through AWS SSO — Then, proceed with the respective AWS SSO login page.

Step 3: Prepare your AWS Environment to support OIDC Authentication

  1. Head to the AWS IAM OIDC providers page.
  2. Click on “Add provider”.
  3. Fill / select the following:
    Provider Type: OpenID Connect
    Provider URL: https://token.actions.githubusercontent.com
    * Click on “Get thumbprint”
    Audience: sts.amazonaws.com
  4. Head to the AWS IAM roles page.
  5. Create a new IAM role with the details as below:
    Role Name: Any name you’d prefer
    Role Policy: Any policy you’d prefer. (I am using AdministratorAccess for testing purposes).
    Role Trust Relationship: (As below)
{ 
    "Version": "2012-10-17", 
    "Statement": [ 
        { 
            "Effect": "Allow", 
            "Principal": { 
                "Federated": "<YOUR_OIDC_ARN>" 
            }, 
            "Action": "sts:AssumeRoleWithWebIdentity", 
            "Condition": { 
                "StringEquals": { 
                    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com", 
                    "token.actions.githubusercontent.com:sub": ["repo:<YOUR_GITHUB_ORG>/<YOUR_REPO_NAME>:ref:refs/heads/<YOUR_BRANCH_NAME>"] 
                } 
            } 
        } 
    ] 
}

Upon creation of the IAM role with the appropriate configurations as mentioned above, you may now attach the IAM role to the OIDC provider by;

  1. Clicking on your OIDC Provider from the OIDC Providers page.
  2. Attaching the IAM role by click on the “Assign role” button on the top right of the page.

Step 4: Setting up your GitHub CI/CD workflow configuration

This is a simple GHA workflow, please update wherever neccessary;

name: "Testing CI/CD" 
on: 
  workflow_dispatch: 
permissions: 
  id-token: write # This is required for requesting the JWT 
  contents: read # This is required for actions/checkout 
jobs: 
  deploy: 
    runs-on: ubuntu-latest 
    steps: 
      - uses: actions/checkout@v2 
      - name: Authenticate to AWS 
        uses: aws-actions/configure-aws-credentials@v2 
        with: 
          role-to-assume: <YOUR_AWS_IAM_ROLE_ARN> 
          role-session-name: GitHub_to_AWS_via_FederatedOIDC 
          aws-region: <YOUR_AWS_REGION> 
      - name: GetCallerIdentity (STS) 
        run: | 
          aws sts get-caller-identity 
      - name: S3 (List) 
        run: | 
          aws s3 ls

Step 5: Let’s test it out

The above is possible with our approach. No Secret Access Key or Access Keys needed in the GH environment.

Conclusion

Now that we have setup and successfully authenticated to our AWS Account through GHA. You may have some questions, and I had too! Let me answer them for you in numbered points.

  1. Is this secure?

Yes. Since we created an IAM Role policy in Step 3 of this document. We have limited the scope, so only GitHub repositories that we own in our GH Organization could exchange STS token among themself.

  1. How do we handle rotations? Are there anything to rotate?

To be honest, there is nothing to rotate as we are not dealing with any IAM Access Keys or Secret Access Keys as we’re aiming to get rid of them anyways! It is secure in a way where we don’t even need to store the IAM Access Key / Secret Access Key within our local machine related to CI/CD.

  1. Can I add more repo to have access to exchange the STS token so they could also use CI/CD?

Definitely! Referring to our IAM role trust relationship policy — You can add multiple repository names in the following format to “token.actions.githubusercontent.com:sub”.

Example:

"token.actions.githubusercontent.com:sub": [ 
  "repo:InspectorGadget/assume-role-with-oidc:ref:refs/heads/main", 
  "repo:InspectorGadget/assume-role-with-oidc:ref:refs/heads/main" 
]

#GoodbyeAccessKeys #OIDCSecurity #CI_CD #AWSIAMRoles #SecureDevOps #NoMoreKeys #IdentityAccessManagement