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 ConductorOne Support team if you’d like to try it out or share feedback.
id_tokens keyword. You exchange this token for a ConductorOne access token using a curl command in your pipeline.
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
bright-eagle-55012@yourcompany.conductor.one/wfe)
Add id_tokens to your job to request a GitLab OIDC token, then exchange it for a ConductorOne 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=bright-eagle-55012@yourcompany.conductor.one/wfe"
| jq -r '.access_token')
- >
curl -s "https://yourcompany.conductor.one/api/v1/apps"
-H "Authorization: Bearer $C1_ACCESS_TOKEN"
id_tokens block tells GitLab to generate a signed JWT with your ConductorOne 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.
