Terraform Enterprise centralizes runs and policy enforcement

An infrastructure configuration can be reusable while the process for changing it remains difficult to share. Someone must supply credentials, retain state and decide whether a proposed change is acceptable. A common configuration language does not by itself assign those responsibilities across an organization. Terraform Enterprise's general availability release concentrates on the workflow around that language.

The December 12 announcement makes the new Terraform Enterprise available for broad production use after its beta. It describes centrally managed workspaces, comprehensive APIs and identity integrations. Sentinel policy checks add a decision point between a completed plan and the application of its changes.

I value Terraform as a reusable abstraction over infrastructure APIs. An enterprise workflow interests me when it preserves that configuration model while making authority and execution visible. The important question is who can propose or authorize a change and which evidence the system evaluates before resources change.

Workspaces describe smaller ownership units

The announcement explains why the previous environment terminology caused confusion. A production environment can contain separately managed networking and application components. Treating that entire collection as one environment-shaped configuration does not necessarily match how teams divide responsibility.

Terraform Enterprise uses workspaces as units that can have separate ownership. It centralizes them with permissions, history and an interface for collaboration. A workspace can connect to a version-control repository containing Terraform configuration, and the service retains configuration and state history.

This is a useful distinction between a business environment and a unit of infrastructure management. A production system can need several workspaces because its components have different maintainers or change schedules. The workspace name does not have to imply that all production infrastructure belongs to one state.

The announcement relates Enterprise workspaces to Terraform's existing ability to manage multiple states for a configuration. Enterprise adds centralized management and workflow around that concept. The added interface and permissions are part of the service, so a comparison should state which responsibilities the service now handles.

Dividing a configuration into components still requires an interface between them. Centralized workspace management does not determine whether networking should be independent from an application or which values one component exposes to another. It provides a place to implement the ownership decision after the architecture establishes it.

A run connects configuration to approval

The new interface places the latest run prominently within a workspace. Its run timeline links configuration with plan and apply logs and provides the approval action for planned changes. That association makes the proposed infrastructure work a reviewable operation with a recorded context.

Version-control integration supplies another entry point. The release describes connecting a workspace to a repository and using changes there to start the Terraform workflow. For Bitbucket Server specifically, a selected branch can trigger new runs on commits, and merge requests receive Terraform plan status.

The useful connection is between source changes and evaluated infrastructure changes. A text diff describes edits to configuration, while a Terraform plan describes their proposed effect under the current inputs and state. Linking both helps a reviewer understand why the system proposes particular resource operations.

It does not make a version-control merge equivalent to every possible deployment approval policy. The service has explicit run confirmation and policy checks. Those decisions need to be understood as parts of the workflow that follows or accompanies source changes.

APIs support service-owned execution

The GA announcement says GUI operations use the same APIs available to users. This extends beyond a small set of run endpoints. The stated scope includes programmatic management of workspaces, teams and access control, alongside submitting configuration and triggering plans or applies.

That approach lets an existing provisioning system call Terraform Enterprise without reproducing the graphical workflow through browser automation. A CI service can request an operation and retrieve its status. Its integration can remain centered on a run and its recorded outcome.

Service accounts support those API-driven cases. The release adds organization-based and team-based accounts that can access APIs but cannot log in interactively. Their purpose is server-to-server calls under a service identity instead of an individual user's identity.

Separating those identities makes the authorization model easier to describe. A person's interactive account and an integration's long-lived responsibility are different subjects. The release supplies account types for the latter, while permissions still determine which operations each account may request.

Policy checks evaluate the proposed result

The GA release places Sentinel checks between plan and apply and requires Terraform Enterprise Premium for the feature. The plan gives policy code information about changes before Terraform creates, modifies or destroys resources. Policy can therefore evaluate intended infrastructure values before the corresponding API operations occur.

The November 2 explanation of Sentinel integration describes the tfplan plugin as the source of Terraform plan, configuration and state data for policy evaluation. Its example examines AWS security-group ingress and disallows a CIDR block of 0.0.0.0/0.

The example checks the resource's applied values, meaning the values that would result if the plan were applied. This is a different question from whether the configuration contains a particular literal string. Expressions and module inputs can contribute to the planned value that a policy needs to evaluate.

A source-code convention alone might miss the resulting configuration after those inputs combine. A plan-aware check can reason about the proposed infrastructure representation available to Terraform. The scope remains what that representation exposes, rather than an independent audit of every possible change made outside Terraform Enterprise.

I prefer this point in the workflow for infrastructure policy because it uses the proposed operation as evidence. A reviewer can relate a failed condition to the same plan that the run would otherwise apply.

Enforcement modes change the authority required

The Sentinel integration describes advisory policies as warnings that do not prevent application. This allows a policy to provide feedback without making its failure an authorization barrier. A failed advisory check and a blocked run are therefore different outcomes.

A soft mandatory policy requires a suitably authorized operator to override a failure before application. The explanation shows an organization owner recording an override and a reason, after which the run can proceed to confirmation. That override is itself an explicit decision in the workflow.

Hard mandatory policies do not offer an override. A failure requires a change to configuration or policy before application can proceed. The distinction is material because the same policy expression has different operational consequences under different enforcement modes.

It would therefore be inaccurate to say every failed Sentinel rule prevents an apply. The configured mode determines the consequence. The expression states the condition, while enforcement determines whether a warning, an authorized exception or an unavoidable block follows.

The November explanation describes policies configured at organization level and applied across its workspaces. It presents workspace-specific configuration and policy source integration with version control as future work at that point. Those plans should not be mistaken for capabilities established by the GA announcement's broader description of policy support.

Identity integration includes team assignment

SAML single sign-on lets users authenticate through a corporate identity provider. The announcement also says SAML assertions can map users to teams automatically. This connects the external identity system to Terraform Enterprise authorization groupings.

Authentication and team membership have different effects. Establishing who a user is does not by itself specify which workspaces or operations that user may access. Mapping assertions to teams supplies a relationship that the Enterprise permission model can use.

Bitbucket Server integration addresses a separate organizational constraint. It lets repositories hosted in that service participate in workspace creation and run triggering. SAML integration determines how users access Terraform Enterprise, while the version-control integration connects infrastructure source changes to runs.

Configuration compatibility does not imply service-data compatibility

The announcement says configurations written for the previous Terraform Enterprise remain compatible. It separately says the former Atlas organizations and environments are not compatible with the new organizations and workspaces. Migration therefore includes service-managed structures and associated state, even when the Terraform language files need no rewrite.

That distinction prevents a misleading interpretation of compatibility. A configuration can still describe valid infrastructure while its surrounding execution records and organizational objects need migration. Source compatibility answers whether the files can run, while service migration preserves the context in which they run.

The GA release makes that surrounding context a substantial part of the product. Workspaces assign ownership, APIs admit service integrations and policies evaluate proposed changes before execution. The practical value depends on configuring those relationships so each run has the intended source, identity and approval requirements.