
# Solving the AWS OIDC Chicken-and-Egg Problem with GitHub Actions

AWS + GitHub OIDC: Escape from Long-Lived Keys

Everyone wants to get rid of IAM access keys in CI/CD. They’re risky, hard to rotate, and inevitably leak.

AWS solved this with OIDC federation: your GitHub Actions runner requests a short-lived token directly from AWS STS using a signed OIDC identity, no secrets required.

It sounds perfect. But there’s one catch:
👉 To configure OIDC in the first place, you need AWS credentials.

Welcome to the bootstrap paradox.

## Environment Setup

```bash
mkdir oidc-bootstrap
cd oidc-bootstrap
```

We’ll explore this bootstrap step from first principles and then run a full demo of GitHub Actions authenticating into AWS without static keys.

## The Chicken-and-Egg Problem

First principles:

- AWS will only trust GitHub’s OIDC provider once you explicitly register it.

- Terraform needs state storage in S3, but you can’t even terraform init unless the bucket exists.

- Docker pushes to ECR fail if the repo doesn’t exist.

So how do you create those resources… if the very credentials you need to do so don't exist yet?

Answer: you bootstrap once with minimal, temporary credentials.

## Bootstrapping the OIDC Trust

Step 1 — Create an OIDC provider in IAM:

```bash
aws iam create-open-id-connect-provider \
  --url https://token.actions.githubusercontent.com \
  --thumbprint-list 6938fd4d98bab03faadb97b34396831e3780aea1 \
  --client-id-list sts.amazonaws.com
```

Step 2 — Create an IAM role trusted by GitHub:

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::<account_id>:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:moabukar/oidc-bootstrap:*"
        }
      }
    }
  ]
}
```

```bash
aws iam create-role \
  --role-name github-oidc-role \
  --assume-role-policy-document file://trust-policy.json
```

Attach permissions:

```bash
aws iam attach-role-policy \
  --role-name github-oidc-role \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3FullAccess
```

At this point, AWS trusts GitHub. Now you can safely delete the bootstrap credentials.

## GitHub Actions in Steady State

No long-lived IAM keys needed — just OIDC:

```yaml
name: Deploy
on: [push]

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::<account_id>:role/github-oidc-role
          aws-region: eu-west-2

      - run: aws s3 ls
```

GitHub Actions fetches an OIDC token, exchanges it for AWS STS creds, and runs with no static secrets.

## Example Scenarios

### A. Terraform Remote State (S3)

Bootstrap credentials create S3 bucket + DynamoDB table.

Switch Terraform backend to S3.

All future terraform apply runs in GitHub Actions via OIDC.

### B. ECR Repository

Bootstrap credentials create repo with aws ecr create-repository.

Pipelines authenticate via OIDC and push images.

### C. Lambda Deployment

Bootstrap user creates role + trust policy.

GitHub OIDC assumes role and deploys Lambda updates seamlessly.

## Test

To see the token exchange in action:

```bash
aws sts get-caller-identity
```

From GitHub Actions, the output shows the IAM role ARN, not a static user.
That’s how you know OIDC federation is working.

## Lessons Learned

- Bootstrap once. OIDC can't configure itself.

- Scope narrowly. Create the minimum S3/ECR/roles you need, then cut off bootstrap access.

- Delete long-lived keys. After setup, your AWS account should run 100% keyless.

## Pain Point: The Paradox in Practice

This bootstrap paradox frustrates everyone:

- New engineers expect OIDC to “just work” and wonder why Terraform can’t even create its own state bucket.

- Security teams get nervous when they see IAM users reappearing.

The fix is boring but necessary: one minimal bootstrap, then never again.

Solving the AWS OIDC Chicken-and-Egg Problem with GitHub Actions


## Introduction

### What Are We Building? 🚀

We're building a **secure GitHub Actions pipeline** that deploys to **GKE** without storing any credentials in GitHub. Instead of using service account keys, we'll use **Workload Identity Federation** (OIDC) so GitHub can impersonate a GCP Service Account.

**No long-lived keys. No kubeconfig. Just secure, modern CI/CD.**

### Why This Matters

- 🔒 No secrets stored in GitHub  
- 🔐 Short-lived, auditable credentials via OIDC  
- 🧑‍💻 First-class support from Google + GitHub  
- 🔁 Reusable pattern for any GCP service, not just GKE  

---

## Architecture

![gha-gke-wif](/images/gha-gke-wif.png)

**Flow:**

1. GitHub Workflow uses OIDC token
2. Google validates identity and issues short-lived credentials
3. Workflow impersonates a GCP Service Account
4. Runs `kubectl` or `gcloud` to deploy to GKE

---

## Prerequisites

- GCP project + billing enabled  
- A GKE Autopilot or Standard cluster  
- GitHub repo (private or public)  
- Terraform 1.3+ and `gcloud` CLI  
- Your app packaged into a container

---

## Terraform Setup

New Autopilot cluster

```hcl
provider "google" {
  project = var.project_id
  region  = var.region
}

