Terraform Cloud|Enterprise static|read only variable set

[Esity]

Terraform Version

Terraform v1.4.6
on darwin_arm64

Use Cases

As we scale out Terraform with Cloud/Enterprise, we need the ability to statically set variables for certain orgs/projects that are read only and cannot be overridden at any level. This would make this the highest precedence level which is not something currently supported.

It also needs to be set up in a way that it requires the org owner to set and the project/workspace admins can't override it

Docs explaining current pattern https://developer.hashicorp.com/terraform/enterprise/workspaces/variables#precedence

Attempted Solutions

There is no solution for this currently as the variables can be overridden by the users

Proposal

Add another precedence level variable set that cannot be overridden

References

No response

[crw]

Hi @Esity, thanks for this request! As it relates to aspects of the commercial product, I would recommend that you also direct your inquiries to tf-cloud@hashicorp.support or open a new request.

In this case, I believe this is relevant to the core open source Terraform product and as such will leave this issue open (in fact, I believe this is a duplicate, but do not know the primary ticket off-hand).

Thanks again for this feedback!

[apparentlymart]

Hi @Esity! Thanks for sharing this use-case.

To help explore the problem space, let's consider a hypothetical edge-case to see what behavior you'd prefer for that situation.

Consider that you currently have a Terraform workspace whose root module contains the following:

variable "example" {
  type = string
}

output "result" {
  value = var.example
}

And let's also assume that the feature you described already exists and you have a non-overridable rule that this variable is always set to "hello". This (presumably) means that it would not be possible to:

• Set this variable in the workspace settings.
• Set this variable in a .tfvars file.

The above would therefore always generate the result "hello", regardless of how the workspace itself is configured or what .tfvars files are present. (If this isn't actually what you intended in your description, please let me know!)

---

Given that starting point, imagine now that someone who controls the source code of the root module of this workspace changes it as follows:

variable "example" {
  type = string
}

output "result" {
  value = "howdy!"
}

Notice that this module is now not using var.example at all, and therefore it's irrelevant what it was set to at the organization/project level. The result is now "howdy!", despite the attempt to set it to "hello" via a top-down setting.

Does that outcome match what you'd expect? Or would you want to impose some sort of additional constraint to make sure that this variable is actually used in a specific way?

Thanks!