GitLab CI integration

Set up secretless authentication from GitLab CI to C1 using OIDC id_tokens.

GitLab CI/CD can issue OIDC tokens for each job via the id_tokens keyword. You exchange this token for a C1 access token using a curl command in your pipeline.

These examples use conductor.one. If your organization is on the EU data residency instance, substitute c1eu.ai in URLs, client IDs, and hostnames.

Prerequisites

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

Configure the pipeline

Add id_tokens to your job to request a GitLab OIDC token, then exchange it for a C1 access token:

# .gitlab-ci.yml
deploy:
  id_tokens:
    C1_TOKEN:
      aud: yourcompany.conductor.one
  script:
    - >
      C1_ACCESS_TOKEN=$(curl -s -X POST
      "https://yourcompany.conductor.one/auth/v1/token"
      -d "grant_type=urn:ietf:params:oauth:grant-type:token-exchange"
      -d "subject_token=$C1_TOKEN"
      -d "subject_token_type=urn:ietf:params:oauth:token-type:jwt"
      -d "client_id=[e-mail]/wfe"
      | jq -r '.access_token')
    - >
      curl -s "https://yourcompany.conductor.one/api/v1/apps"
      -H "Authorization: Bearer $C1_ACCESS_TOKEN"

The id_tokens block tells GitLab to generate a signed JWT with your C1 tenant domain as the audience. The token is available as the C1_TOKEN environment variable within the job.

CEL expression examples

When creating the federation trust, the CEL expression controls which GitLab CI jobs can authenticate.

Restrict to a project

claims.project_path == "acme/infra"

Restrict to a project on protected refs only

claims.project_path == "acme/infra" && claims.ref_protected == "true"

Restrict to a specific branch

claims.project_path == "acme/infra" && claims.ref == "main" && claims.ref_protected == "true"

Common GitLab OIDC claims

Claim	Example value	Description
project_path	acme/infra	Full project path including group
project_id	12345	Numeric project ID
namespace_path	acme	Group or user namespace
ref	main	Branch or tag name
ref_protected	true	Whether the ref is protected
ref_type	branch	branch or tag
pipeline_source	push	What triggered the pipeline
environment	production	Environment name (if used)
environment_protected	true	Whether the environment is protected

Security best practices for GitLab CI

Keep “Require protected ref” enabled (claims.ref_protected == "true") to ensure only jobs running on protected branches or tags can authenticate. For high-privilege access, also bind to a specific ref value. GitLab lets you set the audience per-job via id_tokens — your tenant domain is used as the expected audience.