resource "google_container_cluster" "autopilot" {
  name     = var.cluster_name
  location = var.region

  enable_autopilot = true

  workload_identity_config {
    workload_pool = "${var.project_id}.svc.id.goog"
  }

  release_channel {
    channel = "REGULAR"
  }

  ip_allocation_policy {}
  networking_mode = "VPC_NATIVE"
}
```

### Workload Identity Federation

```hcl
resource "google_iam_workload_identity_pool" "github_pool" {
  workload_identity_pool_id = "github"
  display_name              = "GitHub Actions Pool"
}

resource "google_iam_workload_identity_pool_provider" "github_provider" {
  workload_identity_pool_id = google_iam_workload_identity_pool.github_pool.workload_identity_pool_id
  workload_identity_pool_provider_id = "github-provider"
  display_name = "GitHub OIDC"
  attribute_mapping = {
    "google.subject"         = "assertion.sub"
    "attribute.repository"   = "assertion.repository"
  }

  oidc {
    issuer_uri = "https://token.actions.githubusercontent.com"
  }
}

resource "google_service_account" "gha_deployer" {
  account_id   = "gha-deployer"
  display_name = "GitHub Actions deployer"
}

resource "google_service_account_iam_member" "allow_impersonation" {
  service_account_id = google_service_account.gha_deployer.name
  role               = "roles/iam.workloadIdentityUser"
  member             = "principalSet://iam.googleapis.com/${google_iam_workload_identity_pool.github_pool.name}/attribute.repository/${var.github_repo}"
}

resource "google_project_iam_member" "deploy_permissions" {
  role   = "roles/container.developer"
  member = "serviceAccount:${google_service_account.gha_deployer.email}"
}
```

### Variables

```hcl
variable "project_id" {}
variable "region" {
  default = "us-central1"
}
variable "cluster_name" {
  default = "gha-ci-cluster"
}
variable "github_repo" {
  description = "GitHub repo in format owner/repo"
}
```

### App deployment

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 1
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web
        image: nginx
        ports:
        - containerPort: 80

```

### GitHub Actions Setup

```yaml
name: Deploy to GKE via Workload Identity

on:
  push:
    branches: [ main ]

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout
      uses: actions/checkout@v3

    - name: Authenticate with Google Cloud
      uses: google-github-actions/auth@v1
      with:
        token_format: "id_token"
        workload_identity_provider: "projects/<PROJECT_NUM>/locations/global/workloadIdentityPools/github/providers/github-provider"
        service_account: "gha-deployer@<PROJECT_ID>.iam.gserviceaccount.com"

    - name: Setup gcloud
      uses: google-github-actions/setup-gcloud@v1

    - name: Configure kubectl
      run: |
        gcloud container clusters get-credentials ${{ secrets.CLUSTER_NAME }} --region ${{ secrets.REGION }}

    - name: Deploy app
      run: |
        kubectl apply -f k8s/
```

### Test it

```bash
git push origin main
```

- GitHub will authenticate using OIDC
- GCP will issue a token
- Workflow will deploy to GKE without a service account key

---

## Key Takeaways

🔑 Workload Identity Federation = no key rotation, no secret sprawl

🛡 GitHub OIDC → GCP IAM is the new best practice

☁️ Works for GKE, Cloud Run, Cloud Storage, etc.

✅ GitHub auth + setup-gcloud = seamless GKE integration

## Conclusion

You've now built a secure, automated CI/CD pipeline using GitHub Actions + GKE + Workload Identity Federation. This is production-grade infra without touching a single JSON/token key.

Give it a try and see how it can simplify your GKE deployments!


In this deep dive, we set up a secure, production-ready CI/CD pipeline from GitHub Actions to GKE using Workload Identity Federation—no secrets needed.

Posts tagged with: oidc