A team runs terraform plan and apply directly in GitHub Actions with an S3 backend, not through HCP Terraform. Long-lived AWS access keys are stored as repository secrets, and security wants them removed. What is the recommended replacement?
Select an answer to reveal the explanation.
Short Explanation
The same no-keys idea works outside HCP Terraform, you just use your CI's own ID badge. GitHub Actions can mint an OIDC token per job, and AWS trades it for a short-lived role session. Don't grab the TFC_ variables here; they only mean something inside HCP Terraform runs.
Full Explanation
CI systems that issue OIDC tokens can authenticate to clouds without stored keys. In GitHub Actions the job requests a signed token, which needs the id-token write permission, and AWS trusts GitHub's OIDC provider through an IAM identity provider and a role whose trust policy checks the token's audience and subject, such as the repository and branch or environment. The job assumes the role and receives temporary credentials that Terraform's AWS provider and the S3 backend read from the environment. The TFC_AWS_ variables are interpreted only by HCP Terraform and Terraform Enterprise runs; a GitHub workflow that sets them gets no credentials. Moving the keys into Vault but authenticating with a stored Vault token just replaces one long-lived secret with another. Ephemeral variables keep values out of plan and state files, yet the credentials themselves remain permanent access keys stored as repository secrets, which is the finding. Exam caveat: scope the role's trust to the specific repository and branch or environment, or any workflow on the provider could assume it. Operational check: delete the access-key secrets, run the workflow, and confirm CloudTrail shows AssumeRoleWithWebIdentity from the GitHub OIDC provider for the expected subject.