The argument "subscription_id" is required, but no definition was found

[shess-macu]

Is there an existing issue for this?

• [X] I have searched the existing issues

Community Note

• Please vote on this issue by adding a :thumbsup: reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave comments along the lines of "+1", "me too" or "any updates", they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment and review the contribution guide to help.

Terraform Version

1.9.4

AzureRM Provider Version

4.0.0

Affected Resource(s)/Data Source(s)

azurerm provider

Terraform Configuration Files

provider "azurerm" {
  features {}
}

Debug Output/Panic Output

Error: Missing required argument
│
│   on base.tf line 1, in provider "azurerm":
│    1: provider "azurerm" {
│
│ The argument "subscription_id" is required, but no definition was found.

Expected Behaviour

subscription_id should not be required

Actual Behaviour

No response

Steps to Reproduce

create a basic terraform config with azurerm provider using version 4.0.0. Run terraform init and then terraform validate

Important Factoids

No response

References

No response

[shess-macu]

I was able to confirm all previous versions of the azurerm provider work as expected. Including version 3.116.0. This seems to have broken in 4.0.0

[shess-macu]

I was able to find the documentation on this. Looks like this is expected behavior. Which is unfortunate. https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/guides/4.0-upgrade-guide#specifying-subscription-id-is-now-mandatory

[stephybun]

Thanks for raising this issue @shess-macu!

As you've already found, this is one of the breaking changes we introduced in 4.0. Since this is neither a bug nor a feature request I'm going to go ahead and close this issue.

[LiamLeane]

This breaks a large number of CI scenarios where terraform doesn't, and should not, have subscription/tenant details available. I absolutely understand requiring it to be set for CLI auth when an apply is performed but not for a validation.

Additionally in cases where engineers intentionally do not have access to subscriptions and instead rely on automation via TFC/GHA/etc to plan their changes it means they can't perform a terraform validate without setting a dummy value.

This is extremely inconsistent with all the other providers. Are you really telling us we have to set an env var to 00000000-0000-0000-0000-000000000000 for the provider to be able to validate?

[manicminer]

@LiamLeane Thanks for reporting, that's definitely a bug. It should be possible to run terraform validate without providing authentication details. We'll issue a fix for this shortly.

[gustavonj]

Thanks for raising this issue @shess-macu!

As you've already found, this is one of the breaking changes we introduced in 4.0. Since this is neither a bug nor a feature request I'm going to go ahead and close this issue.

@stephybun this change broke the terraform validate :( and CI pipelines

[manicminer]

@gustavonj This will be fixed in v4.0.1 (see #27178)

[shess-macu]

Thank you @manicminer !