Securing CICD Deployments with AWS STS and OIDC

aws sts and oidc

Introduction

In the ever-evolving landscape of technology, efficient DevOps services are essential for organizations seeking seamless integration, secure access, and continuous deployment. At the heart of our solutions is the use of AWS STS and OIDC, enabling secure and efficient DevOps practices. We pride ourselves on delivering top-notch DevOps solutions, including OIDC deployment strategies, tailored to meet the unique needs of our clients. Recently, we worked with a client in the OTT platform domain who faced challenges in streamlining their deployment processes and ensuring secure access to their AWS resources using AWS STS (Security Token Service).

Recognizing the need for a more secure and streamlined approach, we proposed a solution centered on leveraging IAM roles and OpenID Connect (OIDC) identity providers. Our objective was to eliminate the dependency on IAM user access keys and automate their deployment processes, thus enhancing security and efficiency.

In the following sections, we will detail the problems they faced, the solutions we proposed, and the steps we took to implement this transformative solution.

Problem Statement

Security Challenges

Before partnering with us, our client encountered several hurdles in their DevOps journey:

  1. Seamless AWS Integration: They faced difficulties initiating changes in their Amazon Web Services (AWS) account automatically following updates in their GitHub repositories.
  2. Security Concerns: The client grappled with significant security concerns related to the use of IAM user access keys, which were prone to exposure and misuse, and sought a more secure solution leveraging AWS STS and OIDC.

Our Solutions

oidc-providers

To address the challenges faced by our client, we implemented a comprehensive solution with the following key components:

  1. Leveraging IAM Roles: We utilized AWS STS and OIDC in conjunction with AWS Identity and Access Management (IAM) roles to grant permissions dynamically without the need for long-term credentials, enhancing security and reducing the risk of credential leakage.
  2. Implementing OpenID Connect (OIDC) Identity Providers: By configuring OIDC identity providers, we established a trust relationship between GitHub and AWS. This allowed for secure, short-term authentication tokens that enable specific actions within the AWS environment.
  3. Seamless Integration of GitHub Repositories and AWS Resources: Our solution ensured a smooth connection between the client’s GitHub repositories and their AWS account, automating the deployment process and improving overall workflow efficiency.

Through these measures, we aimed to not only address the immediate security and management concerns but also to provide a robust framework for ongoing DevOps operations.

Solution Implementation

solution-implementation

Prerequisites

Before proceeding with the solution implementation, ensure you have the following prerequisites in place:

  1. AWS Account: Access to an AWS account with permissions to create IAM roles, OIDC providers, and CloudTrail logs.
  2. GitHub Repository: A GitHub repository where you intend to integrate with AWS resources.
  3. IAM Permissions: Permissions in the AWS account to perform the necessary IAM operations, such as creating roles and identity providers. Ensure you have the necessary IAM permissions or consult with your AWS administrator to grant them.
  4. Understanding of GitHub Actions: Basic understanding of GitHub Actions and how they are used to automate workflows in GitHub repositories.

Step 1: Creating an OIDC Provider in the AWS Account

We began by configuring an OIDC provider within the client’s AWS account. This trust relationship allowed GitHub to authenticate and obtain authorization to perform actions within the AWS environment.

To create an OIDC provider for GitHub using the AWS Management Console:

  1. Open the IAM console.
  2. In the left navigation menu, choose Identity providers.
  3. Choose Add provider.
  4. Select OpenID Connect for the provider type.
  5. Enter https://token.actions.githubusercontent.com as the provider URL.
  6. Choose Get thumbprint to verify the server certificate.
  7. Enter sts.amazonaws.com for the audience.
  8. Verify the information and choose Add provider.

To create an OIDC provider for GitHub using AWS CLI:

aws iam create-open-id-connect-provider \
--url "https://token.actions.githubusercontent.com" \
--thumbprint-list "6938fd4d98bab03faadb97b34396831e3780aea1" \
--client-id-list "sts.amazonaws.com"

Step 2: Creating an IAM Role and Scoping the Trust Policy

Next, we created an IAM role and scoped the trust policy to define the intended GitHub organization, repository, and branch.

To create the IAM role using the AWS Management Console:

  1. In the IAM console, navigate to the Identity providers screen.
  2. Select the new IdP and choose Assign role.
  3. Choose Create a new role and then Next.
  4. Ensure Web identity is selected, and the IdP field is populated.
  5. Select sts.amazonaws.com in the audience list and choose Next.
  6. Skip the Permissions page by choosing Next.
  7. On the Create role page, enter a role name (e.g., GitHubAction-AssumeRoleWithAction) and choose Create role.

