• Overview
    • Enforce Policy as Code
    • Infrastructure as Code
    • Inject Secrets into Terraform
    • Integrate with Existing Workflows
    • Manage Kubernetes
    • Manage Virtual Machine Images
    • Multi-Cloud Deployment
    • Network Infrastructure Automation
    • Terraform CLI
    • Terraform Cloud
    • Terraform Enterprise
  • Registry
  • Tutorials
    • About the Docs
    • Intro to Terraform
    • Configuration Language
    • Terraform CLI
    • Terraform Cloud
    • Terraform Enterprise
    • Provider Use
    • Plugin Development
    • Registry Publishing
    • Integration Program
    • Terraform Tools
    • CDK for Terraform
    • Glossary
  • Community
GitHubTerraform Cloud
Download

    Terraform Cloud and Enterprise

  • Overview
  • Plans and Features
  • Getting Started
    • API Docs template
    • Overview
    • Account
    • Agent Pools
    • Agent Tokens
    • Applies
    • Audit Trails
    • Comments
    • Configuration Versions
    • Cost Estimates
    • Feature Sets
    • Invoices
    • IP Ranges
    • Notification Configurations
    • OAuth Clients
    • OAuth Tokens
    • Organizations
    • Organization Memberships
    • Organization Tags
    • Organization Tokens
    • Plan Exports
    • Plans
    • Policies
    • Policy Checks
    • Policy Sets
    • Policy Set Parameters
      • Modules
      • Providers
      • Private Provider Versions and Platforms
      • GPG Keys
    • Runs
      • Run Tasks
      • Stages and Results
      • Custom Integration
    • Run Triggers
    • SSH Keys
    • State Versions
    • State Version Outputs
    • Subscriptions
    • Team Access
    • Team Membership
    • Team Tokens
    • Teams
    • User Tokens
    • Users
    • Variables
    • VCS Events
    • Workspaces
    • Workspace-Specific Variables
    • Workspace Resources
    • Variable Sets
      • Overview
      • Module Sharing
      • Organizations
      • Runs
      • Settings
      • Terraform Versions
      • Users
      • Workspaces
    • Changelog
    • Stability Policy
    • Overview
    • Creating Workspaces
    • Naming
    • Terraform Configurations
      • Overview
      • Managing Variables
      • Overview
      • VCS Connections
      • Access
      • Drift Detection
      • Notifications
      • SSH Keys for Modules
      • Run Triggers
      • Run Tasks
    • Terraform State
    • JSON Filtering
    • Remote Operations
    • Viewing and Managing Runs
    • Run States and Stages
    • Run Modes and Options
    • UI/VCS-driven Runs
    • API-driven Runs
    • CLI-driven Runs
    • The Run Environment
    • Installing Software
    • Users
    • Teams
    • Organizations
    • Permissions
    • Two-factor Authentication
    • API Tokens
      • Overview
      • Microsoft Azure AD
      • Okta
      • SAML
      • Linking a User Account
      • Testing
    • Overview
    • GitHub.com
    • GitHub.com (OAuth)
    • GitHub Enterprise
    • GitLab.com
    • GitLab EE and CE
    • Bitbucket Cloud
    • Bitbucket Server and Data Center
    • Azure DevOps Services
    • Azure DevOps Server
    • Troubleshooting
    • Overview
    • Adding Public Providers and Modules
    • Publishing Private Providers
    • Publishing Private Modules
    • Using Providers and Modules
    • Configuration Designer
  • Migrating to Terraform Cloud
    • Overview
    • Using Sentinel with Terraform 0.12
    • Manage Policies
    • Enforce and Override Policies
    • Mocking Terraform Sentinel Data
    • Working With JSON Result Data
      • Overview
      • tfconfig
      • tfconfig/v2
      • tfplan
      • tfplan/v2
      • tfstate
      • tfstate/v2
      • tfrun
    • Example Policies
    • Overview
    • AWS
    • GCP
    • Azure
      • Overview
      • Service Catalog
      • Admin Guide
      • Developer Reference
      • Example Customizations
      • V1 Setup Instructions
    • Splunk Integration
    • Kubernetes Integration
    • Run Tasks Integration
    • Overview
    • IP Ranges
    • Data Security
    • Security Model
    • Overview
    • Part 1: Overview of Our Recommended Workflow
    • Part 2: Evaluating Your Current Provisioning Practices
    • Part 3: How to Evolve Your Provisioning Practices
    • Part 3.1: From Manual Changes to Semi-Automation
    • Part 3.2: From Semi-Automation to Infrastructure as Code
    • Part 3.3: From Infrastructure as Code to Collaborative Infrastructure as Code
    • Part 3.4: Advanced Workflow Improvements

  • Terraform Cloud Agents

  • Terraform Enterprise Admin

  • Other Docs

  • Intro to Terraform
  • Configuration Language
  • Terraform CLI
  • Terraform Cloud
  • Terraform Enterprise
  • Provider Use
  • Plugin Development
  • Registry Publishing
  • Integration Program
  • Terraform Tools
  • CDK for Terraform
  • Glossary
Type '/' to Search

»Mocking Terraform Sentinel Data

