Skip to main content
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.
Service principals are machine identities in ConductorOne. They give your scripts, CI/CD pipelines, and Terraform runs their own identity and credentials, separate from any human user.

What’s a service principal?

A service principal is a dedicated, non-human identity purpose-built for automation. It appears in the user directory alongside human users, but it’s designed for scripts, CI/CD pipelines, Terraform runs, and API integrations. Each service principal:
  • Has a display name and unique ID
  • Can be assigned ConductorOne roles, just like a human user
  • Has owners who manage it
  • Can have multiple credentials or federation trusts
You don’t need a service principal to use the ConductorOne API for personal use. You can use existing personal API credentials (Profile > API Keys) for individual tasks. Service principals are designed for shared automation where the identity should not be tied to a specific person.

Two ways to authenticate

Service principals support two authentication methods. You can use either one, or both on the same service principal.
Client credentialsWorkload federation
HowClient ID + secret sent to token endpointExternal OIDC (OpenID Connect) token exchanged for ConductorOne token
SecretsClient secret must be stored and rotatedNo secrets — uses your CI/CD platform’s built-in OIDC
Best forLocal development, scripts, cron jobs, Terraform (simple setup)GitHub Actions, GitLab CI, HCP Terraform, AWS (production)
Credential lifetimeMaximum 180 days; must be rotated before expiryNo credentials to manage; tokens are per-run
SecuritySecret can leak; mitigate with IP restrictions + expiration + scoped rolesNo secret to leak; token valid only for a single CI/CD run
Grant typeclient_credentialsurn:ietf:params:oauth:grant-type:token-exchange

Choosing the right method

  • Use client credentials if you want a straightforward path to calling the API. Best for scripts, local development, and environments where storing a secret is acceptable.
  • Use workload federation for production CI/CD. No secrets to rotate, tighter scoping, and tokens are tied to individual workflow runs.

Environment variables

All ConductorOne client tools (Go SDK, Terraform provider, Cone CLI, oidc-token-action) recognize the same environment variables:
VariablePurpose
CONDUCTORONE_CLIENT_IDClient ID for authentication (client credentials or workload federation trust)
CONDUCTORONE_CLIENT_SECRETEd25519 private key for client credentials
CONDUCTORONE_ACCESS_TOKENPre-exchanged bearer token (highest priority, skips all other auth)
CONDUCTORONE_OIDC_TOKENRaw OIDC JWT for workload federation token exchange
CONDUCTORONE_TENANT_DOMAINTenant domain override
CONDUCTORONE_SERVER_URLFull server URL override
When multiple variables are set, tools use this priority order:
  1. CONDUCTORONE_ACCESS_TOKEN — static bearer token, no exchange needed
  2. CONDUCTORONE_OIDC_TOKEN — token exchange using CONDUCTORONE_CLIENT_ID
  3. CONDUCTORONE_CLIENT_ID + CONDUCTORONE_CLIENT_SECRET — Ed25519 JWT assertion

Before you begin

Before creating service principals:
  1. Contact your ConductorOne account team to enable the feature (it’s gated behind a feature flag during early access)
  2. You need Super Admin permissions to create and manage service principals

Next steps

Service principal limits

LimitValue
Maximum credential lifetime180 days (rotation required)
CEL expression size1,024 bytes
IP address ranges per credential or trust32
Workload federation provider requirementPublicly accessible JWKS (JSON Web Key Set) endpoint
Credential expiration can’t be extended after creation. To continue access, create a new credential with the desired expiration and revoke the old one. See credential rotation.