From Long-Lived Keys to Workload Identity<\/strong><\/h2>\n\n\n\nThe first step was removing the dependency on static AWS access keys from the CI\/CD pipeline.<\/p>\n\n\n\n
We configured OIDC-based authentication between GitLab CI\/CD and AWS. Instead of storing an AWS access key and secret key, the pipeline requests a signed identity token. AWS validates that identity and issues temporary credentials through an IAM role.<\/p>\n\n\n\n
This changed the authentication model from:<\/p>\n\n\n\n
GitLab CI\/CD \u2192 Static AWS credentials \u2192 AWS<\/strong><\/p>\n\n\n\nto:<\/p>\n\n\n\n
GitLab CI\/CD \u2192 OIDC identity token \u2192 AWS IAM role \u2192 Temporary credentials<\/strong><\/p>\n\n\n\nFor example, consider a backend microservices project deployed to AWS ECS using GitLab CI\/CD. Initially, the pipeline stored AWS access keys as GitLab CI\/CD variables. These credentials were long-lived, and their permissions extended beyond what the deployment job actually required.<\/p>\n\n\n\n
We can change this approach by configuring OIDC federation between GitLab and AWS IAM. Instead of storing permanent AWS credentials, GitLab issues an identity token that AWS validates through an IAM OIDC identity provider. We then configure a dedicated IAM role with a trust policy restricted to the intended GitLab project and branch, allowing only authorized pipeline jobs to assume the role.<\/p>\n\n\n\n
Example 1: Restricting Who Can Assume the IAM Role<\/strong><\/h3>\n\n\n\nThe following AWS IAM trust policy allows an identity token from a specific GitLab project on the main branch to assume the deployment role.<\/p>\n\n\n\n{
\u00a0\u00a0“Version”: “2012-10-17”,
\u00a0\u00a0“Statement”: [
\u00a0\u00a0\u00a0\u00a0{
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“Effect”: “Allow”,
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“Principal”: {
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“Federated”: “arn:aws:iam::123456789012:oidc-provider\/gitlab.com”
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0},
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“Action”: “sts:AssumeRoleWithWebIdentity”,
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“Condition”: {
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“StringEquals”: {
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“gitlab.com:aud”: “sts.amazonaws.com”,
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“gitlab.com:sub”: “project_path:mygroup\/backend-api:ref_type:branch:ref:main”
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0}
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0}
\u00a0\u00a0\u00a0\u00a0}
\u00a0\u00a0]
}<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nThis trust policy restricts which GitLab workload can assume the IAM role. AWS must also have the corresponding GitLab OIDC provider configured with the appropriate issuer URL and audience.<\/p>\n\n\n\n
Example 2: Applying Least-Privilege Permissions<\/strong><\/h3>\n\n\n\nVerifying identity is only one part of Zero Trust. We also need to define what the authenticated workload is allowed to do.<\/p>\n\n\n\n
For example, the following IAM permissions policy allows the deployment role to describe a specific ECS service.<\/p>\n\n\n\n{
\u00a0\u00a0“Version”: “2012-10-17”,
\u00a0\u00a0“Statement”: [
\u00a0\u00a0\u00a0\u00a0{
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“Effect”: “Allow”,
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“Action”: [
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“ecs:DescribeServices”
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0],
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“Resource”: “arn:aws:ecs:ap-south-1:123456789012:service\/backend-cluster\/backend-service”
\u00a0\u00a0\u00a0\u00a0}
\u00a0\u00a0]
}<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nThis is a deliberately limited example, not a complete ECS deployment policy. A real deployment may also require permissions to update services, register task definitions, access a container registry, or pass an approved task execution role. Those permissions should be added only when required and scoped to the relevant resources.<\/p>\n\n\n\n
The key principle is that the pipeline should not receive administrator-level access just because it needs to deploy an application.<\/p>\n\n\n\n
Example 3: Obtaining Temporary Credentials in GitLab CI\/CD<\/strong><\/h3>\n\n\n\nWith the OIDC provider and IAM role configured, the GitLab pipeline can request an identity token and exchange it for temporary AWS credentials through AWS STS.<\/p>\n\n\n\n
The following simplified .gitlab-ci.yml example demonstrates this flow:<\/p>\n\n\n\ndeploy:
\u00a0\u00a0image: amazon\/aws-cli:2
\u00a0
\u00a0\u00a0id_tokens:
\u00a0\u00a0\u00a0\u00a0AWS_ID_TOKEN:
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0aud: sts.amazonaws.com
\u00a0
\u00a0\u00a0variables:
\u00a0\u00a0\u00a0\u00a0AWS_DEFAULT_REGION: ap-south-1
\u00a0\u00a0\u00a0\u00a0AWS_ROLE_ARN: arn:aws:iam::123456789012:role\/gitlab-backend-deploy
\u00a0
\u00a0\u00a0script:
\u00a0\u00a0\u00a0\u00a0– |
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0CREDS=$(aws sts assume-role-with-web-identity \\
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0–role-arn “$AWS_ROLE_ARN” \\
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0–role-session-name “gitlab-deploy-$CI_PIPELINE_ID” \\
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0–web-identity-token “$AWS_ID_TOKEN” \\
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0–duration-seconds 3600 \\
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0–query ‘Credentials.[AccessKeyId,SecretAccessKey,SessionToken]’ \\
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0–output text)
\u00a0
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0export AWS_ACCESS_KEY_ID=(echo”$CREDS” | awk ‘{print $1}’)
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0export AWS_SECRET_ACCESS_KEY=$(echo “$CREDS” | awk ‘{print $2}’)
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0export AWS_SESSION_TOKEN=$(echo “$CREDS” | awk ‘{print $3}’)
\u00a0
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0aws sts get-caller-identity
\u00a0
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0# Add the actual deployment commands here
\u00a0
\u00a0\u00a0rules:
\u00a0\u00a0\u00a0\u00a0– if: ‘$CI_COMMIT_BRANCH == “main”‘<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nThis example demonstrates how a pipeline can authenticate without storing permanent AWS access keys. In production, the image should be pinned to an approved version or digest, credentials must never be printed to logs, and the pipeline should use protected branches and appropriate deployment controls.<\/p>\n\n\n\n
The branch rule controls when the job runs, while the AWS IAM trust policy independently verifies which identity is permitted to assume the role.<\/p>\n\n\n\n
For example, if a pipeline only needs to update a specific application and invalidate a CloudFront distribution, we grant only the required permissions for those resources rather than giving the pipeline administrator-level access.<\/p>\n\n\n\n
This follows a simple principle:<\/p>\n\n\n\n
A deployment workload should have exactly the permissions required to perform its job not the permissions available to an administrator.<\/p>\n\n\n\n
What We Actually Changed<\/strong><\/h2>\n\n\n\nRather than treating Zero Trust as a theoretical security model, we applied it directly to the deployment workflow.<\/p>\n\n\n\n
Previously, the pipeline depended on credentials that could remain valid until they were manually rotated.<\/p>\n\n\n\n
With the OIDC-based approach:<\/p>\n\n\n\n
\n- GitLab CI\/CD requests an OIDC identity token.<\/li>\n\n\n\n
- AWS validates the token against the configured identity provider and IAM trust policy.<\/li>\n\n\n\n
- The pipeline assumes a dedicated IAM role.<\/li>\n\n\n\n
- AWS STS issues temporary credentials.<\/li>\n\n\n\n
- The role is restricted to the resources and actions required for the deployment.<\/li>\n\n\n\n
- The temporary credentials expire automatically.<\/li>\n<\/ol>\n\n\n\n
This reduces the operational overhead associated with manually rotating long-lived access keys.<\/p>\n\n\n\n
The Practical Challenge<\/strong><\/h2>\n\n\n\nThe transition was not simply a matter of enabling OIDC and changing a configuration.<\/p>\n\n\n\n
We had to review the existing deployment process and identify what the pipeline actually needed to do. Some permissions that had accumulated over time were no longer necessary, while others were required only for specific deployment stages.<\/p>\n\n\n\n
We therefore reviewed the pipeline actions and mapped them to the required AWS permissions before creating the final IAM policy.<\/p>\n\n\n\n
This is where the Zero Trust mindset became useful. Instead of starting with:<\/p>\n\n\n\n
“What access can we give this pipeline?”<\/p>\n\n\n\n
we started with:<\/p>\n\n\n\n
“What operations does this pipeline actually perform, and what is the minimum access required for those operations?”<\/p>\n\n\n\n
That change in approach helped us reduce unnecessary permissions without disrupting the deployment process.<\/p>\n\n\n\n
The Result<\/strong><\/h2>\n\n\n\nThe implementation gives us more than a security improvement.<\/p>\n\n\n\n
By replacing long-lived AWS credentials with OIDC-based temporary credentials, we can reduce the number of persistent secrets that need to be stored and rotated.<\/p>\n\n\n\n
At the same time, separating deployment permissions into a dedicated IAM role makes the access model easier to understand and audit.<\/p>\n\n\n\n
The resulting architecture provides:<\/p>\n\n\n\n
\n- No need to store long-lived AWS access keys in the CI\/CD workflow.<\/li>\n\n\n\n
- Temporary credentials for deployment workloads.<\/li>\n\n\n\n
- Dedicated IAM roles instead of shared administrative credentials.<\/li>\n\n\n\n
- More granular permissions.<\/li>\n\n\n\n
- Lower credential-rotation overhead.<\/li>\n\n\n\n
- A clearer audit trail of which workload accessed AWS and under which role.<\/li>\n<\/ul>\n\n\n\n
The important lesson is that Zero Trust does not require us to introduce another security product. It requires us to rethink how identity, permissions, and access are designed into the deployment process.<\/p>\n\n\n\n
Zero Trust as an Engineering Mindset<\/strong><\/h2>\n\n\n\nThis experience changed how we approached security in our DevOps workflows.<\/p>\n\n\n\n
Instead of trusting something because it was “inside” our infrastructure or because it belonged to our CI\/CD system, we verified its identity and explicitly defined what it was allowed to access.<\/p>\n\n\n\n
Don’t trust based on location.<\/p>\n\n\n\n
Trust based on verified identity, explicit authorization, and demonstrated necessity.<\/p>\n\n\n\n
For DevOps engineers, that is what Zero Trust looks like in practice: not a single tool or product, but a collection of engineering decisions that continuously verify who or what is requesting access, what they need, and how long that access should exist.<\/p>\n\n\n\n \n \n\n \n
\n Author<\/h2>\n <\/span>\n \n \n \n \n - \n \n \n
<\/div>\n <\/div>\n \n
to:<\/p>\n\n\n\n
GitLab CI\/CD \u2192 OIDC identity token \u2192 AWS IAM role \u2192 Temporary credentials<\/strong><\/p>\n\n\n\n For example, consider a backend microservices project deployed to AWS ECS using GitLab CI\/CD. Initially, the pipeline stored AWS access keys as GitLab CI\/CD variables. These credentials were long-lived, and their permissions extended beyond what the deployment job actually required.<\/p>\n\n\n\n We can change this approach by configuring OIDC federation between GitLab and AWS IAM. Instead of storing permanent AWS credentials, GitLab issues an identity token that AWS validates through an IAM OIDC identity provider. We then configure a dedicated IAM role with a trust policy restricted to the intended GitLab project and branch, allowing only authorized pipeline jobs to assume the role.<\/p>\n\n\n\n The following AWS IAM trust policy allows an identity token from a specific GitLab project on the main branch to assume the deployment role.<\/p>\n\n\n\n This trust policy restricts which GitLab workload can assume the IAM role. AWS must also have the corresponding GitLab OIDC provider configured with the appropriate issuer URL and audience.<\/p>\n\n\n\n Verifying identity is only one part of Zero Trust. We also need to define what the authenticated workload is allowed to do.<\/p>\n\n\n\n For example, the following IAM permissions policy allows the deployment role to describe a specific ECS service.<\/p>\n\n\n\n This is a deliberately limited example, not a complete ECS deployment policy. A real deployment may also require permissions to update services, register task definitions, access a container registry, or pass an approved task execution role. Those permissions should be added only when required and scoped to the relevant resources.<\/p>\n\n\n\n The key principle is that the pipeline should not receive administrator-level access just because it needs to deploy an application.<\/p>\n\n\n\n With the OIDC provider and IAM role configured, the GitLab pipeline can request an identity token and exchange it for temporary AWS credentials through AWS STS.<\/p>\n\n\n\n The following simplified .gitlab-ci.yml example demonstrates this flow:<\/p>\n\n\n\n This example demonstrates how a pipeline can authenticate without storing permanent AWS access keys. In production, the image should be pinned to an approved version or digest, credentials must never be printed to logs, and the pipeline should use protected branches and appropriate deployment controls.<\/p>\n\n\n\n The branch rule controls when the job runs, while the AWS IAM trust policy independently verifies which identity is permitted to assume the role.<\/p>\n\n\n\n For example, if a pipeline only needs to update a specific application and invalidate a CloudFront distribution, we grant only the required permissions for those resources rather than giving the pipeline administrator-level access.<\/p>\n\n\n\n This follows a simple principle:<\/p>\n\n\n\n A deployment workload should have exactly the permissions required to perform its job not the permissions available to an administrator.<\/p>\n\n\n\n Rather than treating Zero Trust as a theoretical security model, we applied it directly to the deployment workflow.<\/p>\n\n\n\n Previously, the pipeline depended on credentials that could remain valid until they were manually rotated.<\/p>\n\n\n\n With the OIDC-based approach:<\/p>\n\n\n\n This reduces the operational overhead associated with manually rotating long-lived access keys.<\/p>\n\n\n\n The transition was not simply a matter of enabling OIDC and changing a configuration.<\/p>\n\n\n\n We had to review the existing deployment process and identify what the pipeline actually needed to do. Some permissions that had accumulated over time were no longer necessary, while others were required only for specific deployment stages.<\/p>\n\n\n\n We therefore reviewed the pipeline actions and mapped them to the required AWS permissions before creating the final IAM policy.<\/p>\n\n\n\n This is where the Zero Trust mindset became useful. Instead of starting with:<\/p>\n\n\n\n “What access can we give this pipeline?”<\/p>\n\n\n\n we started with:<\/p>\n\n\n\n “What operations does this pipeline actually perform, and what is the minimum access required for those operations?”<\/p>\n\n\n\n That change in approach helped us reduce unnecessary permissions without disrupting the deployment process.<\/p>\n\n\n\n The implementation gives us more than a security improvement.<\/p>\n\n\n\n By replacing long-lived AWS credentials with OIDC-based temporary credentials, we can reduce the number of persistent secrets that need to be stored and rotated.<\/p>\n\n\n\n At the same time, separating deployment permissions into a dedicated IAM role makes the access model easier to understand and audit.<\/p>\n\n\n\n The resulting architecture provides:<\/p>\n\n\n\n The important lesson is that Zero Trust does not require us to introduce another security product. It requires us to rethink how identity, permissions, and access are designed into the deployment process.<\/p>\n\n\n\n This experience changed how we approached security in our DevOps workflows.<\/p>\n\n\n\n Instead of trusting something because it was “inside” our infrastructure or because it belonged to our CI\/CD system, we verified its identity and explicitly defined what it was allowed to access.<\/p>\n\n\n\n Don’t trust based on location.<\/p>\n\n\n\n Trust based on verified identity, explicit authorization, and demonstrated necessity.<\/p>\n\n\n\n For DevOps engineers, that is what Zero Trust looks like in practice: not a single tool or product, but a collection of engineering decisions that continuously verify who or what is requesting access, what they need, and how long that access should exist.<\/p>\n\n\n\n \n \n\n \n Example 1: Restricting Who Can Assume the IAM Role<\/strong><\/h3>\n\n\n\n
{
\u00a0\u00a0“Version”: “2012-10-17”,
\u00a0\u00a0“Statement”: [
\u00a0\u00a0\u00a0\u00a0{
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“Effect”: “Allow”,
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“Principal”: {
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“Federated”: “arn:aws:iam::123456789012:oidc-provider\/gitlab.com”
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0},
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“Action”: “sts:AssumeRoleWithWebIdentity”,
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“Condition”: {
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“StringEquals”: {
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“gitlab.com:aud”: “sts.amazonaws.com”,
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“gitlab.com:sub”: “project_path:mygroup\/backend-api:ref_type:branch:ref:main”
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0}
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0}
\u00a0\u00a0\u00a0\u00a0}
\u00a0\u00a0]
}<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nExample 2: Applying Least-Privilege Permissions<\/strong><\/h3>\n\n\n\n
{
\u00a0\u00a0“Version”: “2012-10-17”,
\u00a0\u00a0“Statement”: [
\u00a0\u00a0\u00a0\u00a0{
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“Effect”: “Allow”,
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“Action”: [
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“ecs:DescribeServices”
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0],
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“Resource”: “arn:aws:ecs:ap-south-1:123456789012:service\/backend-cluster\/backend-service”
\u00a0\u00a0\u00a0\u00a0}
\u00a0\u00a0]
}<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nExample 3: Obtaining Temporary Credentials in GitLab CI\/CD<\/strong><\/h3>\n\n\n\n
deploy:
\u00a0\u00a0image: amazon\/aws-cli:2
\u00a0
\u00a0\u00a0id_tokens:
\u00a0\u00a0\u00a0\u00a0AWS_ID_TOKEN:
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0aud: sts.amazonaws.com
\u00a0
\u00a0\u00a0variables:
\u00a0\u00a0\u00a0\u00a0AWS_DEFAULT_REGION: ap-south-1
\u00a0\u00a0\u00a0\u00a0AWS_ROLE_ARN: arn:aws:iam::123456789012:role\/gitlab-backend-deploy
\u00a0
\u00a0\u00a0script:
\u00a0\u00a0\u00a0\u00a0– |
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0CREDS=$(aws sts assume-role-with-web-identity \\
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0–role-arn “$AWS_ROLE_ARN” \\
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0–role-session-name “gitlab-deploy-$CI_PIPELINE_ID” \\
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0–web-identity-token “$AWS_ID_TOKEN” \\
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0–duration-seconds 3600 \\
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0–query ‘Credentials.[AccessKeyId,SecretAccessKey,SessionToken]’ \\
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0–output text)
\u00a0
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0export AWS_ACCESS_KEY_ID=(echo”$CREDS” | awk ‘{print $1}’)
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0export AWS_SECRET_ACCESS_KEY=$(echo “$CREDS” | awk ‘{print $2}’)
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0export AWS_SESSION_TOKEN=$(echo “$CREDS” | awk ‘{print $3}’)
\u00a0
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0aws sts get-caller-identity
\u00a0
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0# Add the actual deployment commands here
\u00a0
\u00a0\u00a0rules:
\u00a0\u00a0\u00a0\u00a0– if: ‘$CI_COMMIT_BRANCH == “main”‘<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nWhat We Actually Changed<\/strong><\/h2>\n\n\n\n
\n
The Practical Challenge<\/strong><\/h2>\n\n\n\n
The Result<\/strong><\/h2>\n\n\n\n
\n
Zero Trust as an Engineering Mindset<\/strong><\/h2>\n\n\n\n
Author<\/h2>\n <\/span>\n
\n \n
<\/div>\n <\/div>\n \n