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
Head to the AWS IAM OIDC providers page.
Click on “Add provider”.
Fill / select the following:
Provider Type: OpenID Connect
Provider URL: https://token.actions.githubusercontent.com
** Click on “Get thumbprint”
*Audience: sts.amazonaws.com
Head to the AWS IAM roles page.
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;
Clicking on your OIDC Provider from the OIDC Providers page.
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
contents: read
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.
- 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.
- 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.
- 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
