Workload Identity Federation Config Generator

Workload Identity Federation (WIF) lets external workloads (GitHub Actions, GitLab CI, Kubernetes pods) authenticate to cloud providers by presenting a short-lived OIDC token instead of a long-lived secret key. With service account keys you download a JSON file containing private key material — it never expires, must be rotated manually, and is a high-value secret if leaked. With WIF, there are no secrets to store, rotate, or accidentally commit. The OIDC token (valid for minutes) is exchanged for a cloud access token (valid for ~1 hour) using Security Token Service — nothing long-lived ever leaves the cloud provider.

GitHub Actions has a built-in OIDC provider at https://token.actions.githubusercontent.com. When a workflow runs, it can request an ID token signed by GitHub that contains claims like the repository, branch, actor, and environment. Cloud providers can be configured to trust this OIDC provider: they verify the token's signature using GitHub's public keys, check the claims match expected values (e.g. the correct repo), and issue short-lived cloud credentials. You must add permissions: id-token: write to your workflow for the OIDC token request to succeed.

In GCP, a Workload Identity Pool is a container for external identity providers — think of it as a trust namespace. A Workload Identity Provider (inside the pool) represents a specific external OIDC or SAML provider, configured with its issuer URL and attribute mappings. The attribute mapping translates claims from the external token (e.g. assertion.repository from GitHub) into Google attributes (e.g. attribute.repository). You then bind GCP service account roles to principals from the pool using principalSet:// (for attribute conditions) or principal:// (for exact subjects). The pool and provider IDs appear in the audience URL embedded in the credential config file.

For GCP, use attribute conditions on the provider with --attribute-condition (e.g. assertion.ref=='refs/heads/main' && assertion.repository=='owner/repo') and use principalSet with attribute.repository to bind IAM roles only to the specific repo. For AWS, add conditions in the IAM trust policy: token.actions.githubusercontent.com:sub with value repo:owner/repo:ref:refs/heads/main restricts access to that exact repo and branch. For Azure, the federated credential subject field (repo:owner/repo:ref:refs/heads/main) determines which identity is trusted. Always restrict to the narrowest possible subject — avoid wildcards like repo:owner/*.

Keyless authentication means no static credentials — no passwords, API keys, or private key files. It is significantly more secure for several reasons: no secrets to accidentally commit to source control, no secrets to expire or require rotation, automatic expiry of all issued tokens (minutes to 1 hour), and full audit trail in cloud provider logs showing exactly which workload made which request. The attack surface is also much narrower: an attacker would need to forge a GitHub/OIDC token signed by the identity provider's private key (effectively impossible) rather than just find a leaked JSON key file in a public repository.

Yes. GitLab CI supports OIDC tokens via the id_tokens keyword (CI/CD pipelines) — configure the provider with https://gitlab.com as the issuer. Kubernetes service accounts can use OIDC with clusters that expose an OIDC discovery endpoint (EKS, GKE with workload identity, and any cluster with --service-account-issuer). Terraform Cloud provides OIDC tokens for runs, enabling dynamic provider credentials with no static secrets. The key requirement for any source is a publicly accessible OIDC discovery endpoint (/.well-known/openid-configuration) so the cloud provider can fetch the signing keys to verify tokens.