Overview
Hello there! We're happy to have you back for another blog post. This time, we'll explain the differences between OIDC (OpenID Connect) and Static Credentials straightforwardly. Plus, we'll guide you on how to use them to make Terrateam's CI/CD pipeline work smoothly on your AWS cloud account using both methods.
Let's dive in!
We will cover:
What are OIDC and Static Credentials?
Setting up OIDC and Static Credentials for Terrateam on AWS.
Comparison between two.
Which option should you choose for enhanced security: OIDC or Static Credentials?
OIDC (OpenID Connect)
OpenID Connect (OIDC) is an open authentication protocol built on the foundation of OAuth 2.0. It's designed with consumers in mind, offering a convenient way for individuals to employ single sign-on (SSO) for accessing various websites or services. OIDC works by connecting users to OpenID Providers (OPs), which can be platforms like email providers or social networks. These providers verify the users' identities.
OIDC serves a dual purpose: it not only authenticates users but also supplies the application or service with essential user information, context about their authentication, and access to their profile details. This protocol simplifies and streamlines the login process for users while providing valuable data to the applications they access.
OIDC with Terrateam: Terrateam creates a temporary token for Access to the cloud provider with all specific connections. These tokens are short-lived and are the most secure way to run a CI/CD pipeline.
We have understood enough about OIDC with all theories, but now the question arises of how to set it up. Let’s get our hands on it
Here are the setup instructions for the Terrateam CI/CD pipeline run on GitHub:
Setup of OIDC for Terrateam on AWS:
Follow the official documentation for setting up OIDC authentication and authorization for Terrateam.
Requirements: AWS CLI installed.
Run the following commands in your terminal to get started:
To set up your AWS account with root-level ACCESS KEY and SECRET KEY, this section will guide you through the process of logging in to your AWS account.
- aws configure
Establish an AWS OIDC provider.
aws iam create-open-id-connect-provider \
--url https://token.actions.githubusercontent.com \
--client-id-list sts.amazonaws.com --thumbprint-list \
6938fd4d98bab03faadb97b34396831e3780aea1 \
1c58a3a8518e8759bf075b76b750d4f2df264fcd
Create a local file named trustpolicy.json on your workstation, which will specify the policy for AWS to trust GitHub's OIDC as a federated identity; make sure to update the provided example file with your custom values.
- Example trustpolicy.json. Make sure to replace AWS_ACCOUNT_ID and GITHUB_ORG with your values.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::AWS_ACCOUNT_ID:oidc-provider/token.actions.githubusercontent.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringLike": {
"token.actions.githubusercontent.com:sub":
"repo:GITHUB_ORG/*"
},
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
}
}
}
]
}
For AWS_ACCOUNT_ID:
- aws sts get-caller-identity
For GITHUB_ORG follow the given link:
Create a terrateam IAM role using the newly created trustpolicy.json
aws iam create-role \ --role-name terrateam \ --assume-role-policy-documentfile://trustpolicy.json
Attach the PowerUserAccess IAM policy
aws iam attach-role-policy \ --policy-arn arn:aws:iam::aws:policy/PowerUserAccess \ --role-name terrateam
Create a .terrateam/config.yml configuration file at the root of your Terraform repository:
You can customize Terrateam's behaviour by editing the config.yml file located in the .terrateam directory at the root of your Terraform repository. Ensure you replace AWS_ACCOUNT_ID with your specific AWS account ID.
##########################################################################
# .terrateam/config.yml
##########################################################################
hooks:
all:
pre:
- type: oidc
provider: aws
role_arn: "arn:aws:iam::AWS_ACCOUNT_ID:role/terrateam"
- Your setup for the OIDC connection is done!
- It’s this easy to do and much more secure.
Static Credentials
Every time you need to access a resource, it requires authentication. As your resources and applications multiply, so does the number of credentials needed to access them. Many of these credentials are considered static, meaning they remain unchanged, and there are various types of static credentials in use.
Static credentials are long-lived access keys securely stored within GitHub Secrets. Terrateam strongly advises regularly rotating these credentials to enhance security.
Obviously, this is less secure as compared to OIDC therefore, It's not advisable to use this approach.
We've covered enough theory about Static Credentials, but now it's time to take action and set it up. Let's dive in!
Here are the setup instructions for running the Terrateam CI/CD pipeline on GitHub:
Setup of Static Credentials for Terrateam on AWS:
Follow the official documentation for setting up Static Credentials.
Requirements: AWS CLI installed, and GitHub CLI installed on the local system.
Run the following commands in your terminal:
Create a terrateam IAM user
- aws iam create-user --user-name terrateam
Attach the PowerUserAccess IAM policy
- aws iam attach-user-policy \ --policy-arn arn:aws:iam::aws:policy/PowerUserAccess \ --user-name terrateam
Create an access key for the terrateam user
- aws iam create-access-key --user-name terrateam
Record the AccessKeyId and SecretAccessKey to use below.
Export your Terraform organization/repo combination as an environment variable.
- export REPO="<OWNER/REPO>"
Create the AWS Access Key ID GitHub Secret
gh secret --repo "$REPO" set AWS_ACCESS_KEY_ID
Enter the ACCESS_KEY_ID generated above
Create the AWS Secret Access Key GitHub Secret
gh secret --repo "$REPO" set AWS_SECRET_ACCESS_KEY
Enter the SECRET_ACCESS_KEY generated above
- Setup is done!
- This is not a recommended way to give access to your AWS account.
A Quick Comparision between OIDC and Static Credentials
Long-Term and Secure:
In terms of security, OIDC is much more secure, because it’s ACCESS_KEY and SECRET_KEY keep on changing each time a new token is created.
While with Static Credentials you need to change your ACCESS_KEY and SECRET_KEY manually and put values in secrets.
Vulnerablity/ Security issues:
Static Credentials are more vulnerable to security risks because they require you to include static secrets, such as ACCESS_KEY and SECRET_KEY, in your GitHub repository. If you inadvertently fail to conceal these secrets in your code, your infrastructure could be at risk of disruption or compromise.
Whereas in the case of OIDC, you do not need to put any secrets in your code, it will be generated and retrieved automatically each time the Terrateam CI/CD pipeline runs.
Static Creation of keys:
As the name suggests, Static Credentials are required to create static values and put them in GitHub secrets.
Whereas OIDC once set up doesn’t need any static values to create.
Token/Keys durations:
Static Credentials are long-term keys, you need to change them manually, there’s no other way.
OIDC uses short-term tokens that become void after a few hours and it keep on changing by itself, no manual intervention is required.
Extra Setup files required:
Static Credentials don’t require any extra files to add other than just your Terraform configuration files to be available to execute the pipeline.
On the other hand, OIDC requires some extra files such as config.yml to execute the pipeline, but the setup is still quite easy.
Can work on Multiple repositories:
To make it function for each repository, you must include Static Credentials in each repository individually.
In contrast, OIDC can seamlessly operate across multiple repositories, simplifying access management and enhancing efficiency.
Example trustpolicy.json that grants access to a single repository
Example trustpolicy.json that grants access to multiple repositories
Which option should you choose for enhanced security?
- OIDC (OpenID Connect) is highly recommended for more secure and seamless execution of the pipeline. With OIDC, you eliminate the need to generate access keys manually each time you run the pipeline since they are automatically generated, enhancing both security and convenience.
Conclusion
Terrateam strongly recommends utilizing OIDC authentication and authorization configurations for secure and streamlined execution of your CI/CD pipelines.