Repository navigation
Pin the AWS provider version and commit the lock file #181
Copy link
Copy link
Closed
Labels
complexity: smallfeature: maintenancerole: DevOps Engineersize: 1ptCan be done in 4-6 hoursCan be done in 4-6 hours
Milestone
Description
Overview
We need the AWS provider version pinned and .terraform.lock.hcl committed, because this repository declares no required_providers block at all and ignores the lock file, so every CI run installs whatever the newest AWS provider happens to be that day. Since this repository manages IAM — users, groups, policies and the OIDC providers other repositories authenticate through — an unreviewed provider upgrade lands on the account's access control.
Action Items
- Confirm the current state before changing anything. There is no
required_providersblock anywhere interraform/*.tf, so nothing constrainshashicorp/aws, and.gitignoreignores the lock file (line 25,*.terraform.lock.hcl; accurate 2026-08-30, find it by searching the file forlock.hclif the line has moved). Confirmgit ls-files terraform/.terraform.lock.hclreturns nothing. - Add a
required_providersblock toterraform/backend.tf, inside the existingterraform { }block next torequired_version, pinninghashicorp/awswith a constraint that fixes major and minor —~> 6.62.0against the latest on 2026-08-30. A two-part constraint like~> 6.62allows every 6.x and would not fix this. Pin to the same version as hackforla/incubator so the two repositories cannot diverge against the same AWS account. - Stop ignoring the lock file: remove the
*.terraform.lock.hclline from.gitignore, leaving the.terraform/directory entries alone. - Regenerate and commit the lock file with
terraform providers lock -platform=linux_amd64 -platform=windows_amd64. Both platforms are required — CI runs onubuntu-latestwhile local work is on Windows, and a lock file generated on one platform alone can fail to verify on the other. - Run
terraform planand confirm it still reports "No changes. Your infrastructure matches the configuration." — which is what it reported on 2026-08-30, so any change appearing after the pin is caused by the pin and must be understood before merging rather than applied. - After the PR merges, open the next plan run and confirm the log installs the pinned version rather than resolving a fresh one. This cannot be checked from the branch, because the point of the change is what CI does on a later run.
Resources/Instructions
terraform/backend.tf— has theterraform { }block withrequired_versionbut norequired_providers; that is where the new block goes..gitignore— the line to remove..github/workflows/terraform-plan.yamlandterraform-apply.yaml— note these authenticate as the IAM userdevops-iam-github-actionwith static access keys rather than OIDC, unlike incubator.- Found while deleting the Terragrunt state backend in Clean up the Terraform state backend incubator#170; unrelated to that work beyond having surfaced there.
- Pin the AWS provider version and commit the lock file incubator#192 is the identical defect in that repository. Fix both the same way, and pin both to the same version.
- A previous investigation blamed
dflook/terraform-plan@v1for ignoring a committed lock file. That was wrong — there is no committed lock file to ignore..gitignoreline 25 was added 2025-01-22 in4ff338b, andterraform/.terraform.lock.hclplusterraform/modules/aws-users/.terraform.lock.hclwere deleted from tracking on 2025-05-14 inf4f3364. The6.8.0pin cited at the time was an untracked local file on one machine. dflook installing the latest provider is correct behaviour for a repository with no lock file, so the fix is to give it one rather than to change the action. - Whether dflook honours a lock file once one is committed is genuinely untested. That is what the post-merge action item above checks, and it is the item that decides whether this ticket actually solved the problem.
- Provider versions were read on 2026-08-30 and will drift.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
complexity: smallfeature: maintenancerole: DevOps Engineersize: 1ptCan be done in 4-6 hoursCan be done in 4-6 hours
Type
Projects
- StatusShow more project fieldsDone
Activity
Pin the AWS provider to ~> 6.64.0 and commit the lock file (#219)
ale210 commentedon Sep 10, 2026
Delivered in #192. Five of the six action items are ticked; the post-merge one is left open, with a correction to it below.
Pinned to
~> 6.64.0, not the~> 6.62.0this issue names. 6.62.0 was the latest release on 2026-08-30; 6.64.0 is the latest now. The most recent apply run here installed 6.63.0 and the most recent apply on hackforla/incubator installed 6.64.0. Since this issue asks for both repositories to be pinned to the same version so they cannot diverge against account 035866691871, 6.64.0 is the right choice — it is the higher of the two, so neither state ends up written by a provider newer than its own pin. hackforla/incubator#192 pins to the same version in the same pass.The plan run on the PR is clean:
No changes. Your infrastructure matches the configuration., exactly as the fifth action item asks, with the provider installed at v6.64.0.The post-merge item is already answered for the plan path, and its stated justification is wrong. It says the check "cannot be checked from the branch, because the point of the change is what CI does on a later run." That premise does not hold: the plan job checks out the PR branch, which already contains the committed lock file, and its log opens with
This also settles the open question in the Resources section — "Whether dflook honours a lock file once one is committed is genuinely untested". It does, on the plan path, and it was observable a good deal earlier than this issue expected. I have left the box unticked because what remains genuinely untested is the apply path on
main, which is the narrower thing worth confirming after merge.One note not in scope of this issue:
tlsis now pinned by the lock file at 4.4.0. Nothing constrains it and it gets norequired_providersentry; with no lock file CI was already installing the latesttlson every run, so this records current behaviour rather than changing it.ale210 commentedon Sep 10, 2026
Separately, one line in the Resources section is now stale and worth correcting so it does not mislead a future reader:
That was true when this issue was written on 2026-08-30, but is not true now. Both workflows use
aws-actions/configure-aws-credentials@v4withrole-to-assume: arn:aws:iam::035866691871:role/devops-security-tf-plan(and the matching-tf-applyrole), and the IAM userdevops-iam-github-actionalong with its access key was deleted on 2026-09-06. That work was #182, delivered in #188.Nothing about this changes the fix — the note is context rather than an action item, and the provider-pinning work is unaffected by which credentials the workflow uses. Flagging it rather than editing the body, since the body is the record of what was true when the issue was refined.