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)
In your HCP Terraform workspace, set this environment variable:
| Variable | Value |
|---|
TFC_WORKLOAD_IDENTITY_AUDIENCE | yourcompany.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.
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:
CONDUCTORONE_ACCESS_TOKEN environment variable (static bearer token)
oidc_token attribute, then CONDUCTORONE_OIDC_TOKEN env var, then TFC_WORKLOAD_IDENTITY_TOKEN env var
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"
| Claim | Example value | Description |
|---|
terraform_organization | acme | Terraform Cloud organization name |
terraform_workspace_name | infra-prod | Workspace name |
terraform_workspace_id | ws-abc123 | Workspace ID |
terraform_run_phase | apply | Run phase: plan or apply |
terraform_run_id | run-xyz789 | Unique run ID |
terraform_project_name | infrastructure | Project name |
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).