Make devops-security runnable against a contributor's own AWS account

[ale210]

Overview

We need to make this Terraform runnable against a contributor's own AWS account, because that is how we ask people to test changes here. Today it only works against the Hack for LA account: the import blocks and the CloudTrail resources both name account 035866691871.

Action Items

• Delete terraform/imports.tf and remove the import blocks from aws-custom-policies-legacy.tf, aws-groups-legacy.tf and aws-users-legacy.tf (18 blocks in total). Keep the resource blocks. All 18 targets are already in state, so in the Hack for LA account these blocks do nothing. In any other account they make Terraform try to import resources that don't exist.
• Add a root variable iam_only (bool, default true) and set count = var.iam_only ? 0 : 1 on all 11 resources in cloudtrail.tf. Update any reference between them to use [0]. These are the only resources in the repo that aren't IAM, and their bucket names are global and already taken, so they can't be created in another account.
  • No moved blocks are needed. Terraform treats an existing object as instance [0] when count is added to it.
• Add lifecycle { prevent_destroy = true } to both aws_cloudtrail resources and both aws_s3_bucket resources. This is required, not optional. Because the default is true, any run against the Hack for LA account that forgets to set iam_only = false would plan to destroy both audit trails. This includes a local terraform plan by a lead. With prevent_destroy, that plan errors instead.
• In both .github/workflows/terraform-plan.yaml and .github/workflows/terraform-apply.yaml, add variables: iam_only = false to the dflook step's with: block.
• In aws-groups.tf, replace the hardcoded arn:aws:iam::035866691871:policy/ManageAccessKeys on aws_iam_group_policy_attachment.manageAccessKeys with aws_iam_policy.manage_access_keys.arn. It is the same ARN in our account, so the plan should not change, but in any other account the hardcoded one fails.
• Document for contributors that a test run needs no iam_only setting, and what it will create in their account. That includes every declared IAM user, the ops-leads group with AdministratorAccess, and the GitHub Actions OIDC provider, which fails with EntityAlreadyExists if their account already has one. Also document that anyone running against the Hack for LA account must pass -var iam_only=false.
• Before merging, confirm the PR's CI plan reads 0 to add, 0 to change, 0 to destroy. That is the evidence the Hack for LA account is untouched.
• After the PR merges, confirm the Terraform apply (OIDC) run on main succeeds with no changes, and that both trails still exist: aws cloudtrail describe-trails --region us-west-2.

Resources/Instructions

• Files: terraform/imports.tf, terraform/cloudtrail.tf, terraform/aws-groups.tf (the ARN was at line 25 when written; line numbers may drift, so search for 035866691871), the three terraform/*-legacy.tf files, and both workflow files above.
• How the imports got here: Created resources and import statements to import ops-leads #157, Bring the remaining IAM users under Terraform #180, Import the two CloudTrail trails and their log buckets #193.
• dflook/terraform-plan variables input: https://github.com/dflook/terraform-github-actions/tree/main/terraform-plan#variables
• Terraform prevent_destroy: https://developer.hashicorp.com/terraform/language/meta-arguments/lifecycle#prevent_destroy