Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

after upgrade of provider, alias is used even when not needed #26942

Open
1 task done
ludimax opened this issue Aug 6, 2024 · 3 comments
Open
1 task done

after upgrade of provider, alias is used even when not needed #26942

ludimax opened this issue Aug 6, 2024 · 3 comments

Comments

@ludimax
Copy link

ludimax commented Aug 6, 2024

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.9.3

AzureRM Provider Version

3.114.0

Affected Resource(s)/Data Source(s)

provider block

Terraform Configuration Files

provider "azurerm" {
  features {}
  storage_use_azuread = true
}

provider "azurerm" {
  alias                      = "az_iaas"
  subscription_id            = local.az_subscription_ids["iaas"]
  storage_use_azuread        = true
  skip_provider_registration = true
  features {}
}

Debug Output/Panic Output

Error: populating Resource Provider cache: listing Resource Providers: loading results: unexpected status 403 (403 Forbidden) with error: AuthorizationFailed: The client '00000000-0000-0000-0000-000000000000' with object id '00000000-0000-0000-0000-000000000000' does not have authorization to perform action 'Microsoft.Resources/subscriptions/providers/read' over scope '/subscriptions/00000000-0000-0000-0000-000000000000' or the scope is invalid. If access was recently granted, please refresh your credentials.
│ 
│   with provider["registry.terraform.io/hashicorp/azurerm"].az_iaas,
│   on providers.tf line 6, in provider "azurerm":
│   14: provider "azurerm" {

Expected Behaviour

This alias not being used, in this case it fails because the identity that does do the actual TF plan, has no permissions on that specific subscription.

Actual Behaviour

Alias is used, in our case wil give an error because there's no permissions to that subscription

Steps to Reproduce

  1. Create provider alias
  2. Give no permission on the subscription configured in the alias
  3. Create no specific resources for that alias
  4. It should ignore the provider alias, but it fails

Important Factoids

No response

References

No response

@wozorio
Copy link

wozorio commented Aug 6, 2024

I am also running into the same issue.

@teowa
Copy link
Contributor

teowa commented Aug 7, 2024

Hi @ludimax , the provider will try to list the resource provider registration in the subscription in order to

  1. register certain resource provider , this is controlled by skip_provider_registration inside provider block
  2. enable enhanced validation for resource provider, this can be controlled by ARM_PROVIDER_ENHANCED_VALIDATION env variable, which defaults to true

Seems after the PR https://github.com/hashicorp/terraform-provider-azurerm/pull/26630/files#diff-5a6fd8b8e9a3c349fc532826972d39b180350c4b1f5c9cf4c5b9e0bb31afec21R27, list resource provider only skips if RP registration and enhanced validation are not both disabled, so in conclusion, you need to set both skip_provider_registration=false and the env variable ARM_PROVIDER_ENHANCED_VALIDATION=false to avoid this error.

But you mentioned the provider alias az_iaas is not used, I suggest to comment or remove the provider block from Terraform config file.

Thanks.

@websolut
Copy link

I do not think adding an env variable is a sensible solution but rather a costly workaround. I suppose there is a good reason that var's default value is set to TRUE and have been working for all us for many years.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants