PSS: Allow users of Terraform in automation to trust the state storage provider when initialising a state store for the first time

[SarahFrench]

Description

Closes https://hashicorp.atlassian.net/browse/TF-36258

This PR follows #38395 and adds equivalent features for when Terraform is run in automation (i.e input is disabled).

Summary: during init Terraform needs to know that the provider it's going to start using for PSS is trusted, as the provider will be downloaded and used in the same operation. In interactive modes of using Terraform the user will be prompted to approve/reject a provider. In automation a different approach is needed. Then, Terraform will expect to be able to find a dependency lock file describing the new provider (version) that it's about to use. This could be via a dependency lock file that's supplied via a CLI flag and isn't necessarily the file in the working directory.

Usage

If Terraform is run in automation using a configuration that's in version control then every init is a 'first init' that creates the backend state for the first time. If there is a dependency lock file committed in the VCS that describes the provider used for PSS then Terraform will treat the state storage provider as trusted.

If PSS is being added to a project for the first time then the provider will not be described in the lock file yet; trust needs to be established on first use. Establishing that trust in an interactive setting means approving a prompt prior to downloading, using, and recording that provider in a lock file.

In an automated setting, we cannot prompt. Instead, we expect a user to supply a separate dependency lock file describing the provider to use for PSS to Terraform. This can be supplied via a new CLI flag, i.e. this lock file can be separate from the project's preexisting .terraform.hcl.lock file. If the lock for the state storage provider is supplied through a separate file then that lock will be added to the project's preexisting .terraform.hcl.lock file after a successful init operation.

NOTE: for systems where practitioners don't commit a dependency lock file to VCS they would need to supply the separate dependency lock file on every init.

Workflow

Just like how setting up a mirror or pre-approved list of providers to use requires some one-off pre-work, showing prior trust in a state store provider requires some (interactive) pre work to create an artefact that's reusable to show that trust has been established.

1. Practitioner initialises a Terraform project with minimal config describing how they'd like to use PSS in other production configurations. This is done manually, so they get an interactive prompt for approval and create a lock file describing the downloaded provider.

Example minimal config - enables checking that configuration is correct and compatible with a specified version of a provider.

terraform {
   required_providers {
      foobar = {
         source = "my-org/foobar"
         version = "~> 1.0.0"
      }
   }
  state_store "foobar_store" {
    provider "foobar" {
      # provider config
    }
    # store config
  }
}

Resulting .terraform.lock.hcl file from the manually-run init:

# This file is maintained automatically by "terraform init".
# Manual edits may be lost in future updates.

provider "registry.terraform.io/my-org/foobar" {
  version     = "1.0.1"
  constraints = "~> 1.0.0"
  hashes = [
    "h1:1234567890=",
    "zh:1234567890",
  ]
}

2. Practitioner copies that .terraform.lock.hcl artefact to a location that can be used in their automation environment.

3. Projects being initialised with PSS for the first time (no prior state) in automation are initialised using the command terraform init -state-provider-lock=<path-to-reused-lock-file>.
* That file shows prior trust of that provider version, so the init completes without error.

Target Release

1.16.x

Rollback Plan

• If a change needs to be reverted, we will roll out an update to the code within 7 days.

Changes to Security Controls

Are there any changes to security controls (access controls, encryption, logging) in this pull request? If so, explain.

CHANGELOG entry

• This change is user-facing and I added a changelog entry.
• This change is not user-facing.