> ## Documentation Index
> Fetch the complete documentation index at: https://conductorone-docs-ia-reframe-draft.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Workload federation

> Eliminate stored secrets by exchanging OIDC tokens from CI/CD platforms for C1 access tokens.

Workload federation eliminates stored secrets entirely. Your CI/CD platform's built-in OIDC (OpenID Connect) tokens are exchanged directly for C1 access tokens -- no client secrets to store, rotate, or risk leaking.

## How it works

Most CI/CD platforms (GitHub Actions, GitLab CI, HCP Terraform) can issue short-lived OIDC tokens that identify the running workload. Workload federation lets C1 trust these tokens directly:

1. Your CI/CD platform issues a signed JWT (JSON Web Token) for the current workflow run
2. Your workflow sends this JWT to C1's token exchange endpoint
3. C1 validates the token: issuer, signature, audience, freshness, and your conditions
4. C1 issues a short-lived access token scoped to the service principal's roles

The entire flow is secretless. No credentials are stored anywhere -- the OIDC token is only valid for a single CI/CD run, typically for a few minutes.

## Two building blocks

Workload federation has two layers:

### Providers

A **provider** represents an OIDC token issuer, for example GitHub Actions or HCP Terraform. Providers are created once at the tenant level and shared across service principals.

Each provider has:

* An **issuer URL** (for example `https://token.actions.githubusercontent.com` for GitHub Actions)
* A public JWKS (JSON Web Key Set) endpoint for signature verification

C1 includes presets for common platforms:

| Provider             | Issuer URL                                      | Notes                            |
| :------------------- | :---------------------------------------------- | :------------------------------- |
| **GitHub Actions**   | `https://token.actions.githubusercontent.com`   | Fixed issuer URL                 |
| **GitLab CI/CD**     | `https://gitlab.com` (or self-managed URL)      | Editable issuer URL              |
| **HCP Terraform**    | `https://app.terraform.io` (or custom hostname) | Editable issuer URL              |
| **AWS IAM Outbound** | Account-specific issuer URL                     | Editable issuer URL              |
| **Custom OIDC**      | Any HTTPS issuer URL                            | For other OIDC-capable platforms |

### Trusts

A **trust** binds a provider to a specific service principal with conditions. It controls which tokens from that provider are accepted and what permissions they receive.

Each trust has:

* A **client ID** (for example `swift-otter-19384@yourcompany.conductor.one/wfe`)
* A **CEL condition expression** that the JWT claims must satisfy
* **Optional** IP restrictions and scoped roles

The CEL (Common Expression Language) expression evaluates against the JWT's claims. For example, this expression restricts access to a specific GitHub repository and environment:

```go theme={"theme":{"light":"css-variables","dark":"css-variables"}}
claims.repository == "acme/infra" && claims.environment == "production"
```

## Supported platforms

<Columns cols={2}>
  <Card title="GitHub Actions" icon="github" href="/product/admin/service-principals/github-actions">
    Use the conductorone/oidc-token-action for one-step setup.
  </Card>

  <Card title="GitLab CI" icon="gitlab" href="/product/admin/service-principals/gitlab-ci">
    Use GitLab's built-in id\_tokens with a curl exchange.
  </Card>

  <Card title="HCP Terraform" icon="cloud" href="/product/admin/service-principals/hcp-terraform">
    Auto-detected from TFC\_WORKLOAD\_IDENTITY\_TOKEN.
  </Card>

  <Card title="AWS IAM" icon="aws" href="/product/admin/service-principals/aws-iam">
    Use IAM outbound identity federation from any AWS workload.
  </Card>

  <Card title="Custom OIDC" icon="shield-check" href="/product/admin/service-principals/custom-oidc">
    Any platform with OIDC support.
  </Card>
</Columns>

## Next steps

* [Set up federation](/product/admin/service-principals/federation-setup) -- step-by-step wizard walkthrough
* [Security controls](/product/admin/service-principals/security) -- scoped roles, IP restrictions, and CEL expressions

## Frequently asked questions about workload federation

<AccordionGroup>
  <Accordion title="What OIDC providers are supported?">
    Any OIDC-compliant provider that serves a `/.well-known/openid-configuration` document, has a public JWKS endpoint, and issues JWTs with standard claims (`iss`, `aud`, `exp`, `iat`). Built-in presets are available for GitHub Actions, GitLab CI/CD, HCP Terraform, and AWS IAM. Use "Custom OIDC" for any other provider.
  </Accordion>

  <Accordion title="Can I restrict which branches or environments can authenticate?">
    Yes. The CEL condition expression controls exactly which tokens are accepted. For GitHub Actions, restrict by `claims.repository`, `claims.ref`, and `claims.environment`. For GitLab, use `claims.project_path` and `claims.ref_protected`.
  </Accordion>

  <Accordion title="How do scoped roles work with federation trusts?">
    The trust's scoped roles are intersected with the service principal's assigned roles at token issuance time. For example, if the service principal has \[Super Admin, Basic User] and the trust has \[Basic User], the token's effective permissions are \[Basic User] only.
  </Accordion>
</AccordionGroup>