OIDC authentication for CI/CD in Terraform - Time & Space Complexity

Time Complexity: OIDC authentication for CI/CD

O(n)

Understanding Time Complexity

We want to understand how the time needed to set up OIDC authentication in CI/CD changes as we add more resources.

How does the work grow when we add more roles or policies in Terraform?

Scenario Under Consideration

Analyze the time complexity of the following code snippet.

resource "aws_iam_openid_connect_provider" "oidc_provider" {
  url = var.oidc_url
  client_id_list = ["sts.amazonaws.com"]
  thumbprint_list = [var.thumbprint]
}

resource "aws_iam_role" "ci_cd_role" {
  count = var.role_count
  name = "ci-cd-role-${count.index}"
  assume_role_policy = jsonencode({
    Statement = [{
      Effect = "Allow"
      Principal = { Federated = aws_iam_openid_connect_provider.oidc_provider.arn }
      Action = "sts:AssumeRoleWithWebIdentity"
    }]
  })
}

This code creates one OIDC provider and multiple IAM roles for CI/CD, each trusting the provider.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

• Primary operation: Creating multiple IAM roles using count to repeat the resource block.
• How many times: The number of roles equals var.role_count, so the role creation repeats that many times.

How Execution Grows With Input

As you increase the number of roles, Terraform creates more resources one by one.

Input Size (n)	Approx. Operations
10	10 role creations
100	100 role creations
1000	1000 role creations

Pattern observation: The work grows directly with the number of roles you add.

Final Time Complexity

Time Complexity: O(n)

This means the time to create roles grows linearly as you add more roles.

Common Mistake

[X] Wrong: "Adding more roles won't affect the time much because Terraform handles it fast."

[OK] Correct: Each role is a separate resource, so more roles mean more work and longer apply times.

Interview Connect

Understanding how resource count affects deployment time helps you plan scalable infrastructure and explain your design choices clearly.

Self-Check

"What if we replaced count with for_each using a map of roles? How would the time complexity change?"

Practice

1. What is the main benefit of using OIDC authentication in CI/CD pipelines with Terraform?

easy

A. It disables all access restrictions for faster builds.

B. It automatically deploys code without any manual approval.

C. It replaces Terraform with a different infrastructure tool.

D. It allows secure authentication without storing passwords in the pipeline.

Solution

1. Step 1: Understand OIDC purpose in CI/CD

   OIDC provides a secure way for pipelines to prove identity without passwords.

2. Step 2: Connect to Terraform usage

   Terraform can create roles that trust OIDC tokens, avoiding password storage.

3. Final Answer:

   It allows secure authentication without storing passwords in the pipeline. -> Option D

4. Quick Check:

   OIDC = passwordless secure authentication [OK]

Hint: OIDC means no passwords needed in CI/CD [OK]

Common Mistakes:

• Thinking OIDC automates deployment without approval
• Confusing OIDC with replacing Terraform
• Assuming OIDC disables access controls

2. Which Terraform resource block correctly defines an IAM role trusting GitHub Actions OIDC provider?

easy

A. resource "aws_iam_role" "github_oidc_role" {
assume_role_policy = jsonencode({
Version = "2012-10-17",
Statement = [{
Effect = "Allow",
Principal = { Federated = "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com" },
Action = "sts:AssumeRoleWithWebIdentity"
}]
})
}

B. resource "aws_iam_role" "github_oidc_role" {
assume_role_policy = jsonencode({
Version = "2012-10-17",
Statement = [{
Effect = "Allow",
Principal = { Service = "github.com" },
Action = "sts:AssumeRole"
}]
})
}

C. resource "aws_iam_role" "github_oidc_role" {
assume_role_policy = jsonencode({
Version = "2012-10-17",
Statement = [{
Effect = "Allow",
Principal = { AWS = "arn:aws:iam::123456789012:root" },
Action = "sts:AssumeRoleWithWebIdentity"
}]
})
}

D. resource "aws_iam_role" "github_oidc_role" {
assume_role_policy = jsonencode({
Version = "2012-10-17",
Statement = [{
Effect = "Allow",
Principal = { Federated = "arn:aws:iam::123456789012:oidc-provider/github.com" },
Action = "sts:AssumeRoleWithWebIdentity"
}]
})
}

Solution

1. Step 1: Identify correct OIDC provider ARN format

   The OIDC provider ARN for GitHub Actions uses 'token.actions.githubusercontent.com'.

2. Step 2: Check assume_role_policy structure

   The policy must allow 'sts:AssumeRoleWithWebIdentity' with Principal as Federated and correct ARN.

3. Final Answer:

   The resource block with Federated principal using 'token.actions.githubusercontent.com' and 'sts:AssumeRoleWithWebIdentity' action. -> Option A

