terraform v1.0.0

The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.

Reference

secret-ref-terraform-api-token

Custody

customer_vault

Injection

header (Authorization)

An HCP Terraform API token for the customer's own organization, held in the client's own secret manager. The stored material must be the complete Authorization header value: the scheme 'Bearer', one separating space, then the token — 'Bearer <token>'. Issuance is external and three token types exist per the retrieved API overview: user tokens (each user can have any number, created on the user's account settings page), team tokens (one per team, created in the team's settings, intended for plans and applies via CI/CD) and organization tokens (one per organization, intended for automating team and workspace management — and per the same reference, organization tokens CANNOT perform plans and applies). This pack's run capabilities require a user or team token; prefer a team token on a dedicated least-privilege team so the credential is not a person's identity. Least privilege: place that team on only the workspaces the deployment binds, with Read permission for the collection reads, and Apply runs / Admin permissions only where the run and workspace-write capabilities are enabled. Expiry and revocation: the retrieved API overview (re-fetched this session) confirms the token types but documents no configurable expiration for them, and this review could not substantiate a categorical no-expiry claim — treat these tokens as long-lived until revoked and confirm current expiration behavior against HashiCorp's token-management documentation at install; revocation is explicit — regenerating or deleting the team or organization token in settings, or deleting the individual user token — and because team and organization tokens are one-at-a-time, regeneration replaces the old value. Disabling issuance does NOT invalidate already-issued tokens: removing a team's or user's permission to create tokens leaves tokens already minted valid, so each issued token must be regenerated or deleted individually; a deleted value fails closed with a 401. Rotation therefore sits with an external deployment process: the executor injects the stored value verbatim and performs no token lifecycle of its own. A fourth token type, the audit trails token, reads only the organization's audit trails and cannot serve any capability in this pack. Executor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

• terraform-organization (api, internal): https://terraform-cloud.invalid/api/v2/organizations/ORG

The endpoint host 'terraform-cloud.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): substitute the customer's HCP Terraform host (app.terraform.io) or Terraform Enterprise hostname before enabling, in every endpoint, in the resource locator and in every egress allowlist entry. The allowlist matches exactly, so endpoints and allowlist must be substituted together, and substitution is a required deployment step. ORG, WORKSPACE_ID and RUN_ID in the endpoint paths are placeholders the deployment binds before enabling. Per the retrieved API overview the API is version 2 under the /api/v2 prefix and speaks JSON:API (Content-Type application/vnd.api+json), POST and PATCH endpoints take a JSON:API document as the request payload, and list endpoints paginate with page[number]/page[size] query parameters. The token type matters and this pack's notes say so plainly: per the retrieved overview, ORGANIZATION tokens cannot perform plans and applies, so the run create/apply/discard capabilities require a user or team token, and forbidden requests with a valid token return 404 rather than 403 — a capability that inexplicably 404s is a permissions finding, not an absence of the resource. Tiering rationale: run creation registers as create, deploy AND delete at the R3 floor, judged by effect — per the retrieved Runs reference a run performs a plan and apply, and the caller-controlled body can set auto-apply (apply without a further confirmation step), is-destroy=true (the plan destroys ALL provisioned resources in the workspace) and target/replace addresses — so an unrestricted body can both deploy infrastructure change and destroy the whole estate a workspace manages; deploy and delete are IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer) and an installer's intention to queue only plan-only runs is not a restriction. Applying a run registers as approve, deploy AND delete at the R3 floor: the apply action confirms a run paused for confirmation and queues the apply of the reviewed plan — it is precisely the approval moment — and the plan being applied may itself destroy managed resources, so delete is declared as well. Discarding a run registers as delete at the R3 floor: discard is terminal (the run reaches its discarded final state and later runs can proceed), and queuing a fresh run afterward is a new run, not a reversal of the discard. Workspace creation registers as create AND deploy at the R3 floor: per the retrieved Workspaces reference the unrestricted body can link a VCS repository with automatic run triggering, speculative plans and auto-apply, and those VCS-triggered executions run provider-side — they need not traverse terraform.run.create or terraform.run.apply or any other AAES capability. Workspace deletion registers as delete at the R3 floor: per the retrieved Workspaces reference, DELETE /workspaces/{id} FORCE-deletes the workspace WITHOUT first checking for managed resources — destroying nothing itself but orphaning real infrastructure whose management record is gone; the checking form (POST .../actions/safe-delete, which refuses while resources are managed) is deliberately not registered, so this pack's only workspace deletion is the force form and the description says so. Documented exclusions — this pack does not register: state versions and state version outputs (state routinely contains cleartext secrets, and hosted-state download URLs are themselves bearer-secret URLs per the retrieved overview), variable creation/update (writing variables injects configuration, including sensitive values, into future runs), configuration-version upload, run force-execute and force-cancel (per the retrieved Runs reference, force-cancel warns of potentially dangerous side effects including loss of in-flight state), policy check overrides, workspace lock/unlock/force-unlock, team and organization membership management, agent pools and agent tokens, SSH keys, organization tokens and audit-trails tokens, and every other HCP Terraform API — a documented exclusion, not an approximated capability.

Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)

• https://developer.hashicorp.com/terraform/cloud-docs/api-docs (retrieved 2026-09-21)
• https://developer.hashicorp.com/terraform/cloud-docs/api-docs/run (retrieved 2026-09-21)
• https://developer.hashicorp.com/terraform/cloud-docs/api-docs/workspaces (retrieved 2026-09-21)

A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.