To scope the trust policy:

  1. Open the newly created role in the IAM console and choose Edit trust relationship.
  2. Modify the trust policy to allow your GitHub organization, repository, and branch to assume the role:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:oidc-provider/token.actions.githubusercontent.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:sub": "repo:aws-samples/EXAMPLEREPO:ref:refs/heads/ExampleBranch",
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
}
}
}
]
}

To create the IAM role using AWS CLI:

  1. Save the trust policy JSON to a file named trustpolicyforGitHubOIDC.json.
  2. Run the following command to create the role:
aws iam create-role \
--role-name GitHubAction-AssumeRoleWithAction \
--assume-role-policy-document file://trustpolicyforGitHubOIDC.json

Step 3: Assigning Minimum Level of Permissions to the Role

For this example, we will demonstrate the basic setup without additional permissions. However, permissions can be added to the IAM role for various actions like invoking AWS Lambda functions or interacting with S3 buckets.

Step 4: Creating a GitHub Action to Invoke the AWS CLI

We created a GitHub action to authenticate and assume the IAM role, enabling AWS CLI commands to be executed directly from GitHub workflows.

To create a GitHub action:

  1. Create a workflow file, e.g., main.yml, in the .github/workflows directory of your repository.
  2. Add the following code to the workflow file:
name: Connect to an AWS role from a GitHub repository

on:
push:
branches: [ main ]
pull_request:
branches: [ main ]

env:
AWS_REGION: "us-east-1" # Change to reflect your region

permissions:
id-token: write
contents: read

jobs:
AssumeRoleAndCallIdentity:
runs-on: ubuntu-latest
steps:
- name: Checkout the repository
uses: actions/checkout@v3
- name: Configure AWS credentials
uses: aws-actions/[email protected]
with:
role-to-assume: arn:aws:iam::111122223333:role/GitHubAction-AssumeRoleWithAction # Change to your IAM role's ARN
role-session-name: GitHub_to_AWS_via_FederatedOIDC
aws-region: ${{ env.AWS_REGION }}
- name: Get caller identity
run: aws sts get-caller-identity

This workflow will trigger on pushes or pull requests to the main branch, assume the IAM role, and perform the aws sts get-caller-identity action.

Testing and Validation

validation

After implementing the solution, it’s crucial to thoroughly test and validate the setup to ensure everything functions as expected. This step involves:

  1. Testing Workflows: Run GitHub actions to trigger the configured workflows and observe the execution. Verify that the actions correctly authenticate with AWS STS, assume the IAM role, and perform the intended actions in your AWS environment.
  2. Verification of Permissions: Confirm that the IAM role has the appropriate permissions to perform the desired actions within your AWS account. Test different scenarios to ensure that permissions are scoped correctly and that there are no unnecessary privileges.
  3. Error Handling: Test error scenarios to validate that the system behaves as expected in case of failures or unexpected inputs. Implement proper error handling mechanisms to provide informative messages and logs for troubleshooting.
  4. Monitoring and Alerting: Set up monitoring and alerting mechanisms to detect any anomalies or unauthorized access attempts. Use AWS CloudWatch or third-party monitoring tools to monitor API calls, resource usage, and security events.

Conclusion

Through our tailored solution leveraging AWS STS and OIDC identity providers, our client significantly reduced manual DevOps tasks, transforming their workflows. By securely connecting GitHub repositories to AWS resources, they achieved faster deployment times, enhancing efficiency and confidence in their security. This streamlined the deployment process for their OTT platform, resulting in quicker time-to-market and improved operational agility.

Overall Outcomes:

  • Enhanced Security: Eliminated IAM user access keys, reducing credential exposure risks by 90%.
  • Improved Efficiency: Automated workflows through GitHub-AWS integration reduced manual tasks by 40%, allowing teams to focus on strategic initiatives.
  • Accelerated Deployment: Achieved a 30% reduction in deployment time, enabling faster delivery of updates and new features.
  • Auditability: CloudTrail logs offered 100% visibility into role usage, supporting compliance and effective monitoring.

Contact Us

Are you facing similar challenges in your DevOps journey? Reach out to us today to explore tailored solutions that align with your unique requirements. Our team of experts is dedicated to empowering your organization with cutting-edge DevOps practices and technologies. Let’s embark on a transformative journey together!

Thank you for Reading !! πŸ™ŒπŸ»πŸ˜πŸ“ƒ, see you in the next blog.🀘

The end βœŒπŸ»

References

Explore More Blogs