A GCP team using HCP Terraform stores a service account JSON key in a sensitive GOOGLE_CREDENTIALS variable. Security wants keyless authentication for every run, and only tokens from the company's own HCP Terraform organization may be accepted. Which configuration meets both requirements?
Select an answer to reveal the explanation.
Short Explanation
Keyless on GCP means workload identity federation: a pool and a provider that trust HCP Terraform's tokens. Here's the catch you can't skip: lock the provider down with an attribute condition on your organization, or every HCP Terraform customer's token looks just as valid as yours. Rotating a JSON key is still keeping a key.
Full Explanation
GCP dynamic provider credentials rely on workload identity federation. The team creates a workload identity pool and an OIDC provider whose issuer is the HCP Terraform address, maps the token's sub claim to google.subject, and adds an attribute condition such as one on assertion.sub that names the organization, and optionally the project and workspace. Permissions are granted to the pool principal directly or to a service account it impersonates. The workspace sets TFC_GCP_PROVIDER_AUTH to true, TFC_GCP_WORKLOAD_PROVIDER_NAME to the provider's full resource name and, when impersonating, TFC_GCP_RUN_SERVICE_ACCOUNT_EMAIL. Rotating a JSON key on a schedule keeps a downloadable long-lived credential and a job that must hold rights to mint keys, so it is not keyless. A provider with no attribute condition accepts tokens from every HCP Terraform organization, which HashiCorp explicitly warns against; at minimum the audience and organization must be checked. Application Default Credentials only find something when the process runs on GCP compute or has a key file present, and HCP Terraform's hosted runs offer neither. Exam caveat: pool and provider IDs cannot be changed after creation. Operational check: delete GOOGLE_CREDENTIALS, run a plan, and confirm the Cloud Audit Logs show a federated principal.