Update 4.0.0 subscription_id is not optional in provider azurerm

[yasvanth511]

Is there an existing issue for this?

• I have searched the existing issues

Community Note

• Please vote on this issue by adding a 👍 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.42

AzureRM Provider Version

4.0.0

Affected Resource(s)/Data Source(s)

azurerm

Terraform Configuration Files

# We strongly recommend using the required_providers block to set the
# Azure Provider source and version being used
terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "=4.0.0"
    }
  }
}

# Configure the Microsoft Azure Provider
provider "azurerm" {
  resource_provider_registrations = "none" # This is only required when the User, Service Principal, or Identity running Terraform lacks the permissions to register Azure Resource Providers.
  features {}
}

# Create a resource group
resource "azurerm_resource_group" "example" {
  name     = "example-resources"
  location = "West Europe"
}

# Create a virtual network within the resource group
resource "azurerm_virtual_network" "example" {
  name                = "example-network"
  resource_group_name = azurerm_resource_group.example.name
  location            = azurerm_resource_group.example.location
  address_space       = ["10.0.0.0/16"]
}

Debug Output/Panic Output

│ provider "azurerm" {
│
│ The argument "subscription_id" is required, but no definition was found.

Expected Behaviour

The subscription_id should remain optional, as it was in the previous version and as stated in the documentation.

Actual Behaviour

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

Steps to Reproduce

terraform validate

Important Factoids

No response

References

[subscription_id]- (Optional) The Subscription ID which should be used. This can also be sourced from the ARM_SUBSCRIPTION_ID Environment Variable.

url: (https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs#subscription_id)

[jhutchings]

@yasvanth511 this is called out in the upgrade guide as a new requirement https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/guides/4.0-upgrade-guide#specifying-subscription-id-is-now-mandatory

I get the convenience of not needing to set it but I can also see where they're coming from on:

Users authenticating the provider using Azure CLI, however, may previously have elected to omit the subscription ID from their Terraform configuration and rely on the provider selecting the currently active subscription from Azure CLI. Whilst convenient, this behavior has historically led to a number of issues. In particular, when omitting the subscription ID, the provider cannot guarantee that a plan is executed against the correct subscription.

By making it mandatory to specify the subscription ID for all authentication methods, this will also make it possible to implement a number of improvements to our authentication support in the future.

[manicminer]

@yasvanth511 Thanks for reporting this documentation issue, this unfortunately slipped through whilst we were updating the docs for v4.0. I've corrected this in #27178, and also fixed a bug that prevented terraform validate from running. This will go out very soon in a v4.0.1 patch release.

The subscription_id property will be required from v4.0, for plan/apply/refresh operations. As @jhutchings mentioned, this ensures consistency between plan/apply operations, and prevents a number of issues that stem from sourcing this from Azure CLI.

[github-actions]

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.