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.
HCP Terraform (formerly Terraform Cloud) can issue workload identity tokens for each run. The ConductorOne Terraform provider auto-detects these tokens, so your runs authenticate without stored secrets.

Prerequisites

  • A service principal with an HCP Terraform federation trust. See set up federation if you haven’t created one yet. Use the HCP Terraform preset.
  • The trust’s client ID (for example clever-fox@yourcompany.conductor.one/wfe)

Step 1: Configure workspace environment variables

In your HCP Terraform workspace, set this environment variable:
VariableValue
TFC_WORKLOAD_IDENTITY_AUDIENCEyourcompany.conductor.one (your ConductorOne tenant domain)
HCP Terraform automatically generates a TFC_WORKLOAD_IDENTITY_TOKEN environment variable for each run. This token is a signed JWT containing metadata about the Terraform run.

Step 2: Configure the provider

The ConductorOne Terraform provider auto-detects TFC_WORKLOAD_IDENTITY_TOKEN. You only need to provide the trust’s client ID:
provider "conductorone" {
  client_id = "clever-fox@yourcompany.conductor.one/wfe"
  # oidc_token is auto-detected from TFC_WORKLOAD_IDENTITY_TOKEN
}
That’s it. When terraform plan or terraform apply runs in HCP Terraform, the provider exchanges the workload identity token for a ConductorOne access token automatically.

Explicit configuration

If you prefer to be explicit, or if you need multiple audience values, use a Terraform variable:
variable "tfc_conductorone_token" {
  type      = string
  sensitive = true
  default   = ""
}

provider "conductorone" {
  oidc_token = var.tfc_conductorone_token
  client_id  = "clever-fox@yourcompany.conductor.one/wfe"
}
For multiple audiences, set TFC_WORKLOAD_IDENTITY_AUDIENCE_CONDUCTORONE in your workspace. HCP Terraform generates a corresponding TFC_WORKLOAD_IDENTITY_TOKEN_CONDUCTORONE variable.

Provider auth priority

The provider resolves authentication in this order:
  1. CONDUCTORONE_ACCESS_TOKEN environment variable (static bearer token)
  2. oidc_token attribute, then CONDUCTORONE_OIDC_TOKEN env var, then TFC_WORKLOAD_IDENTITY_TOKEN env var
  3. client_id + client_secret attributes or CONDUCTORONE_CLIENT_ID + CONDUCTORONE_CLIENT_SECRET env vars

CEL expression examples

When creating the federation trust, the CEL expression controls which HCP Terraform runs can authenticate.

Restrict to an organization and workspace

claims.terraform_organization == "acme" && claims.terraform_workspace_name == "infra-prod"

Restrict to apply phase only

claims.terraform_organization == "acme" && claims.terraform_workspace_name == "infra-prod" && claims.terraform_run_phase == "apply"

Common HCP Terraform OIDC claims

ClaimExample valueDescription
terraform_organizationacmeTerraform Cloud organization name
terraform_workspace_nameinfra-prodWorkspace name
terraform_workspace_idws-abc123Workspace ID
terraform_run_phaseapplyRun phase: plan or apply
terraform_run_idrun-xyz789Unique run ID
terraform_project_nameinfrastructureProject name

Security best practices for HCP Terraform

Restricting to “apply only” prevents plan-phase runs from obtaining credentials. This is the recommended default for workloads that modify infrastructure. If you need separate permissions for plan and apply, create two trusts with different scoped roles — one for plan (read-only) and one for apply (write).