HCP Terraform: Teams, Policies, Health, Explorer & Dynamic Credentials

Beyond Workspaces — The Platform Features

Workspaces, runs, variables — that’s the operational layer. But running Terraform at scale isn’t just about execution. It’s about governance: who can do what, what policies are enforced before changes land, how do you know if infrastructure has drifted, and how do you stop long-lived credentials from becoming a security liability.

This is the enterprise layer. The stuff that makes auditors happy and security teams less twitchy.

Teams & Permissions — RBAC in HCP Terraform

HCP Terraform has role-based access control built around teams.

Every org starts with one team: owners — full admin access to everything.

From there, you create teams that map to your org structure:

• networking — access to networking workspaces
• app-team — read access to compute workspaces
• security — read-only across all workspaces

Permission levels per workspace:

The “Plan only” permission is underused and underappreciated. I’ve set this up for junior engineers — they can queue plans and see what would happen, but can’t actually apply. Great for learning without risk.

Organizations and Projects

Organization — the top-level container. Your company has one (or a few). All workspaces, teams, and policies live inside it.

Projects (HCP Terraform Plus and above) — group related workspaces within an org. The payments project contains all payment-system workspaces. The platform project contains networking workspaces.

Projects enable scoped team access — the payments team gets access to the payments project, not every workspace in the organization. This matters when you have 50+ workspaces and you don’t want the database team accidentally browsing compute state that has nothing to do with them.

Policy Enforcement: Sentinel and OPA

This is where HCP Terraform earns its keep. Policy-as-code frameworks that run between terraform plan and terraform apply. If a policy fails, the apply is blocked. No human in the loop needed to catch the violation.

Sentinel (HashiCorp’s own policy language):

# sentinel policy: no-public-s3-buckets.sentinel
import "tfplan/v2" as tfplan

all_buckets = filter tfplan.resource_changes as _, rc {
    rc.type is "aws_s3_bucket" and
    rc.mode is "managed"
}

bucket_acl_not_public = rule {
    all all_buckets as _, b {
        b.change.after.acl is not "public-read" and
        b.change.after.acl is not "public-read-write"
    }
}

main = rule { bucket_acl_not_public }

OPA/Rego (Open Policy Agent — the industry standard that isn’t vendor-locked):

# policy: instances-must-be-tagged.rego
package terraform

deny[msg] {
    r := input.resource_changes[_]
    r.type == "aws_instance"
    r.mode == "managed"
    not r.change.after.tags["CostCenter"]
    msg := sprintf("Instance %s is missing required 'CostCenter' tag", [r.address])
}

Enforcement levels — this is important:

I typically make security policies hard-mandatory (no public S3 buckets, no wildcard IAM permissions) and cost policies soft-mandatory (warning when estimated cost exceeds $X/month, but overridable for legitimate high-cost resources).

Note: Sentinel and OPA require HCP Terraform Plus tier or above. Free tier doesn’t include policy enforcement.

Workspace Health Assessments

HCP Terraform Plus workspaces can run health assessments on a schedule:

• Drift detection — compares current cloud infrastructure with Terraform state. Flags resources that someone modified outside Terraform.
• Continuous validation — runs check blocks from your config against live infrastructure.

Results surface in the workspace UI and can trigger Slack/email/PagerDuty notifications.

This turns Terraform from a “run it and forget it” tool into continuous monitoring. When someone tweaks a security group rule in the console at 3 AM during an incident, drift detection catches it the next morning before anyone forgets to clean it up.

HCP Terraform Explorer

Explorer (HCP Terraform Plus) gives you a birds-eye view across your entire org:

• Search all managed resources across every workspace
• Filter by resource type, workspace, tag, or drift status
• See at a glance which workspaces have drifted, are unhealthy, or have failed runs

When you’re managing 200 workspaces and thousands of resources, this is the control plane view that keeps you sane. Without it, you’re logging into each workspace individually trying to figure out if anything is broken. I’ve done that. It’s terrible.

Dynamic Credentials — The End of Static Secrets

This is the single most important security improvement in the HCP Terraform ecosystem. If you take one thing from this article, make it this.

The old way:

Developer creates AWS access key → stores in HCP variable set → key never expires → six months later it leaks in a log → manual rotation → everyone's day is ruined

The new way — Dynamic Credentials (OIDC workload identity):

1. HCP Terraform is registered as an OIDC identity provider with your cloud
2. When a run starts, HCP Terraform generates a short-lived JWT token
3. Your cloud (AWS, GCP, Azure) exchanges this for a temporary credential
4. The run executes with a credential that expires when the run completes
5. No static credentials stored anywhere. At all.

AWS Setup:

# Provider config — no access key, no secret key
provider "aws" {
  region = "us-east-1"
}

In HCP Terraform workspace environment variables:

TFC_AWS_PROVIDER_AUTH = true
TFC_AWS_RUN_ROLE_ARN  = arn:aws:iam::123456789:role/HCPTerraformRole

That’s it. When the run executes, HCP Terraform fetches a credential by assuming that IAM role via OIDC. The AWS provider picks it up transparently.

GCP Setup:

TFC_GCP_PROVIDER_AUTH      = true
TFC_GCP_SERVICE_ACCOUNT_EMAIL = [email protected]
TFC_GCP_WORKLOAD_PROVIDER_NAME = projects/.../providers/hcp-terraform

Why this matters in practice:

• No long-lived credentials to rotate, secure, or accidentally expose in logs
• The IAM role has exactly the permissions Terraform needs, no more
• Every run has a unique credential with a full audit trail
• Credential rotation as an operational concern simply ceases to exist

Setting up OIDC takes about 30 minutes. Once it’s done, you never think about Terraform credentials again. I’ve migrated three orgs from static keys to dynamic credentials. Every single one of them asked “why didn’t we do this sooner?”

The setup does require trust configuration on both sides — HCP Terraform as an OIDC provider in your cloud account, AND the workspace environment variables. Miss either side and the run falls back to looking for static credentials, which usually means a confusing auth failure.

Change Requests (Pre-Apply Gate)

HCP Terraform supports a pre-apply approval workflow:

1. Plan runs automatically
2. A designated team reviews the plan in the HCP UI (or via Slack integration)
3. They approve or reject
4. Only after approval does the apply execute

The “four eyes” principle: no single person both writes and applies a production change. Non-negotiable in finance, healthcare, and government. Good practice everywhere else.

Key Takeaways

Sentinel is HashiCorp-proprietary. OPA/Rego is an open standard used across the industry (Kubernetes admission controllers, API gateways, you name it). HCP Terraform supports both. If you’re already invested in OPA elsewhere, use Rego for consistency. If you’re starting fresh and staying in the HashiCorp ecosystem, Sentinel is fine.

Health assessments (drift detection) run in the background on a schedule. They’re separate from manually running terraform plan -refresh-only. You don’t trigger them — they just happen, and surface problems in the UI.

The HCP Terraform Feature Map