TF_WORKSPACE allows workspace names 'terraform workspace' does not

[whatsfordinner]

Terraform Version

Terraform v0.12.24

Terraform Configuration Files

Just using a basic S3 backend

terraform {
  backend "s3" {
    key = "github-actions-tfstate"
  }
}

Expected Behavior

Workspace names sourced from TF_WORKSPACE should undergo the same syntax checking as the terraform workspace commands and Terraform should error out appropriately.

Actual Behavior

Using TF_WORKSPACE makes it possible to define invalid workspace names.

Steps to Reproduce

1. terraform init
2. terraform workspace new 'inv${}alid'
3. TF_WORKSPACE='inv${}alid' terraform plan
4. terraform workspace list

E.g.:

$ terraform init -backend-config="bucket=${STATE_BUCKET}"
$ terraform workspace new 'inv${}alid'
The workspace name "inv${}alid" is not allowed. The name must contain only URL safe
characters, and no path separators.
$ TF_WORKSPACE='inv${}alid' terraform plan
$ terraform workspace list
* default
  inv${}alid
$ terraform workspace select 'inv${}alid'
The workspace name "inv${}alid" is not allowed. The name must contain only URL safe
characters, and no path separators.

[whatsfordinner]

I was having a look at where the workspace gets validated in the codebase, and it looks like the validWorkspaceName() function only gets called for workspace new, workspace select and workspace delete. However, all the other commands call the Meta.Workspace() method which calls Meta.WorkspaceOverridden() and if TF_WORKSPACE is set then it just returns it without any validation being performed:

func (m *Meta) WorkspaceOverridden() (string, bool) {
	if envVar := os.Getenv(WorkspaceNameEnvVar); envVar != "" {
		return envVar, true
	}

	envData, err := ioutil.ReadFile(filepath.Join(m.DataDir(), local.DefaultWorkspaceFile))
	current := string(bytes.TrimSpace(envData))
	if current == "" {
		current = backend.DefaultStateName
	}

	if err != nil && !os.IsNotExist(err) {
		// always return the default if we can't get a workspace name
		log.Printf("[ERROR] failed to read current workspace: %s", err)
	}

	return current, false
}

Because of how TF_WORKSPACE is used primarily in automation, rather than returning the default workspace I think it'd be safer for the command to fail. So maybe Meta.Workspace() could validate the workspace name before returning, and update its return types to (string, error)?

[danieldreier]

I've verified this against 0.13.0 beta 1, so it's definitely still a real issue. Note that this does not require an S3 backend. I reproduced it against just:
example.tf

resource null_resource "example" {}

bash-3.2$ terraform init

Initializing the backend...

Initializing provider plugins...
- Finding latest version of hashicorp/null...
- Installing hashicorp/null v2.1.2...
- Installed hashicorp/null v2.1.2 (signed by HashiCorp)

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, we recommend adding version constraints in a required_providers block
in your configuration, with the constraint strings suggested below.

* hashicorp/null: version = "~> 2.1.2"

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
bash-3.2$ TF_WORKSPACE='inv${}alid' terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.


------------------------------------------------------------------------

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # null_resource.example will be created
  + resource "null_resource" "example" {
      + id = (known after apply)
    }

Plan: 1 to add, 0 to change, 0 to destroy.

------------------------------------------------------------------------

Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.

bash-3.2$ terraform workspace list
* default
  inv${}alid

bash-3.2$ terraform workspace select 'inv${}alid'

The workspace name "inv${}alid" is not allowed. The name must contain only URL safe
characters, and no path separators.

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.