feat(groq): A whimsical Terraform module that generates a secure random password for post‑apocalyptic secret keeping.

[polsala]

Implementation Summary

• Utility: nightly-post-apoc-secret-vault
• Provider: groq
• Location: terraform-modules/nightly-nightly-post-apoc-secret-vau
• Files Created: 5
• Description: A whimsical Terraform module that generates a secure random password for post‑apocalyptic secret keeping.

Rationale

• Automated proposal from the Groq generator delivering a fresh community utility.
• This utility was generated using the groq AI provider.

Why safe to merge

• Utility is isolated to terraform-modules/nightly-nightly-post-apoc-secret-vau.
• README + tests ship together (see folder contents).
• No secrets or credentials touched.
• All changes are additive and self-contained.

Test Plan

• Follow the instructions in the generated README at terraform-modules/nightly-nightly-post-apoc-secret-vau/README.md
• Run tests located in terraform-modules/nightly-nightly-post-apoc-secret-vau/tests/

Links

• Generated docs and examples committed alongside this change.

Mock Justification

• Not applicable; generator did not introduce new mocks.

[polsala]

🤖 Review by GROQ Agent

✅ What's solid

• Self‑contained module – All required resources live in a single directory; no external data sources or backends are referenced.
• Provider pinning – random provider is required with a version constraint (~> 3.5), which protects against breaking changes.
• Sensitive output – The password is marked sensitive = true, preventing it from being displayed in normal Terraform output.
• Clear variable defaults – Reasonable defaults (length = 16, special = true, a well‑chosen override_special set) make the module usable out‑of‑the‑box.
• Simple test script – The Bash test isolates Terraform work in a temporary directory, runs init, validate, and apply, and checks the default password length.

🧪 Tests

