Terraform: v0.12 - terraform validate - different behaviour from v0.11 with terraform_remote_state data source

[t3mi]

Terraform Version

Terraform v0.12.5

Terraform Configuration Files

data "terraform_remote_state" "dev" {
    backend = "azurerm"
    config = {
        resource_group_name  = "terraformmf"
        storage_account_name = "storageaccount0864213579"
        container_name       = "terraformstates"
        key                  = "dev.terraform.state"
    }
}

Expected Behavior

Terraform validate shound not require any authentication to be configured or a opt-out possiblity.

Actual Behavior

Error: Error building ARM Config: Error retrieving the Profile from the Azure CLI: No Subscription was Marked as Default in the Azure Profile. Please re-authenticate using `az login`.

Steps to Reproduce

terraform validate

Additional Context

Terraform validate with previous version 0.11.14 doesn't throw any errors and doesn't require authentication while 0.12.5 requires connection variables to be present, authenticated and configured so that terraform validate could successfully obtain remote state data.

References

Maybe this issue is part of #21408 as well.

[cehoffman]

Ran into this as well. This is making it impossible to have rudimentary syntax checks for our external contributors without exposing secrets to them.

[knl]

Yes, observing this also in v0.12.6. We can't run terraform validate in our CI, as it runs everything in a sandbox.

[aerickson]

This continues to not work with Terraform 12.7.

Here's a repo demonstrating the issue: https://github.com/aerickson/terraform_hacking

[heymega]

Not working with 0.12.9

Is there a workaround?

[aerickson]

Still not working in 0.12.10.

[arcotek-ltd]

I'm running 0.12.10 and encountered the same issue. Until it is fixed, I've cheated and added the access_key of the storage account. My data declaration (for Azure) looks like:

data "terraform_remote_state" "example" {
  backend = "azurerm"
  config = {
    resource_group_name  = "resource_group_containing_storage_account"
    storage_account_name = "storage_account_containing_state_container"
    container_name       = "tfstate"
    key                  = "prefix/mystatefile.tfstate"
    access_key           = "mylongaccesskey" #From Storage Account > Access Key
  }
}

I expect one can add subscription_id, tenant_id etc, as per: https://www.terraform.io/docs/backends/types/azurerm.html

HTH

Update 22/10/2019

Updated TF to 0.12.12. Experiencing same issue.

[eytanhanig]

I have a workaround for when backend = "remote", which is used be Terraform Enterprise & Cloud: First define a variable whose value is the desired name, then reference the variable:

variable "desired_name" {
  description = "DO NOT CHANGE - This is part of a hack to get around a TFE bug causing false validation errors."
  default     = "master-org"
}

# Used to retrieve account info
data "terraform_remote_state" "desired_name" {
  backend = "remote"
  config = {
    organization = "your_org"
    workspaces = {
      # TF bug results in this only working if the value includes a variable
      name = var.desired_name
    }
  }
}

I recommend trying something similar for the other backend types.

[bendrucker]

For everyone in this thread, this will be fixed in an upcoming release!

@apparentlymart This is another one that should be closed by #24887 that I missed.

[wyardley]

Since #24887 is locked, and since it wasn't in 0.12.25 or 0.12.26, do we know when this is going to land? Will the PRs / issues get marked with any additional labels or comments when it is released?

[mitchellrj]

It looks like this is going to be a 0.13-only feature with no backport to 0.12 :(

[wyardley]

I was able to confirm that it works as expected with 0.13, though.

[apparentlymart]

Hi all! Sorry for the slow update here... this was indeed fixed by @bendrucker in #24887, so I'm going to close this. Thanks!

[hashibot[bot]]

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.