Terraform provides more flexible controls with project-owned variable sets
Project-owned variable sets simplify management, reduce dependencies, and allow for more flexible control over access and usage.
HCP Terraform and Terraform Enterprise variable sets play a critical role in ensuring consistency and simplifying configuration management by allowing users to define variables once and reuse them across multiple workspaces. Until now, however, variable sets could only be managed at the organization level or the workspace level.
With the growing adoption of projects as a means to create a middle layer with clearer separation between teams and environments, we recognized the need for a more flexible and secure way to manage variables within these boundaries. We are excited to introduce project-owned variable sets, which address these challenges by enabling variable sets to be owned at the project level. Custom permissions can also be set, allowing users to have no permission, read-only permission, or manage permission for project-owned variable sets.
This provides the same functionality as organization-owned variable sets but without requiring high-level organization permissions. With this new feature, teams gain full self-service control over their variable sets, simplifying management, reducing dependencies, and allowing for more flexible control over access and usage.
In this blog post, we’ll explore the challenges this feature solves, the benefits it offers, and how it can help streamline the management of variables within HCP Terraform and Terraform Enterprise.
» What challenges do project-owned variable sets solve?
Projects enable teams to group workspaces, define granular permissions, and manage infrastructure efficiently with minimal admin intervention required. By centralizing control, reducing risk, and offering self-service capabilities, projects streamline workflows while maintaining security and organizational boundaries. However, until now, managing variable sets within the context of a specific project and with project-level permission was not possible.
Previously, in order to grant teams the ability to modify and use variable sets, platform teams had to add users to the organization owners team or a team with the “manage all workspaces” permission. This made it impossible for platform teams to give a set of users the ability to create and update variable sets without also giving these users broad organization wide permissions. This lack of granular control over variable set permissions posed a significant security and operational challenge.
Users without owner or “manage all workspaces” permission would still need to be able to reuse variables across workspaces in a project. Some workarounds for this would be to:
- Submitting requests to platform teams to create variable sets on their behalf.
- Duplicating variables across multiple workspaces as workspace-specific variables.
These workarounds add unnecessary dependency on the platform team and make workspace variables difficult to manage. Duplicating sensitive variables (e.g., cloud credentials) across multiple workspaces creates significant manual effort when rotating values. Updating a credential requires changes in potentially hundreds of places, increasing operational toil, the risk of inconsistency, and the potential for security vulnerabilities if some workspaces are missed.
Customers needed more granular permissions around variable sets to delegate their creation to project admins without giving them permissions to impact workspaces and variable sets outside of the projects they administer.
» Introducing project-owned variable sets
Project-owned variable sets allow users to reuse variables for a set of workspaces within a specific project. They can still be more granularly scoped to none, some, or all workspaces within the specified project, but project-owned variable sets cannot be “global” and they cannot be applied to workspaces outside their specified project. Now HCP Terraform and Terraform Enterprise variable sets can have one of three different scopes:
- Global: The set will apply to all current and future workspaces within an organization.
- Project-specific: The set will apply to all current and future workspaces within the selected projects.
- Workspace-specific: The set will apply only to the selected workspaces.
This solution addresses both the need for more granular permissions and the requirement for variable reuse across project workspaces, while ensuring that users maintain appropriate levels of access control.
» What benefits do project-owned variable sets have?
Project-owned variable sets allow more granular permissions for creating and managing access and usage of variable sets. Key benefits include:
- Facilitates transition to projects and consolidation: This feature enables a smoother transition from using multi-org systems to adopting a project-based structure as teams can manage variable sets with project-level permissions.
- Simplified management of variable sets: Users with write-level project access can create, edit, and delete variable sets that apply to only their projects without organization-level workspace or owner access. This allows for greater flexibility without increasing the risk for unauthorized access to resources outside their scope. It also limits the potential damage caused by a misconfigured variable or cloud credential.
- Granular control of variable sets: Project admins control who can read, manage, or access specific variable sets within their project. Teams can be granted custom permission to manage variable sets within a project without other project-level permissions, such as the ability to perform a run.
- Increased operational efficiency: By allowing project teams to manage their own variable sets, platform teams can offload this responsibility, leading to more streamlined operations. Project admins can now focus on managing their own variables without needing to request changes from higher-level teams or risk misconfigurations.
» Looking forward
This feature empowers project teams with the control they need to manage their infrastructure efficiently while maintaining a high level of security and governance. This will also facilitate a smoother transition from using multi-org systems to adopting projects.
We’re excited to continue enhancing the user experience for all of our customers. To learn more about the new features, visit the Terraform guides and documentation on HashiCorp Developer. If you are new to Terraform, sign up for HCP Terraform and get started for free today, or contact HashiCorp sales to learn more about Terraform Enterprise.
Sign up for the latest HashiCorp news
More blog posts like this one

A smoother HCP Terraform workspace experience
Learn how to automate HCP Terraform workspace setup and onboarding with the TFE provider, a custom module, and good requirements gathering.

ServiceNow Terraform plugin updates: No-code execution mode, key-value tags, and enhanced security
The ServiceNow plugins for Terraform are being updated with new enhancements that implement no-code execution mode, key-value tags, and increased encryption security enhancements.

Which Terraform workflow should I use? VCS, CLI, or API?
Learn about the three levels of HCP Terraform run workflows and key considerations to guide your decision on when to use each approach.