Workload Identity Federation Without Long-Lived Keys

By Khimananda Oli | Last reviewed: August 2026

Storing static access keys in CI/CD environments is a critical security liability that exposes organizations to credential theft and lateral movement attacks. Modern platforms now support workload identity federation without long-lived keys, replacing permanent secrets with ephemeral tokens exchanged via OpenID Connect (OIDC). This approach binds cloud permissions directly to specific pipeline runs, ensuring credentials expire automatically and cannot be reused if leaked. Transitioning to this model requires configuring trust relationships between your identity provider and cloud platform rather than managing user accounts.

How does workload identity federation without long-lived keys actually work?

The mechanism relies on establishing a cryptographic trust relationship between your CI/CD platform and your cloud provider, eliminating the need to store static secrets. When a pipeline job starts, the CI platform generates an OIDC token containing claims about the execution context: repository name, branch, commit SHA, environment, and actor. This token is cryptographically signed by the CI provider's private key.

Your cloud IAM service has been pre-configured with the CI provider's public signing key and a set of trust policies. Upon receiving the token, the cloud provider validates the signature and evaluates the claims against your configured conditions. If the claims match an allowed pattern (e.g., "repo:myorg/myapp" AND "environment:production"), the cloud provider issues temporary credentials valid for typically 15–60 minutes. These credentials are injected into the runtime environment and used for API calls, then discarded when the job completes.

This differs fundamentally from traditional approaches where you create an IAM user or service account, generate an access key, and store it as an encrypted variable in your CI platform. With secure secrets management practices, those keys still exist persistently and can be exfiltrated. Federation removes the secret entirely; there is nothing to steal because credentials only materialize during authorized execution contexts.

Key components of the trust chain

• OIDC Provider Configuration: The cloud provider must know the CI platform's issuer URL and JWKS endpoint to validate token signatures.
• Trust Policy / Role Mapping: Defines which token claims map to which cloud roles, using condition operators like StringEquals or StringLike.
• Token Exchange Endpoint: The STS or equivalent API that accepts the OIDC token and returns temporary credentials.
• SDK/CLI Integration: Native support in cloud SDKs to automatically detect and use federated credentials without code changes.

How do you configure AWS IAM Roles for GitHub Actions OIDC?

AWS uses IAM Identity Provider and IAM Roles to implement workload identity federation without long-lived keys for GitHub Actions. The setup involves creating an OIDC identity provider entity, then a role with a trust policy that restricts assumption to specific repositories and branches.

# Create the OIDC identity provider for GitHub Actions
aws iam create-open-id-connect-provider \
  --url https://token.actions.githubusercontent.com \
  --client-id-list sts.amazonaws.com \
  --thumbprint-list 6938fd4d98bab03faadb97b34396831e3780aea1

# Trust policy restricting to specific repo and environment
cat > trust-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::ACCOUNT_ID:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
          "token.actions.githubusercontent.com:sub": "repo:myorg/myapp:environment:production"
        }
      }
    }
  ]
}
EOF

aws iam create-role \
  --role-name GitHubActions-DeployProd \
  --assume-role-policy-document file://trust-policy.json

In your GitHub Actions workflow, use the official aws-actions/configure-aws-credentials action with role-to-assume instead of access keys. The action automatically requests the OIDC token, exchanges it, and configures the AWS SDK:

permissions:
  id-token: write   # REQUIRED for OIDC token generation
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::ACCOUNT_ID:role/GitHubActions-DeployProd
          aws-region: ap-south-1
      - run: aws s3 sync ./dist s3://my-app-prod-bucket

A common mistake is omitting id-token: write permission at the job or workflow level. Without it, GitHub will not issue the OIDC token and authentication fails silently or with cryptic errors. Always specify the minimum required claim conditions in your trust policy; allowing all repositories in an organization grants excessive blast radius if any repo is compromised.

What are the differences between OIDC federation and traditional access keys?

Understanding the operational and security trade-offs helps justify the migration effort to stakeholders. While traditional keys are simpler to set up initially, they accumulate technical debt and risk that compounds over time. For teams managing infrastructure across multiple clouds, understanding these distinctions is as fundamental as choosing between major cloud providers.

How do you troubleshoot OIDC federation failures in production pipelines?

Federation misconfigurations produce opaque errors because the failure occurs before your application code runs. Systematic debugging requires understanding where in the trust chain the breakdown happens. Teams operating Kubernetes on AWS encounter similar issues with IRSA (IAM Roles for Service Accounts), which uses the same underlying STS WebIdentity mechanism.

1. Verify OIDC token generation: Add a debug step to print the token (redacted) or decode it locally. Confirm the sub, aud, and custom claims match your trust policy exactly. GitHub's token format changed in 2024; older blog posts may reference outdated claim structures.
2. Validate trust policy conditions: Use aws sts assume-role-with-web-identity manually with the captured token to isolate IAM from CI. If this fails, the issue is policy, not pipeline. Check for trailing slashes in issuer URLs — AWS is strict about exact string matching.
3. Check clock skew tolerance: OIDC validation rejects tokens with >5 minute skew. Ensure CI runners have synchronized clocks. Self-hosted runners on VMs with drifted NTP are a frequent cause of intermittent failures.
4. Confirm role permissions: The assumed role must have both the trust policy allowing federation AND attached permission policies granting actual resource access. A role with perfect trust but no S3 permissions fails at the API call, not authentication.
5. Review CloudTrail / Audit Logs: Failed AssumeRoleWithWebIdentity events include the reason code. AccessDenied indicates policy mismatch; InvalidIdentityToken indicates signature or issuer problems; ExpiredToken indicates timing issues.

For Azure and GCP, the diagnostic approach is identical but tooling differs. Azure uses az login --federated and GCP uses gcloud auth login --cred-file. All three providers now offer CLI commands specifically for testing federated identity outside CI, which should be your first troubleshooting step before modifying pipeline configurations.

Common anti-patterns to avoid

Do not use wildcard conditions (StringLike: *) in trust policies unless intentionally creating a broad development sandbox. Production trust policies should pin to specific repositories, environments, and ideally branches. Do not reuse the same federated role across unrelated workflows; create separate roles with minimal permissions. Do not disable OIDC verification to "fix" authentication — this defeats the entire security model. If verification fails, fix the configuration, don't bypass it.

When should you migrate existing pipelines to keyless authentication?

Migrate immediately for any pipeline handling production deployments, database migrations, or infrastructure changes. The effort is typically 2–4 hours per cloud provider per repository, and the security payoff eliminates an entire class of supply chain attack vectors. For legacy systems where CI platforms lack native OIDC support, consider intermediate solutions like HashiCorp Vault's dynamic secrets or cloud-specific workload identity bridges until native support arrives.

Prioritize migration based on credential exposure surface: shared CI runners, open-source repositories with external contributors, and multi-tenant CI environments carry highest risk. Internal-only monorepos on dedicated self-hosted runners present lower immediate risk but should still migrate to maintain compliance posture and reduce operational overhead from key rotation schedules.

Securing Your Pipeline Future

Adopting workload identity federation without long-lived keys is no longer optional for teams serious about supply chain security and compliance readiness. The initial configuration investment pays immediate dividends: eliminated secret rotation toil, granular audit trails tied to specific commits, and removal of an entire attack surface that adversaries actively exploit. Start with your highest-risk production pipelines, validate thoroughly using manual STS calls before cutting over, and maintain observability on federation events through your existing monitoring stack. If your team needs assistance designing or implementing keyless authentication across multi-cloud environments, reach out to discuss your specific architecture.