CI/CD on HabibiOps

Bitbucket OIDC Integration with AWS ECR

Thu, 05 Feb 2026 00:00:00 +0000

Introduction

We previously talked about OIDC integration with AWS using GitHub Actions. We will now see how to do a similar integration with BitBucket Pipelines. Namely, we want to push a container image to AWS ECR and then use that image in future pipelines.

AWS IAM Identity Providers

We have to configure the Bitbucket OpenID Connect provider in AWS IAM. Use the following to create a new OpenID Connect provider:

Provider URL: api.bitbucket.org/2.0/workspaces/<YOUR-WORKSPACE-NAME>/pipelines-config/identity/oidc
Audience: ari:cloud:bitbucket::workspace/<YOUR-WORKSPACE-ID>

Now that the provider is configured, we can set up the IAM role for the Bitbucket OIDC provider and use it in our pipelines.

AWS OIDC IAM Role

The IAM role requires ECR push permissions and the GetAuthorizationToken action in order to be able to log into ECR.

Example permissions:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


{
 "Statement": [
 {
 "Action": "ecr:*",
 "Effect": "Allow",
 "Resource": "arn:aws:ecr:eu-central-1:123456789012:repository/devops-terraform",
 "Sid": "AllowAllEcrActions"
 },
 {
 "Action": "ecr:GetAuthorizationToken",
 "Effect": "Allow",
 "Resource": "*",
 "Sid": "EcrGetAuthorizationToken"
 }
 ],
 "Version": "2012-10-17"
}

In the trust relationships section, we need to add the arn of the previously created Bitbucket OIDC provider and allw the AssumeRoleWithWebIdentity action for our specific Bitbucket repository. We can also add the IP addresses of the Bitbucket servers that will be using the OIDC provider in case you are using dedicated self-hosted Bitbucket runners.

Example trust relationships:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Sid": "",
 "Effect": "Allow",
 "Principal": {
 "Federated": "arn:aws:iam::123456789012:oidc-provider/api.bitbucket.org/2.0/workspaces/stulz_bitbucket/pipelines-config/identity/oidc"
 },
 "Action": "sts:AssumeRoleWithWebIdentity",
 "Condition": {
 "StringLike": {
 "api.bitbucket.org/2.0/workspaces/stulz_bitbucket/pipelines-config/identity/oidc:sub": "{YOUR-BITBUCKET-REPO-ID}*"
 },
 "IpAddress": {
 "aws:SourceIp": [
 "64.x.y.z/32",
 "32.x.y.z/32"
 ]
 }
 }
 }
 ]
}

ECR Push Pipeline

After setting up the IAM role, we can use it in our pipelines as follows:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


pipelines:
 custom:
 dockerEcrBuildPush:
 - variables:
 - name: IMAGE_NAME
 default: cicd-tf
 - name: IMAGE_TAG
 default: 1.12.0-6.5.0
 - name: AWS_DEFAULT_REGION
 default: eu-central-1
 - step:
 name: Build & Push Docker Image
 oidc: true
 runs-on:
 - 'self.hosted'
 - 'linux'
 script:
 - docker build -t $IMAGE_NAME:$IMAGE_TAG -t $IMAGE_NAME:latest .
 - pipe: atlassian/aws-ecr-push-image:2.6.0
 variables:
 AWS_DEFAULT_REGION: '$AWS_DEFAULT_REGION'
 AWS_OIDC_ROLE_ARN: 'arn:aws:iam::123456789012:role/devops-terraform-oidc'
 IMAGE_NAME: '$IMAGE_NAME'
 TAGS: '$IMAGE_TAG latest'

The above pipeline will build the docker image and push it to ECR using the IAM role we created and using the official Bitbucket Pipelines Pipe: AWS ECR push image atlassian/aws-ecr-push-image.

If we want to use this image as a base image in our future pipelines, we can reference it in the image name section and specify the OIDC IAM role that can be used to pull it from ECR.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


 steps:
 - step:
 name: TF Plan
 image:
 name: '123456789012.dkr.ecr.eu-central-1.amazonaws.com/devops-terraform:1.12.0-6.5.0'
 aws:
 oidc-role: 'arn:aws:iam::123456789012:role/devops-terraform-oidc'
 oidc: true
 script:
 - terraform init
 - terraform validate
 - terraform plan -out=plan.tfplan
 runs-on:
 - 'self.hosted'
 - 'linux'

This way, the terraform plan step will run inside the designated container image with a pre-installed terraform binary pinned to a specific version (1.12.0-6.5.0).

Conclusion

In this post, we have seen how to use Bitbucket OIDC integration with AWS ECR. We have also seen how to use the official Bitbucket Pipelines Pipe: AWS ECR push image to build and push a docker image to ECR. Hopefully, this will help you in your future projects.

References:

GitHub Actions AWS Deploy using OIDC

Mon, 19 Jan 2026 00:00:00 +0000

