Your code is clean; main.tf, variables.tf, outputs.tf, everything is in place.

Terraform apply runs successfully, and your resources are provisioned exactly as planned.

But there’s a catch: your Terraform configurations might not be secure enough.

So how do we tighten the security of our infrastructure?

This is where Checkov comes in.

What is Checkov?

Checkov is an open-source static analysis tool for IaC (Infrastructure-as-Code) that scans Terraform, CloudFormation, Kubernetes, and other IaC files for misconfigurations and security issues.

When run, it:

• Performs multiple security and compliance checks on your Terraform code.
• Flags any misconfigurations, vulnerabilities, or best practice violations.
• Guides on how to fix each failed check.

In short: Checkov helps you find and fix security issues before they make it into production.

Let’s Try It Out

Step 1 — Install Checkov

You can install Checkov locally:

macOS (Homebrew)

brew install checkov

Python (Cross-platform)

pip install checkov

Step 2 — Navigate to Your Terraform Code

Move into the folder containing your Terraform configuration files:

cd path/to/terraform/code

Step 3 — Run Checkov

Run the following command to scan your entire directory:

checkov -d . --quiet

Here’s an example output from my run:

I had 10 failed security checks in my Terraform code.

Fixing a Failed Check Example

Let’s fix one of these failed checks for demonstration purposes.

One of my failed checks was:
CKV_AWS_130 – This warns if a public subnet automatically assigns public IP addresses to instances on launch.

Finding the Root Cause

Upon checking the Checkov documentation, I found the cause:
My Terraform code had map_public_ip_on_launch = true, meaning any EC2 instance launched in this subnet would be publicly accessible by default.

Security best practice:
Set map_public_ip_on_launch to false unless explicitly needed.

Before:

resource "aws_subnet" "public" {
  vpc_id                  = var.vpc_id
  cidr_block              = var.public_subnets_cidr_blocks[count.index]
  availability_zone       = var.azs[count.index]
  map_public_ip_on_launch = true
}

After (Fixed):

resource "aws_subnet" "public" {
  vpc_id                  = var.vpc_id
  cidr_block              = var.public_subnets_cidr_blocks[count.index]
  availability_zone       = var.azs[count.index]
  map_public_ip_on_launch = false
}

Step 4 — Re-run Checkov

checkov -d . --quiet

As you can see, the number of failed checks dropped from 10 → 7.
(The other failed checks can be fixed in a similar way.)

Skipping Specific Checks

Sometimes you might want to skip certain checks — for example, in non-production environments or known exceptions.

To skip a specific check, pass the --skip-check flag:

checkov -d . --skip-check CKV_AWS_289,CKV_AWS_129

This will exclude those checks from the scan results.

Summary

In this tutorial, we:

• Installed and ran Checkov to scan Terraform code for security issues.
• Identified a failed check (CKV_AWS_130) and fixed it by updating the subnet configuration.
• Learnt how to skip certain checks when necessary.

Key Takeaway:
Checkov is a powerful tool to integrate into your IaC workflow, ensuring your Terraform code follows security best practices before it ever reaches production.

1. Using Long-Lived AWS IAM User Credentials (Secrets)

• Create an IAM user in AWS and generate an Access Key ID and Secret Access Key.
• Store these keys in GitHub under Settings → Secrets and variables (at the repository or environment level).
• The GitHub Actions workflow retrieves these secrets and uses them to authenticate to AWS.
• Drawback: Long-lived credentials must be rotated manually and are at risk if exposed.

2. Using OpenID Connect (OIDC) — The More Secure Way

• Instead of long-lived credentials, your workflow requests a short-lived token from GitHub’s OIDC provider at runtime.
• This token is exchanged with AWS Security Token Service (STS) for temporary credentials.
• No AWS keys are stored in GitHub.

Example Scenario

We have a workflow that builds a Docker image and pushes it to Amazon Elastic Container Registry (ECR).

• Before (Secrets-Based Authentication):
  The workflow retrieves AWS credentials from AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY stored in GitHub Secrets.
• After (OIDC-Based Authentication):
  The workflow assumes a temporary AWS role at runtime — no secrets needed.

How OIDC Authentication Works with AWS and GitHub Actions

