terraform_remote_state remote backend ignores token in config block when token is present in CLI config

[tangentspace]

Terraform Version

Terraform v1.1.7

Terraform Configuration Files

data "terraform_remote_state" "example" {
  backend = "remote"

  config = {
    hostname     = "terraform.example.com"
    token        = var.tfe_example_access_token
    organization = "ExampleOrg"
    workspaces = {
      name = "ExampleWorkspace"
    }
  }
}

output "something" {
  value = data.terraform_remote_state.example.outputs.vpcs
}

Expected Behavior

Terraform uses the API token provided in the config block to access the remote state for the target workspace.

Actual Behavior

Terraform always uses the API token from the CLI config file when it exists, ignoring the token explicitly provided in config block.

Steps to Reproduce

Create a .terraformrc file containing a token which does not have access to the target workspace.

Additional Context

This makes it impossible to configure API tokens for workspaces that are not accessible using the token defined in the .terraformrc file. In previous Terraform versions which used the atlas backend, the data source token config overrode other config sources, and this behavior has changed in the new remote backend which breaks existing workflows.

References

I opened a PR that implements the desired functionality: #30663

[rubyisbeautiful]

In a possibly related issue, the expected behavior of providing the token on the commandline, e.g. terraform init -backend-config=token=abc123 would be to override .terraformrc, but it does not. This is not documented.
I see #30917 addresses that.

[crw]

Thanks for these reports! I am checking to see if this issue was fixed by that same PR, but have yet to hear back. I'll update this issue when I hear back. Thanks again!

[Maraket]

So this issue still seems to be present with Terraform 1.8.4, and due to running my script in our CICD environment (bitbucket pipelines) every solution I can think of has a horrible code smell, is there any visibility on this getting fixed?

[crw]

@Maraket This issue should have been fixed with #30917 -- can you confirm that this is the same bug, or open a new issue if you have discovered a different issue? Thanks!

[jbardin]

Since we have not heard back in a while I'm going to close the issue. If you have any updates regarding the issue, feel free to open a new issue with the requested information. If you have more questions, you can also use the community forum where there are more people ready to help.

Thanks!