Introduction

1
2
3
4
5
6


- name: Configure AWS credentials
 uses: aws-actions/configure-aws-credentials@v6
 with:
 aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
 aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
 aws-region: ${{ env.AWS_REGION }}

What’s wrong with this step inside the GitHub Actions workflow? Yes, it’s not the best way to authenticate to AWS because AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY were used to configure the credentials. This means having to manage an IAM user with valid access keys. This means that these keys have to be rotated regularly. This means that someone has to copy and paste those static credentials into the secrets and make sure they are not leaked or compromised somewhere else.

What’s the best practice to authenticate to AWS in a pipeline you may ask? The answer is OpenID Connect (OIDC). OpenID Connect allows your workflows to exchange short-lived tokens directly from your cloud provider. Let’s see how to configure this in GitHub Actions and deploy to AWS using this method.

AWS IAM Identity Providers

Before allowing GitHub Actions to authenticate to AWS, we need to configure an OpenID Connect provider in AWS IAM. Inside the AWS IAM console, go to Identity Providers and create a new OpenID Connect provider. Use the following details for the configuration:

Provider URL: token.actions.githubusercontent.com
Audience: sts.amazonaws.com

After setting up the provider, we can create an IAM role forGitHub Actions to assume it.

AWS IAM Role and Trust Relationship Policy

create a new IAM role with the following trust policy that allows the OIDC provider to assume the role with web identity:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Principal": {
 "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
 },
 "Action": "sts:AssumeRoleWithWebIdentity",
 "Condition": {
 "StringEquals": {
 "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
 },
 "StringLike": {
 "token.actions.githubusercontent.com:sub": [
 "repo:GitHubOrg/GitHubRepo:ref:refs/heads/*",
 "repo:GitHubOrg/GitHubRepo:ref:refs/tags/*"
 ]
 }
 }
 }
 ]
}

Let’s break down the trust relationship policy:

Federated Principal: the OIDC provider ARN
StringEquals Condition: the OIDC token audience (aws sts)
StringLike Condition: the GitHub repository and branch patterns that the role can be assumed from. Here we allow the role to be assumed from any branch or tag in the GitHubRepo repository.

We can use wildcards in the repository and branch patterns to allow multiple repositories and branches to assume the role. We can also define only specific branches or tags to allow only specific branches or tags to assume the role. For example:

Allow only the main branch:

1
2
3


"StringLike": {
 "token.actions.githubusercontent.com:sub": ""repo:GitHubOrg/GitHubRepo1:ref:refs/heads/main"
}

Allow any branch:

1
2
3


"StringLike": {
 "token.actions.githubusercontent.com:sub": ""repo:GitHubOrg/GitHubRepo1:*"
}

Allow only tags from multiple repositories:

1
2
3
4
5
6
7


"StringLike": {
 "token.actions.githubusercontent.com:sub": [
 "repo:GitHubOrg/GitHubRepo1:ref:refs/tags/*",
 "repo:GitHubOrg/GitHubRepo2:ref:refs/tags/*",
 "repo:GitHubOrg/GitHubRepo3:ref:refs/tags/*"
 ]
}

These fine-grained permissions should be used to restrict access to the role accordingly. After creating the role with the trust policy, we can attach the IAM policy that allows the role to do whatever we would like to do inside AWS such as write to S3 buckets, update ECS tasks, etc.

GitHub Actions Workflow

After setting up the IAM role and trust relationship policy, we can configure the GitHub Actions workflow to assume the role and deploy to AWS. Here is an example workflow that deploys a Hugo site to S3:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47


name: 'Deploy to S3'

on:
 workflow_dispatch:
 branches:
 - main

permissions:
 id-token: write
 contents: read

defaults:
 run:
 shell: bash

env:
 AWS_REGION: "eu-central-1"
 AWS_DEFAULT_REGION: "eu-central-1"
 AWS_ROLE_ARN: "arn:aws:iam::123456789012:role/gha-oidc-rolename"
 AWS_ROLE_SESSION_NAME: "GHA-OIDC-${{ github.run_id }}-${{ github.run_number }}-${{ github.run_attempt }}"
 AWS_S3_BUCKET_NAME: "my-awesome-hugo-website"

jobs:
 deploy:
 runs-on: ubuntu-latest
 steps:

 - name: Checkout
 uses: actions/checkout@v5

 - name: Configure AWS Credentials
 uses: aws-actions/configure-aws-credentials@v5
 with:
 role-to-assume: ${{ env.AWS_ROLE_ARN }}
 role-session-name: ${{ env.AWS_ROLE_SESSION_NAME }}
 aws-region: ${{ env.AWS_REGION }}

 - name: Setup Hugo
 run: sudo apt-get update && sudo apt-get install hugo -y

 - name: Build Hugo site
 run: hugo --gc --minify
 working-directory: ./my-awesome-hugo-theme

 - name: Deploy to S3
 run: aws s3 sync --delete ./public/ s3://${{ env.AWS_S3_BUCKET_NAME }}/public/
 working-directory: ./my-awesome-hugo-theme

