Exercise 1: OIDC & Credential-Free Deployment (~15 min)

Goal: Understand the supply chain attack that OIDC prevents, configure credential-free deployment with properly scoped trust, and apply defense-in-depth with action pinning.

📝 Open docs/oidc-comparison-worksheet.md — record your BEFORE/AFTER observations as you work through this exercise.

Threat Framing: The Supply Chain Attack That OIDC Prevents

The Attack Chain:

Step 1: AZURE_CREDENTIALS leaked
        (log file exposure / compromised runner / insider / dependency attack)
    ↓
Step 2: Attacker authenticates as your service principal
        (the secret is long-lived — it doesn't expire for 1-2 years)
    ↓
Step 3: Attacker pushes malicious container image to your registry
        (they have full deployment permissions)
    ↓
Step 4: Malicious image deployed to your production cluster
        (indistinguishable from a legitimate deployment)
    ↓
Step 5: Production compromised — data exfiltrated, service disrupted
        (you may not know for days or weeks)

┌─────────────────────────────────────────────────────────┐
│ OIDC breaks this chain at Step 1:                       │
│ There is NO long-lived credential to steal.             │
│ The OIDC token is short-lived (~10 min), scoped to a    │
│ specific workflow run, and tied to a specific            │
│ repository, branch, and commit SHA.                     │
└─────────────────────────────────────────────────────────┘

Note: This is not hypothetical. In March 2025, the tj-actions/changed-files supply chain attack (CVE-2025-30066) demonstrated that compromised CI/CD components can exfiltrate secrets from thousands of repositories. OIDC eliminates the most valuable target — long-lived deployment credentials.

Step 1: Review the BEFORE Workflow

Open .github/workflows/build-deploy.yml and examine the authentication section:

    # ⚠️ INSECURE: Long-lived static credential
    - name: Azure Login
      uses: azure/login@v2
      with:
        creds: $

What’s wrong here:

• AZURE_CREDENTIALS is a JSON blob containing a client ID, client secret, tenant ID, and subscription ID
• The client secret is long-lived (default: 1-2 years)
• Anyone with access to this secret can authenticate as this service principal
• Rotation is manual and error-prone

Step 2: Configure Azure Federated Credential

Create a federated identity credential that trusts GitHub Actions OIDC tokens:

# Get your Azure AD Application (Service Principal) Object ID
APP_OBJECT_ID=$(az ad app list --display-name "sp-devsecops-ws3-deploy" --query "[0].id" -o tsv)

# Create federated credential for the main branch
az ad app federated-credential create \
  --id $APP_OBJECT_ID \
  --parameters '{
    "name": "github-actions-main",
    "issuer": "https://token.actions.githubusercontent.com",
    "subject": "repo:{owner}/{repo}:ref:refs/heads/main",
    "audiences": ["api://AzureADTokenExchange"],
    "description": "GitHub Actions OIDC for main branch deployments"
  }'

Store the non-secret identifiers as repository variables (not secrets):

# These are NOT secrets — they are public identifiers
gh variable set AZURE_CLIENT_ID --body "<your-client-id>"
gh variable set AZURE_TENANT_ID --body "<your-tenant-id>"
gh variable set AZURE_SUBSCRIPTION_ID --body "<your-subscription-id>"

Step 2.5: Understand Subject Claim Scoping — The Most Important Security Decision

The subject field in the federated credential determines WHO can use this trust. This is the most critical security decision in OIDC configuration.

Look at the subject claim you just configured:

"subject": "repo:{owner}/{repo}:ref:refs/heads/main"

This means: ONLY the workflow running on the main branch of this specific repository can authenticate. But what if you configured it differently?

Verify your configuration:

1. Read back the subject claim you configured — is it scoped to main? ✅
2. Think: What would happen if you used repo:org/* (wildcard)? → Any repo in the org could deploy to your cloud. A compromised experimental repo could push to production.
3. Think: For a production deployment at your company, which scope would you use? Why?

⚠️ Wildcard subject claims are the OIDC equivalent of sharing a password. They defeat the purpose of federated identity. Always scope to the narrowest possible claim — specific repo + specific branch or environment.

Step 3: Review the AFTER Workflow

Open .github/workflows/build-deploy-oidc.yml and compare the authentication section:

permissions:
  id-token: write   # Required for OIDC token exchange
  contents: read

steps:
    # ✅ SECURE: Short-lived OIDC token, no stored secrets
    - name: Azure Login (OIDC)
      uses: azure/login@v2
      with:
        client-id: $
        tenant-id: $
        subscription-id: $

What changed:

• No secrets.AZURE_CREDENTIALS — no long-lived secret anywhere
• permissions: id-token: write — the workflow requests an OIDC token from GitHub
• Azure validates the token against the federated credential — trusting the identity, not a secret
• The token is short-lived (valid for ~10 minutes) and scoped to this specific workflow run

⚠️ Defense-in-Depth: Pin Actions to Commit SHAs

OIDC protects your credentials. But what if the azure/login action ITSELF is compromised? The 2025 supply chain attacks showed that action tags can be hijacked.

# ❌ Mutable tag — can be hijacked if the action repo is compromised
uses: azure/login@v2

# ✅ Pinned to specific commit SHA — immutable, tamper-proof
uses: azure/login@6c251865b4e6290e7b78be643ea2d005bc51f69a  # v2.3.1

Complete supply chain integrity requires all three:

1. OIDC — protects deployment credentials (no secrets to steal)
2. SHA pinning — protects workflow actions (no tags to hijack)
3. Attestation — protects build artifacts (Exercise 2)

Step 4: Run the OIDC Workflow

# Trigger the OIDC workflow
gh workflow run build-deploy-oidc.yml --ref main

# Watch the run
gh run watch

Step 5: Verify OIDC Token Exchange

After the workflow completes, inspect the logs:

# Get the latest run ID
RUN_ID=$(gh run list --workflow=build-deploy-oidc.yml --limit 1 --json databaseId --jq '.[0].databaseId')

# View the login step logs
gh run view $RUN_ID --log | grep -A 5 "Azure Login"

Look for: Login successful using OIDC — this confirms the federated token exchange worked.

Step 6: BEFORE vs. AFTER Comparison

Step 7: Clean Up the Static Secret

# Now that OIDC is working, the static secret is no longer needed
gh secret delete AZURE_CREDENTIALS

Key Insight

OIDC is not a convenience feature. It is a supply chain integrity control that eliminates an entire class of attack — stolen deployment credentials. Every workflow run gets a unique, short-lived, auditable token tied to a specific repository, branch, and commit.

Tip: Run scripts/verify-exercise1.sh to validate your Exercise 1 completion.