GitHub Actions integration

Set up secretless authentication from GitHub Actions to C1 using the oidc-token-action.

Early access. This feature is in early access, which means it’s undergoing ongoing testing and development while we gather feedback, validate functionality, and improve outputs. Contact the C1 Support team if you’d like to try it out or share feedback.

The conductorone/oidc-token-action GitHub Action exchanges a GitHub Actions OIDC token for a C1 access token in a single step. No secrets to store or rotate.

Prerequisites

• A service principal with a GitHub Actions federation trust. See set up federation if you haven’t created one yet.
• The trust’s client ID (for example [e-mail]/wfe)

Set up the workflow

Add the action to your workflow file. Your workflow must have id-token: write permission for GitHub to issue the OIDC token.

# .github/workflows/deploy.yml
name: Deploy with C1

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: conductorone/oidc-token-action@v1
        with:
          audience: yourcompany.conductor.one
          client_id: [e-mail]/wfe

      # CONDUCTORONE_ACCESS_TOKEN is now set for all subsequent steps

The action:

1. Requests a GitHub OIDC token with your tenant domain as the audience
2. Exchanges it for a C1 access token via token exchange
3. Exports CONDUCTORONE_ACCESS_TOKEN and CONDUCTORONE_CLIENT_ID as environment variables
4. Masks the token in logs to prevent accidental exposure
5. Cleans up the environment variables when the job finishes

Use with downstream tools

After the action runs, CONDUCTORONE_ACCESS_TOKEN is available to all subsequent steps. Every C1 tool recognizes this variable automatically.

Cone CLI

      - uses: conductorone/oidc-token-action@v1
        with:
          audience: yourcompany.conductor.one
          client_id: [e-mail]/wfe

      - run: cone whoami

Terraform

      - uses: conductorone/oidc-token-action@v1
        with:
          audience: yourcompany.conductor.one
          client_id: [e-mail]/wfe

      - uses: hashicorp/setup-terraform@v3
      - run: terraform apply

Direct API calls

      - uses: conductorone/oidc-token-action@v1
        with:
          audience: yourcompany.conductor.one
          client_id: [e-mail]/wfe

      - run: |
          curl -s "https://yourcompany.conductor.one/api/v1/apps" \
            -H "Authorization: Bearer $CONDUCTORONE_ACCESS_TOKEN"

CEL expression examples

When creating the federation trust, the CEL expression controls which GitHub Actions workflows can authenticate. The expression evaluates against the GitHub OIDC token’s claims.

Restrict to a repository

claims.repository == "acme/infra"

Restrict to a repository and branch

claims.repository == "acme/infra" && claims.ref == "refs/heads/main"

Restrict to a repository and environment

claims.repository == "acme/infra" && claims.environment == "production"

Common GitHub OIDC claims

Claim	Example value	Description
repository	acme/infra	Owner and repository name
repository_owner	acme	Repository owner (organization or user)
ref	refs/heads/main	Git ref that triggered the workflow
environment	production	GitHub Environment name (if used)
job_workflow_ref	acme/infra/.github/workflows/deploy.yml@refs/heads/main	Full workflow file reference
actor	octocat	GitHub user who triggered the run
event_name	push	Event that triggered the workflow

Security best practices for GitHub Actions

For production workloads, enable GitHub Environments and add an environment constraint to your CEL expression. This prevents any branch or workflow in the repo from authenticating — only jobs running in the specified environment can.

For maximum security, pin to a specific reusable workflow via job_workflow_ref:

claims.job_workflow_ref == "acme/infra/.github/workflows/deploy.yml@refs/heads/main"

This ensures only a specific workflow file on a specific branch can authenticate, even if other workflows in the same repo have id-token: write permission.