Note: Sentinel policies are a paid feature, available as part of the Team & Governance upgrade package. Learn more about Terraform Cloud pricing here.

We recommend that you test your Sentinel policies extensively before deploying them within Terraform Cloud. An important part of this process is mocking the data that you wish your policies to operate on.

Due to the highly variable structure of data that can be produced by an individual Terraform configuration, Terraform Cloud provides the ability to generate mock data from existing configurations. This can be used to create sample data for a new policy, or data to reproduce issues in an existing one.

Testing policies is done using the Sentinel CLI. More general information on testing Sentinel policies can be found in the Testing section of the Sentinel runtime documentation.

Be careful! Mock data generated by Terraform Cloud directly exposes any and all data within the configuration, plan, and state. Terraform attempts to scrub sensitive data from these mocks, but we do not guarantee 100% accuracy. Treat this data with care, and avoid generating mocks with live sensitive data when possible. Access to this information requires permission to download Sentinel mocks for the workspace where the data was generated.

»Generating Mock Data Using the UI

Mock data can be generated using the UI by expanding the plan status section of the run page, and clicking on the Download Sentinel mocks button.

sentinel mock generate ui

For more information on creating a run, see the Terraform Runs and Remote Operations section of the docs.

If the button is not visible, then the plan is ineligible for mock generation or the user doesn't have the necessary permissions. See Mock Data Availability for more details.

»Generating Mock Data Using the API

Mock data can also be created with the Plan Export API.

Multiple steps are required for mock generation. The export process is asynchronous, so you must monitor the request to know when the data is generated and available for download.

  1. Get the plan ID for the run that you want to generate the mock for by getting the run details. Look for the id of the plan object within the relationships section of the return data.
  2. Request a plan export using the discovered plan ID. Supply the Sentinel export type sentinel-mock-bundle-v0.
  3. Monitor the export request by viewing the plan export. When the status is finished, the data is ready for download.
  4. Finally, download the export data. You have up to an hour from the completion of the export request - after that, the mock data expires and must be re-generated.

»Using Mock Data

Note: The v2 mock files are only available on Terraform 0.12 and higher.

Mock data is supplied as a bundled tarball, containing the following files:

mock-tfconfig.sentinel    # tfconfig mock data
mock-tfconfig-v2.sentinel # tfconfig/v2 mock data
mock-tfplan.sentinel      # tfplan mock data
mock-tfplan-v2.sentinel   # tfplan/v2 mock data
mock-tfstate.sentinel     # tfstate mock data
mock-tfstate-v2.sentinel  # tfstate/v2 mock data
mock-tfrun.sentinel       # tfrun mock data
sentinel.hcl              # sample configuration file
mock-tfconfig.sentinel    # tfconfig mock data
mock-tfconfig-v2.sentinel # tfconfig/v2 mock data
mock-tfplan.sentinel      # tfplan mock data
mock-tfplan-v2.sentinel   # tfplan/v2 mock data
mock-tfstate.sentinel     # tfstate mock data
mock-tfstate-v2.sentinel  # tfstate/v2 mock data
mock-tfrun.sentinel       # tfrun mock data
sentinel.hcl              # sample configuration file

The sample sentinel.hcl file contains mappings to the mocks so that you can get started testing with sentinel apply right away. For sentinel test, however, we recommend a more detailed layout.

We recommend placing the files for sentinel test in a subdirectory of the repository holding your policies, so they don't interfere with the command's automatic policy detection. While the test data is Sentinel code, it's not a policy and will produce errors if evaluated like one.

.
├── foo.sentinel
├── sentinel.hcl
├── test
│   └── foo
│       ├── fail.hcl
│       └── pass.hcl
└── testdata
    ├── mock-tfconfig.sentinel
    ├── mock-tfconfig-v2.sentinel
    ├── mock-tfplan.sentinel
    ├── mock-tfplan-v2.sentinel
    ├── mock-tfstate.sentinel
    ├── mock-tfstate-v2.sentinel
    └── mock-tfrun.sentinel
.
├── foo.sentinel
├── sentinel.hcl
├── test
│   └── foo
│       ├── fail.hcl
│       └── pass.hcl
└── testdata
    ├── mock-tfconfig.sentinel
    ├── mock-tfconfig-v2.sentinel
    ├── mock-tfplan.sentinel
    ├── mock-tfplan-v2.sentinel
    ├── mock-tfstate.sentinel
    ├── mock-tfstate-v2.sentinel
    └── mock-tfrun.sentinel

Each configuration that needs access to the mock should reference the mock data files within the mock block in the Sentinel configuration file.

For sentinel apply, this path is relative to the working directory. Assuming you always run this command from the repository root, the sentinel.hcl configuration file would look like:

mock "tfconfig" {
  module {
    source = "testdata/mock-tfconfig.sentinel"
  }
}

mock "tfconfig/v1" {
  module {
    source = "testdata/mock-tfconfig.sentinel"
  }
}

mock "tfconfig/v2" {
  module {
    source = "testdata/mock-tfconfig-v2.sentinel"
  }
}

mock "tfplan" {
  module {
    source = "testdata/mock-tfplan.sentinel"
  }
}