Observation	Recommendation
The script only validates the default password length (16).	Add tests for custom variable values, e.g. length = 24, special = false, and a custom override_special. This ensures the module respects user input.
The test uses terraform apply -auto-approve which actually creates a resource (the random password).	Switch to terraform plan -out=plan.out and then terraform show -json plan.out to extract the planned password without persisting state. This speeds up CI and avoids leftover state files.
No assertion on the sensitivity of the output.	After terraform output -json password, verify that the value is not printed to stdout in plain text (e.g., run the command with TF_LOG=ERROR and ensure no password appears).
The script silently discards all Terraform CLI output (> /dev/null).	Capture and display terraform validate and terraform plan errors on failure to aid debugging. Example: `terraform validate
No CI‑friendly exit codes for multiple assertions.	Consider using a testing framework like Terratest (Go) or kitchen‑terraform (Ruby) for richer assertions and reporting.
The test script lives under tests/ but the README points to cd test.	Align the path in the README (cd tests && ./test_module.sh) to avoid confusion.

Sample extended test snippet (Bash)

# Test custom length and special flag
cat > terraform.tfvars <<EOF
length  = 24
special = false
EOF

terraform apply -auto-approve -input=false -no-color > /dev/null
PASS=$(terraform output -json password | tr -d '"')
if [ "${#PASS}" -ne 24 ]; then
  echo "❌ custom length test failed"
  exit 1
fi
if [[ "$PASS" =~ [^a-zA-Z0-9] ]]; then
  echo "❌ special characters should be absent"
  exit 1
fi
echo "✅ custom length & special flag passed"

🔒 Security

• No secret leakage – The module does not embed any credentials, and the output is marked sensitive.
• Potential CI exposure – The test script captures the password into a shell variable (PASS). If the CI system logs environment variables or command output, the password could be exposed.
  • Fix: Avoid storing the password in a plain variable; pipe directly to validation logic, or unset the variable after use: unset PASS.
• Provider version – Pinning to ~> 3.5 is good, but consider also pinning the Terraform version (required_version = ">= 1.5, < 2.0"), preventing accidental use of an older Terraform that may have weaker random generation.
• Randomness source – The random_password resource uses the default OS RNG, which is cryptographically secure on modern platforms. No further action needed.

🧩 Docs/DX

• README clarity
  • The usage block points to source = "./modules/nightly-post-apoc-secret-vault" while the actual path in the repo is terraform-modules/nightly-nightly-post-apoc-secret-vau. Align the example with the real path or provide a generic source = "git::https://...#nightly-post-apoc-secret-vault" snippet.
  • Add a Prerequisites section (Terraform version, required providers).
  • Mention that the module outputs a sensitive value and suggest using terraform output -json or referencing it in other modules without printing.
• Typo in directory name – The folder ends with vau instead of vault. Consider renaming to avoid confusion (nightly-post-apoc-secret-vault).
• Testing instructions – Update the command to cd tests && ./test_module.sh (matches the actual directory).
• Example with overrides – Show how to customize override_special for stricter policies.

Suggested README addition

### Prerequisites
- Terraform >= 1.5
- Random provider `hashicorp/random` (pinned to ~> 3.5)

### Example with custom characters
module "secret_vault" {
  source = "git::https://github.com/yourorg/terraform-modules.git//nightly-post-apoc-secret-vault?ref=v1.0.0"

  length          = 32
  special         = true
  override_special = "!@#%^&*"
}

🧱 Mocks/Fakes

• The test script already avoids external dependencies by copying the module into a temporary directory. This is a solid approach for a pure Terraform module.
• No external data sources or APIs are used, so no mocks are required.
• If future enhancements add data sources (e.g., fetching a secret from a vault), consider introducing local mock providers or using the terraform-provider-mock to keep tests deterministic.

---

Overall, the module is functional, well‑structured, and includes a basic test harness. Strengthening the test coverage, tightening CI‑side secret handling, and polishing the documentation (especially the path typo) will make the contribution more robust and developer‑friendly.

[polsala]

🤖 Review by GEMINI Agent

✅ What's solid

• Sensitive Output Handling: The sensitive = true flag is correctly applied to the password output, preventing its accidental exposure in Terraform plan/apply outputs.
• Provider Version Pinning: The random provider is explicitly pinned with a version constraint (~> 3.5), which enhances stability and protects against unexpected breaking changes from future provider updates.
• Clear Variable Definitions: All input variables (length, special, override_special) include clear descriptions, types, and sensible default values, improving module usability.

🧪 Tests

• Expand Test Coverage: The current test script primarily validates the default password length. Extend the test suite to include scenarios where special is set to false, override_special is used, and custom length values are provided. This ensures the module behaves as expected under various configurations.

  # Example: Test with custom length and no special characters
  terraform apply -auto-approve -input=false -no-color -var="length=10" -var="special=false" > /dev/null
  PASS_NO_SPECIAL=$(terraform output -json password | tr -d '"')
  if [ "${#PASS_NO_SPECIAL}" -ne 10 ]; then
    echo "Test failed: expected password length 10, got ${#PASS_NO_SPECIAL}"
    exit 1
  fi
  # Add regex check to ensure no special characters are present
  if [[ "$PASS_NO_SPECIAL" =~ [!@#$%&*()-_=+\[\]{}<>?] ]]; then
    echo "Test failed: special characters found when 'special' was false"
    exit 1
  fi

• Correct README Test Instructions: The README.md instructs users to cd test and then ./test_module.sh. The actual test script is located in tests/test_module.sh. Update the README.md to reflect the correct path, e.g., cd tests or provide a direct execution command from the module's root.

🔒 Security

• Input Validation for Length: Consider adding a validation block to the length variable in variables.tf to enforce a minimum password length (e.g., 8 or 12 characters). This helps guide users towards stronger password choices, even if they override the default.

  variable "length" {
    description = "Length of the generated password"
    type        = number
    default     = 16
    validation {
      condition     = var.length >= 8
      error_message = "The password length must be at least 8 characters."
    }
  }

• Override Special Character Set: While override_special offers flexibility, it also allows users to define a potentially weak set of special characters. If the module's primary goal is maximum security, consider adding a note in the README.md advising users on best practices for defining a strong override_special set, or implement validation to ensure a minimum diversity of character types if feasible.

🧩 Docs/DX

• Module Naming Consistency: There are inconsistencies in the module's name and path across the PR title, body, README.md, and the actual directory structure.
  • The PR body lists the utility as nightly-post-apoc-secret-vault but the location as terraform-modules/nightly-nightly-post-apoc-secret-vau.
  • The README.md title is "Nightly Post‑Apoc Secret Vault".
  • The README.md usage example uses source = "./modules/nightly-post-apoc-secret-vault".
  • The actual directory is terraform-modules/nightly-nightly-post-apoc-secret-vau.
    Standardize the module name and ensure all references (directory, README.md title, usage examples) are consistent.
• Correct README Usage Example: Update the source path in the README.md usage example to accurately reflect the module's location within the repository. For instance, if the module is consumed from the repository root, it should be source = "./terraform-modules/nightly-nightly-post-apoc-secret-vau".

🧱 Mocks/Fakes

• Document Test Isolation: The test script's use of mktemp -d to create a temporary directory and terraform init -backend=false effectively isolates the test environment. This is a robust approach to ensure tests are self-contained and do not interfere with existing Terraform states or require external dependencies. Consider adding a brief note in the README.md or test script comments to highlight this effective isolation strategy.