Provider Authentication in Production

Provider authentication is the operational control for credential security. The wrong authentication is the most common production credential leak. The lesson teaches the production patterns for authentication.

The credential hierarchy

A hierarchy of credentials, from most to least secure:

1. Workload identity. The runtime (EC2, ECS, Lambda) assumes an IAM role. No credentials are stored.
2. OIDC. The CI/CD pipeline assumes an IAM role via OpenID Connect. No long-lived credentials.
3. IAM role assumption. The engineer assumes an IAM role via aws sts assume-role. Short-lived credentials.
4. Instance profile. The runtime has an IAM role attached at launch. No credentials are stored.
5. Environment variables. Short-lived credentials in environment variables. Used by CI/CD pipelines.
6. AWS profile. Long-lived credentials in ~/.aws/credentials. Avoid in production.
7. Static access keys. Hard-coded access keys. Never use.

The courses recommendation: use workload identity or OIDC.

Workload identity

The runtime (EC2, ECS, EKS, Lambda) has an IAM role attached at launch. The role has the permissions the runtime needs. The runtime does not have credentials stored.

provider "aws" {
  region = "us-east-1"
  # No credentials: the provider uses the instance profile
}

The provider uses the instance profile. The credentials are short-lived and rotated by the platform.

OIDC for CI/CD

The CI/CD pipeline uses OIDC to assume an IAM role. The pipeline does not have long-lived credentials.

# GitHub Actions example
permissions:
  id-token: write
  contents: read

jobs:
  terraform:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::PRODUCTION_ACCOUNT:role/github-actions-terraform
          aws-region: us-east-1
      - run: terraform init
      - run: terraform plan
      - run: terraform apply

The aws-actions/configure-aws-credentials action uses OIDC to assume the IAM role. The credentials are short-lived and do not require long-lived access keys.

IAM role assumption

The engineer assumes an IAM role via aws sts assume-role. The credentials are short-lived (typically 1 hour).

# Assume the role
aws sts assume-role \
  --role-arn "arn:aws:iam::PRODUCTION_ACCOUNT:role/terraform" \
  --role-session-name "terraform-session"

# Use the credentials
export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...

The credentials expire after the session. The credentials are not stored.

The rejected pattern

A common rejected pattern is to use long-lived access keys:

provider "aws" {
  region     = "us-east-1"
  access_key = "AKIAIOSFODNN7EXAMPLE"
  secret_key = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
}

The hard-coded credentials are in the configuration. The configuration is in Git. The Git history has the credentials. A leaked credential is a security incident.

The fix is to use workload identity or OIDC.

The CI/CD environment

The CI/CD pipeline uses short-lived credentials:

# GitHub Actions with OIDC
- uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::PRODUCTION_ACCOUNT:role/ci-terraform
    aws-region: us-east-1
    duration: 3600  # 1 hour

The credentials are short-lived. The CI pipeline does not have long-lived credentials.

The credential rotation

When a credential is compromised:

1. Revoke the credential immediately. Delete the IAM access key, deactivate the role, or revoke the OIDC trust.
2. Audit the access. Use CloudTrail to see what was accessed with the credential.
3. Document the incident. The runbook should be followed.
4. Implement the fix. Use workload identity or OIDC.

The course has a dedicated runbook for credential rotation.

What comes next

The next lesson is managing secrets — how to keep secrets out of the configuration and the state.

Verification