I was reviewing a vendor's proposed "enterprise-grade" Terraform module for a new AWS service yesterday, and the assistant helping me insisted on a specific configuration pattern for the initial admin password. The prompt was straightforward:
"Generate a Terraform variable block for an initial admin password, following security best practices for enterprise deployments."
The assistant's output suggested defining a variable with a type constraint and a default value, which is correct in principle. However, the suggested default was a hardcoded string placeholder, `"ChangeMe123!"`. The assistant explicitly stated this was a common pattern for initial setup in enterprise-grade software, to be changed later.
This is a catastrophic failure of reasoning. The correct answer is that an initial administrative password should **never** be hardcoded, even as a placeholder default, in a reusable module claiming to be enterprise-grade. The enterprise-grade label implies built-in security posture, not technical debt.
The correct approach would involve:
* Defining a required variable with no default, forcing the user to provide a value at apply time via a secure method (e.g., from a secrets manager data source).
* Or, generating a random password using `random_password` and outputting it to a state backend (with appropriate warnings about state visibility).
* At the very least, marking the variable as `sensitive = true` (which the suggestion omitted).
The assistant conflated a common *bad practice* seen in quick-start guides with a legitimate "enterprise-grade" pattern. This is precisely the kind of subtle, dangerous advice that gets propagated because it sounds plausible. It would directly violate most organizational security policies.
Has anyone else encountered similar "best practice" hallucinations where the assistant confidently reinforces a blatantly insecure or inefficient pattern under the guise of enterprise conventions? Particularly in infrastructure-as-code or cloud configuration contexts.
Optimize or die.
CloudCostHawk
That default placeholder is just the visible symptom. The real problem is a design philosophy that treats the first deployment as disposable.
Enterprise-grade should mean the module enforces the right pattern from the first 'terraform plan'. If a default like that exists, it *will* get checked into a git repo somewhere by a tired engineer at 2 AM. Now you've baked a known password into your commit history.
Your point about a required variable is correct, but I'd push further. Even forcing a value at apply time can fail if the input method isn't specified. Without clear guidance, teams will just pass the var from a .tfvars file, which is another form of hardcoding. The module should document, or better yet, integrate with a specific secrets backend as the *only* accepted pattern.
Lisa M.
You're absolutely right about the hardcoded placeholder, but the core issue is that the module design stops at the variable declaration. A truly enterprise-grade module would dictate the **entire input chain**.
Simply making the variable required just shifts the problem. If the module's documentation, or even its variable description, doesn't explicitly forbid `.tfvars` files and mandate integration with something like AWS Secrets Manager or HashiCorp Vault via a data source, teams will inevitably take the path of least resistance. They'll store it in a `terraform.tfvars` file, which is just another hardcoded location.
The pattern should be enforced within the module itself. For example, the variable could be of type `object` requiring a `secret_manager_arn` attribute, and the module's local-exec or external data source would handle the retrieval. That eliminates the possibility of a plaintext value ever being handled in Terraform state or plan output.
Data > opinions