fix: Block commands from using an invalid workspace name.

[SarahFrench]

Background

Workspace names need to be valid. For Terraform, valid means the name should not require escaping if they were used in a URL. The workspace new and workspace select command have validation that checks users have supplied a valid name as an argument, so workspaces with invalid names cannot be created through Terraform.

However, out-of-band changes could create workspaces or select workspaces that have invalid names. This should not happen; external systems should not manage things that are solely meant to be managed by Terraform. Despite that, we want users to be enabled by the Terraform CLI to address and fix these issues if they arise.

An example situation is that something other than Terraform sets the contents of .terraform/environment. This is a file that's used by Terraform to track which workspace is selected, and just like all things in the .terraform folder it is an implementation detail of Terraform and not a public API. Despite this, something could edit the contents of that file. Currently Terraform is designed with the assumption that the CLI is the only owner of the .terraform/environment file and that preventing bad values entering it (via validation in workspace new and workspace select commands) is sufficient protection. When the file is read the value is not re-validated.

This PR adds validation at the point that Terraform reads the .terraform/environment file to learn about the last-selected workspace's name.

Expected Workflow

Following this PR the majority of Terraform commands will error out if the selected workspace has an invalid name. This can only happen if the .terraform directory has been interfered with unexpectedly, so enforcing a fix before Terraform can resume working feels appropriate.

The returned error will prompt the user to select or create a different workspace via the workspace select command. Users are expected to select the intended, pre-existing workspace and then resume operations. If the user is in a situation where no other workspaces exist they are able to create one via workspace select -or-create.

The user will be responsible to identify what caused the issue, as it was not due to Terraform.

Implementation

This PR validates the contents of .terraform/environment in the same way that the value of the TF_WORKSPACE environment variable is currently validated. This logic is invoked during the process of initialising a backend, so validation errors will cause any command that interacts with state/launches a backend to error early.

The one exception is the workspace select command, as that command needs to work in this scenario when fixing the environment file's contents. This is currently achieved in the PR via a field on the Meta struct that allows commands to choose to bypass workspace name validation. That option is only enabled in workspace select.

TODOs for review process

• Should the changes to (Meta) WorkspaceOverride, etc, be replicated in the Stack-related side of the codebase?
• Alternative approaches?

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.

[SarahFrench]

@radeksimko - do you think that the changes to (Meta) WorkspaceOverride, etc, be replicated in the Stack-related side of the codebase?

I haven't done that in this PR, and my justification is that this PR protects against potential malicious changes taking place on a user-controlled machine. As Stacks is controlled by us then the risk is arguably not there. But then there's the downsides of having two implementations of basically the same thing being different.

What do you think?

[radeksimko]

That is a good question. I think you laid out all the (counter) arguments well, so I have nothing more to add there. 😄 I'm happy to re-approve if you wish to apply the same change to stacks.

I think it would be great if this was shared code to some extent but I suppose that's an entirely separate conversation to have. We already learnt the hard way recently that code duplication in Stacks can be harmful, so I suppose this isn't something to disagree with - it's more about when we do it, not if.