Let’s break down the workflow:

The id-token is used in combination with OpenID Connect. Setting the permissions to write is required in order to request an OpenID Connect JWT Token as described in the docs.
The configure-aws-credentials action is used to configure the AWS credentials using the OpenID Connect JWT Token. Notice that we are not using the aws-access-key-id and aws-secret-access-key inputs. We only specified the role ARN and session name.
The Setup Hugo step installs Hugo on the runner.
After building the Hugo site, the Deploy to S3 step deploys the site to S3 by copying over the generated public folder using the AWS CLI: aws s3 sync ....

Here’s a diagram of the OIDC workflow:

Conclusion

In this post, we saw how to configure GitHub Actions to authenticate to AWS using OpenID Connect. An example Hugo site deployment to S3 was used to demonstrate the workflow. I hope this post was helpful and you learned something new. Let’s stop using IAM users with static credentials inside CI/CD pipelines!

References:

Terraform Container Image for CI/CD Pipelines

Sun, 11 Jan 2026 00:00:00 +0000

Introduction

Terraform is a great tool for managing infrastructure and can be integrated with CI/CD pipelines for automated deployments. In order to achieve idempotency and avoid unexpected changes from version updates, terraform should be run in a container image and be pinned to a specific version.

In addition to having a pinned terraform version inside the container image, it can be a wise choice to also include a pinned version of the main provider being used for your infrastructure. For example, if you are using AWS, you can pin the terraform aws provider to your specific version.

Terraform and Provider Version Pinning

Your terraform configuration file should include the terraform and provider versions you want to use. For example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


terraform {
 required_version = "1.12.0"

 required_providers {
 aws = {
 source = "hashicorp/aws"
 version = "6.5.0"
 }
 }
}

I place the above in a separate file called versions.tf and include it in any directory used by terraform.

Terraform Container Image

The main characteristics of a good terraform container image are:

small size: use Alpine Linux as a base image
pinned terraform version
pinned provider versions
arguments to specify the terraform and provider versions
environment variables reflecting the used versions

This link provides an example on how to install terraform on Alpine Linux. Here is an example Dockerfile for our terraform container image:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


FROM alpine:3.22.0

ARG TERRAFORM_VERSION="1.12.0"
ARG TERRAFORM_AWS_PROVIDER_VERSION="6.5.0"

ENV TF_IN_AUTOMATION=true
ENV TF_INPUT=false
ENV TERRAFORM_VERSION="${TERRAFORM_VERSION}"
ENV TERRAFORM_AWS_PROVIDER_VERSION="${TERRAFORM_AWS_PROVIDER_VERSION}"

RUN apk add --update --no-cache \
 aws-cli \
 curl \
 git \
 unzip

# terraform
RUN curl -o tf.zip "https://releases.hashicorp.com/terraform/${TERRAFORM_VERSION}/terraform_${TERRAFORM_VERSION}_linux_amd64.zip" \
 && unzip tf.zip -d /usr/local/bin/ \
 && rm tf.zip

# terraform hashicorp/aws provider
RUN mkdir -p "/root/.terraform.d/plugins/registry.terraform.io/hashicorp/aws/${TERRAFORM_AWS_PROVIDER_VERSION}/linux_amd64" \
 && curl -o tf_aws.zip "https://releases.hashicorp.com/terraform-provider-aws/${TERRAFORM_AWS_PROVIDER_VERSION}/terraform-provider-aws_${TERRAFORM_AWS_PROVIDER_VERSION}_linux_amd64.zip" \
 && unzip tf_aws.zip -d "/root/.terraform.d/plugins/registry.terraform.io/hashicorp/aws/${TERRAFORM_AWS_PROVIDER_VERSION}/linux_amd64/" \
 && rm tf_aws.zip

Some advantages of having a pinned terraform and provider versions are:

The pipeline runs will be guaranteed to run in a reproducible manner
terraform init will not download the latest provider version and will fail in case someone tries to use a different version in the pipeline
The pipeline runs will be faster since the provider will not need to be downloaded every time on terraform init

Image Tagging

There are different ways to tag a container image. Some prefer to use the git commit hash as the tag, while others prefer to use semantic versioning. In this case, I prefer to use the explicit terraform and provider versions as the tag.

The image is therefore tagged accordingly: $IMAGE:$TERRAFORM_VERSION-$TERRAFORM_AWS_PROVIDER_VERSION. For example, an image with terraform version 1.12.0 installed and aws provider version 6.5.0 would have the tag 1.12.0-6.5.0.

Conclusion

This post summarized the best practices for creating terraform container images to be used in CI/CD pipelines.

A sequel post will cover how to configure pipeline builds and deployments using the above container image.