mock "tfplan/v1" {
  module {
    source = "testdata/mock-tfplan.sentinel"
  }
}

mock "tfplan/v2" {
  module {
    source = "testdata/mock-tfplan-v2.sentinel"
  }
}

mock "tfstate" {
  module {
    source = "testdata/mock-tfstate.sentinel"
  }
}

mock "tfstate/v1" {
  module {
    source = "testdata/mock-tfstate.sentinel"
  }
}

mock "tfstate/v2" {
  module {
    source = "testdata/mock-tfstate-v2.sentinel"
  }
}

mock "tfrun" {
  module {
    source = "testdata/mock-tfrun.sentinel"
  }
}
mock "tfconfig" {
  module {
    source = "testdata/mock-tfconfig.sentinel"
  }
}

mock "tfconfig/v1" {
  module {
    source = "testdata/mock-tfconfig.sentinel"
  }
}

mock "tfconfig/v2" {
  module {
    source = "testdata/mock-tfconfig-v2.sentinel"
  }
}

mock "tfplan" {
  module {
    source = "testdata/mock-tfplan.sentinel"
  }
}

mock "tfplan/v1" {
  module {
    source = "testdata/mock-tfplan.sentinel"
  }
}

mock "tfplan/v2" {
  module {
    source = "testdata/mock-tfplan-v2.sentinel"
  }
}

mock "tfstate" {
  module {
    source = "testdata/mock-tfstate.sentinel"
  }
}

mock "tfstate/v1" {
  module {
    source = "testdata/mock-tfstate.sentinel"
  }
}

mock "tfstate/v2" {
  module {
    source = "testdata/mock-tfstate-v2.sentinel"
  }
}

mock "tfrun" {
  module {
    source = "testdata/mock-tfrun.sentinel"
  }
}

For sentinel test, the paths are relative to the specific test configuration file. For example, the contents of pass.json, asserting that the result of the main rule was true, would be:

mock "tfconfig" {
  module {
    source = "../../testdata/mock-tfconfig.sentinel"
  }
}

mock "tfconfig/v1" {
  module {
    source = "../../testdata/mock-tfconfig.sentinel"
  }
}

mock "tfconfig/v2" {
  module {
    source = "../../testdata/mock-tfconfig-v2.sentinel"
  }
}

mock "tfplan" {
  module {
    source = "../../testdata/mock-tfplan.sentinel"
  }
}

mock "tfplan/v1" {
  module {
    source = "../../testdata/mock-tfplan.sentinel"
  }
}

mock "tfplan/v2" {
  module {
    source = "../../testdata/mock-tfplan-v2.sentinel"
  }
}

mock "tfstate" {
  module {
    source = "../../testdata/mock-tfstate.sentinel"
  }
}

mock "tfstate/v1" {
  module {
    source = "../../testdata/mock-tfstate.sentinel"
  }
}

mock "tfstate/v2" {
  module {
    source = "../../testdata/mock-tfstate-v2.sentinel"
  }
}

mock "tfrun" {
  module {
    source = "../../testdata/mock-tfrun.sentinel"
  }
}

test {
  rules = {
    main = true
  }
}
mock "tfconfig" {
  module {
    source = "../../testdata/mock-tfconfig.sentinel"
  }
}

mock "tfconfig/v1" {
  module {
    source = "../../testdata/mock-tfconfig.sentinel"
  }
}

mock "tfconfig/v2" {
  module {
    source = "../../testdata/mock-tfconfig-v2.sentinel"
  }
}

mock "tfplan" {
  module {
    source = "../../testdata/mock-tfplan.sentinel"
  }
}

mock "tfplan/v1" {
  module {
    source = "../../testdata/mock-tfplan.sentinel"
  }
}

mock "tfplan/v2" {
  module {
    source = "../../testdata/mock-tfplan-v2.sentinel"
  }
}

mock "tfstate" {
  module {
    source = "../../testdata/mock-tfstate.sentinel"
  }
}

mock "tfstate/v1" {
  module {
    source = "../../testdata/mock-tfstate.sentinel"
  }
}

mock "tfstate/v2" {
  module {
    source = "../../testdata/mock-tfstate-v2.sentinel"
  }
}

mock "tfrun" {
  module {
    source = "../../testdata/mock-tfrun.sentinel"
  }
}

test {
  rules = {
    main = true
  }
}

»Mock Data Availability

The following factors can prevent you from generating mock data:

  • You do not have permission to download Sentinel mocks for the workspace. (More about permissions.) Permission is required to protect the possibly sensitive data which can be produced via mock generation.
  • The run has not progressed past the planning stage, or did not create a plan successfully.
  • The run progressed past the planning stage prior to July 23, 2021. Prior to this date, Terraform Cloud only kept JSON plans for 7 days.

If a plan cannot have its mock data exported due to any of these reasons, the Download Sentinel mocks button within the plan status section of the UI will not be visible.

Note: Only a successful plan is required for mock generation. Sentinel can still generate the data if apply or policy checks fail.

github logoEdit this page
  • Overview
  • Docs
  • Extend
  • Privacy
  • Security
  • Press Kit
  • Consent Manager