1. Token Request — The workflow requests an OIDC token from GitHub’s OIDC provider.
2. Role Assumption — AWS STS is called with AssumeRoleWithWebIdentity using that token.
3. Validation — AWS verifies the token against the IAM role’s trust policy (which can be restricted to specific repos/branches).
4. Temporary Credentials — AWS issues short-lived credentials (up to 1 hour).
5. Access AWS Services — The workflow uses these temporary credentials to interact with AWS, limited by the role’s permissions.

Setting Up OIDC with AWS and GitHub Actions

Step 1 — Add GitHub as an Identity Provider in AWS

1. Go to AWS IAM → Identity Providers → Add Provider.
2. Provider type: OpenID Connect.
3. Pass in the Provider URL and Audience as shown below

Step 2 — Create an IAM Role for GitHub Actions

1. Go to AWS IAM → Roles → Create role.
2. Choose Web identity and select the OIDC provider you created.
3. Set audience to sts.amazonaws.com.
4. Attach an IAM policy (for testing, you can use AdministratorAccess, but in production, follow the principle of least privilege).
5. Add a trust policy condition to restrict access, e.g.,

"Condition": {
  "StringEquals": {
    "token.actions.githubusercontent.com:sub": "repo:your-username/your-repo:ref:refs/heads/main"
  }
}

6. Create the role and copy the Role ARN.

Step 3 — Update Your GitHub Actions Workflow

At the top of your workflow, allow the job to request the OIDC token:

permissions:
  contents: read
  id-token: write

and replace the old secrets-based step with:

- name: Configure AWS Credentials using OIDC
  uses: aws-actions/configure-aws-credentials@v4
  with:
    aws-region: ${{ env.AWS_REGION }}
    role-to-assume: arn:aws:iam::123456789012:role/GitHubOIDCRole
    audience: sts.amazonaws.com

Optional: You can also create a secret for the AWS IAM Role ARN and reference it within the step.

Step 4 — Test the Workflow

Push your changes to the branch specified in the IAM role’s trust policy.
If successful, your build will proceed without any long-lived secrets.

Summary
In this guide, we explored how to replace long-lived AWS credentials in GitHub Actions with a secure, short-lived authentication method using OpenID Connect (OIDC). By configuring AWS to trust GitHub’s OIDC provider, your workflows can assume IAM roles at runtime without storing secrets in your repository. This approach reduces security risks, automates credential rotation, and allows fine-grained access control, making it a best practice for connecting GitHub Actions to AWS.

1. Install the AWS CLI:

You can refer to the documentation to install the AWS CLI here → https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html

2. AWS CLI Configuration:

Make sure you have configured the AWS CLI with your credentials (Access Key and Secret Key). To create these, go to the AWS portal, click on your username/profile in the top right corner, select Security Credentials, then scroll down to Access Keys. From there, create new access keys, and you’ll have the credentials needed for AWS CLI configuration.

To configure the AWS CLI, run the `aws configure` command, input your Access Key and Secret Key, and either accept the default options for the following prompts or customise them as needed.

3. Using the S3 API:

You can use the aws s3api help command to display a list of all the available commands that you can execute. These commands represent requests made to the S3 bucket API for performing various CRUD (Create, Read, Update, Delete) operations. Essentially, the s3api interface allows you to directly interact with the S3 service at a more granular level, giving you control over actions like creating buckets, uploading files, retrieving objects, managing permissions, and more. Here's a more detailed breakdown of the types of commands you should expect to see when using s3api.

4. Use the create-bucket command. Make sure the bucket name is both unique and valid, and specify the region where you'd like the bucket to be located. Additionally, there are several optional arguments you can provide when setting up the S3 bucket to customise its configuration further.

aws s3api create-bucket --bucket test-bucket-98928124  --region us-east-1

You should then be able to see an output:

And Voila! You have successfully created an S3 Bucket. To confirm your newly created resource, Use the command:

aws s3 ls 

You should see the date/time and the s3 bucket name as the output

To now delete your newly created s3 bucket. Use the command:

aws s3api delete-bucket --bucket test-bucket-98928124  --region us-east-1

Then use the command:

aws s3 ls 

You should see that you no longer get the s3 bucket as an output, indicating that the s3 bucket no longer exists. To confirm, you can also view the AWS UI (Portal) to see if the changes made on the CLI are reflected on the console.

And that’s it! That is how you create and delete an S3 Bucket.