4. Quick Check:

   Correct OIDC ARN + sts:AssumeRoleWithWebIdentity = resource "aws_iam_role" "github_oidc_role" { assume_role_policy = jsonencode({ Version = "2012-10-17", Statement = [{ Effect = "Allow", Principal = { Federated = "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com" }, Action = "sts:AssumeRoleWithWebIdentity" }] }) } [OK]

Hint: OIDC provider ARN uses token.actions.githubusercontent.com [OK]

Common Mistakes:

• Using Service principal instead of Federated
• Wrong OIDC provider ARN format
• Using sts:AssumeRole instead of sts:AssumeRoleWithWebIdentity

3. Given this Terraform snippet for an IAM role trust policy, what is the effect of the condition block?

condition = {
  StringEquals = {
    "token.actions.githubusercontent.com:sub" = "repo:myorg/myrepo:ref:refs/heads/main"
  }
}

medium

A. Allows any GitHub repo to assume the role.

B. Restricts role assumption to the main branch of myorg/myrepo only.

C. Blocks all role assumptions from GitHub Actions.

D. Allows only forks of myorg/myrepo to assume the role.

Solution

1. Step 1: Understand the condition key

   The condition uses 'token.actions.githubusercontent.com:sub' to specify the GitHub repo and branch.

2. Step 2: Interpret the value

   The value 'repo:myorg/myrepo:ref:refs/heads/main' restricts access to the main branch of that repo only.

3. Final Answer:

   Restricts role assumption to the main branch of myorg/myrepo only. -> Option B

4. Quick Check:

   Condition limits to specific repo and branch = Restricts role assumption to the main branch of myorg/myrepo only. [OK]

Hint: Condition with repo and ref limits branch access [OK]

Common Mistakes:

• Ignoring the branch restriction in condition
• Assuming condition allows all repos
• Confusing forks with original repo access

4. You wrote this Terraform assume_role_policy but your CI/CD pipeline fails to authenticate:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Federated": "arn:aws:iam::123456789012:oidc-provider/github.com" },
    "Action": "sts:AssumeRoleWithWebIdentity"
  }]
}

What is the most likely error?

medium

A. The Principal should use 'Service' instead of 'Federated'.

B. The Action should be 'sts:AssumeRole' instead of 'sts:AssumeRoleWithWebIdentity'.

C. The OIDC provider ARN is incorrect; it should be 'token.actions.githubusercontent.com'.

D. The Version date is invalid and must be updated.

Solution

1. Step 1: Check the OIDC provider ARN

   The ARN 'arn:aws:iam::123456789012:oidc-provider/github.com' is incorrect for GitHub Actions.

2. Step 2: Identify correct ARN for GitHub Actions

   The correct ARN uses 'token.actions.githubusercontent.com' as the OIDC provider host.

3. Final Answer:

   The OIDC provider ARN is incorrect; it should be 'token.actions.githubusercontent.com'. -> Option C

4. Quick Check:

   Wrong OIDC ARN causes auth failure = The OIDC provider ARN is incorrect; it should be 'token.actions.githubusercontent.com'. [OK]

Hint: Check OIDC ARN spelling carefully for GitHub Actions [OK]

Common Mistakes:

• Using 'sts:AssumeRole' instead of 'sts:AssumeRoleWithWebIdentity'
• Confusing Federated with Service principal
• Ignoring ARN format for OIDC provider

5. You want to create a Terraform IAM role for GitHub Actions that only allows workflows from the 'release' branch of 'myorg/myrepo' to assume it. Which condition block correctly enforces this restriction?

hard

A. {
"StringEquals": {
"token.actions.githubusercontent.com:sub": "repo:myorg/myrepo:ref:refs/heads/release"
}
}

B. {
"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:myorg/myrepo:ref:refs/heads/*"
}
}

C. {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
}
}

D. {
"StringNotEquals": {
"token.actions.githubusercontent.com:sub": "repo:myorg/myrepo:ref:refs/heads/main"
}
}

Solution

1. Step 1: Understand the condition key and value

   To restrict to the 'release' branch, the condition must match 'repo:myorg/myrepo:ref:refs/heads/release'.

2. Step 2: Choose correct operator

   'StringEquals' ensures exact match, so only 'release' branch is allowed.

3. Final Answer:

   The condition block with StringEquals matching 'repo:myorg/myrepo:ref:refs/heads/release'. -> Option A

4. Quick Check:

   Exact branch match uses StringEquals with correct ref [OK]

Hint: Use StringEquals with exact repo and branch ref [OK]

Common Mistakes:

• Using StringLike with wildcard allowing all branches
• Checking audience (aud) instead of subject (sub)
• Using StringNotEquals which excludes main but allows others