Terraform-provider-azurerm: AuthorizationPermissionMismatch when creating a storage account in 2.0.0

[krezreb]

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 "+1" or "me too" comments, 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

Terraform (and AzureRM Provider) Version

terraform v0.12.21
AzureRM Provider Version 2.0.0

Affected Resource(s)

• azurerm_storage_account

Terraform Configuration Files

resource "azurerm_storage_account" "storage" {
  name                              = local.name
  resource_group_name               = data.terraform_remote_state.resource_group.outputs.name
  location                          = var.location
  account_kind                      = var.account_kind
  account_tier                      = var.account_tier
  account_replication_type          = var.account_replication_type
  access_tier                       = var.access_tier
  is_hns_enabled                    = var.is_hns_enabled
  enable_https_traffic_only = true

  dynamic "network_rules" {
    for_each = var.network_rules != null ? ["true"] : []
    content {
      default_action             = "Deny"
      ip_rules                   = var.network_rules.ip_rules
      virtual_network_subnet_ids = var.network_rules.subnet_ids
      bypass                     = var.network_rules.bypass
    }
  }

  tags = var.tags
}

Full code available at https://github.com/krezreb/terraform-modules-azure/tree/master/storage/account

Debug Output

Panic Output

Expected Behavior

the storage account is created, remote state saved

Actual Behavior

the storage account is created, but the following error appears in the console.
remote state is saved, but is not correct because terraform destroy does not destroy it, resource must be deleted manually

azurerm_storage_account.storage: Refreshing state... [id=/subscriptions/27aaa3c6-5a24-4a2a-8117-8d4991ec6f07/resourceGroups/infra-dev/providers/Microsoft.Storage/storageAccounts/infradev]

Error: Error reading static website for AzureRM Storage Account "infradev": accounts.Client#GetServiceProperties: Failure responding to request: StatusCode=403 -- Original Error: autorest/azure: Service returned an error. Status=403 Code="AuthorizationPermissionMismatch" Message="This request is not authorized to perform this operation using this permission.\nRequestId:a397b17c-a01e-0091-40c1-ec2b03000000\nTime:2020-02-26T16:25:48.5825594Z"

Note: the above command was run using full administrator privileges. I'll check it it's working with a previous provider version and add the results in the comments

Steps to Reproduce

1. terraform apply

Important Factoids

References

• #0000

[DSakura207]

I've run into the same issue and got it resolved (in an unknown way).

Here are what I have done:

• Rebooted my PC

• Toggled elevated access in Azure AD ( I am global administrator).

Hope it helps.

[adrianhall]

Worth mentioning - running terraform destroy does not destroy any resources due to this error. I have to remove the resources manually.

[krezreb]

I can confirm that this works with the 1.44 provider, pinning my code for the time being

[carldjohnston]

Setting account_kind = "Storage" allowed me to create a storage account with 2.0.0, the provider defaults to account_kind = "StorageV2"

[DSakura207]

It is similar to #502. I had run into the same issue, and az account get-access-token cannot get a valid token.

Can you please try:

• Reboot your PC

• Toggled elevated access in Azure AD ( if you are a global administrator)

• Run az account get-access-token to obtain a token from Azure

  If Azure cli throws error, try to follow the instructions to refresh your Azure session.

[krezreb]

Setting account_kind = "Storage" allowed me to create a storage account with 2.0.0, the provider defaults to account_kind = "StorageV2"

I am interested in data lake v2, so I am using StorageV2 along with it

[krezreb]

It is similar to #502. I had run into the same issue, and az account get-access-token cannot get a valid token.

Can you please try:

• Reboot your PC
• Toggled elevated access in Azure AD ( if you are a global administrator)
• Run az account get-access-token to obtain a token from Azure
  If Azure cli throws error, try to follow the instructions to refresh your Azure session.

Coming from 2 years of AWS DevOps experience, I am surprised at the suggestion of rebooting my PC. Perhaps in your setup, your Az account is federated with your Windows AD Session, meaning rebooting would refresh any stale session data.

In any case, I am running Linux, my azure account has full admin access, and I am able to manually create a StorageV2 account in the web console without having to refresh my account. Additionally, as mentioned in my comment yesterday, it works with the 1.44 provider, with StorageV2 and is_hns_enabled = true

[DSakura207]

It is similar to #502. I had run into the same issue, and az account get-access-token cannot get a valid token.
Can you please try:

• Reboot your PC
• Toggled elevated access in Azure AD ( if you are a global administrator)
• Run az account get-access-token to obtain a token from Azure
  If Azure cli throws error, try to follow the instructions to refresh your Azure session.

Coming from 2 years of AWS DevOps experience, I am surprised at the suggestion of rebooting my PC. Perhaps in your setup, your Az account is federated with your Windows AD Session, meaning rebooting would refresh any stale session data.

In any case, I am running Linux, my azure account has full admin access, and I am able to manually create a StorageV2 account in the web console without having to refresh my account. Additionally, as mentioned in my comment yesterday, it works with the 1.44 provider, with StorageV2 and is_hns_enabled = true

Yep, we have SSO. When I ran into this issue, I was also able to create a StorageV2 account in Azure portal, and terraform with 1.44 provider.

Azure portal has its own session. It is in browser, not command line. My guess is Azure CLI's session and/or token(s) are in an inconsistent state.

When terraform throws error, can you get an access token by running az account get-access-token ? If not, please give it a try.

As https://github.com/terraform-providers/terraform-provider-azurerm/issues/502#issuecomment-341858561, the command will refresh tokens.

[krezreb]

I just tried doing az account get-access-token on the command line just before doing terragrunt apply, same error message in 2.0.0. No error message in 1.44

[DSakura207]

Well, I am sorry but I have no idea of what to do next. 1.44 provider does not have the issue since it never touches blob properties. In my case, it is where terraform throws error.

Besides, I am not using terragrunt. I am with terraform original CLI. I am not sure if it makes a difference.

Maybe a trace log helps.

[krezreb]

Well it's not a blocker since I've pinned my code to 1.44 and am able to continue with other modules.

Perhaps others will be impacted by this issue as 2.0.0 becomes more widely adopted, if the problem is indeed _not_ specific to my setup

[cdunford]

I have this issue as well

[shivamsriva31093]

Facing the same issue as well

[jackofallops]

Hi all,
The default value for account_kind changed in 2.0 from Storage to StorageV2 see here. If you have upgraded your provider version and are experiencing this issue with an existing storage account you should be able to resolve it by setting that property in your config for that resource:

e.g.
account_kind = "Storage"

[krezreb]

Hi all,
The default value for account_kind changed in 2.0 from Storage to StorageV2 see here. If you have upgraded your provider version and are experiencing this issue with an existing storage account you should be able to resolve it by setting that property in your config for that resource:

e.g.
account_kind = "Storage"

As mentioned in my comment https://github.com/terraform-providers/terraform-provider-azurerm/issues/5914#issuecomment-592381907
The entire point is to be able to use StorageV2. And StorageV2 in the 1.44 plugin works

[eliog]

This issue is happening to me on newly created storage accounts. Just as described in the issue description above. The storage account is created but the error message appears. The error continues to happen if I run "terraform apply" again (even though the account is already created).

I also reverted to 1.44.

[DSakura207]

I suspect the bug is from the custom blob service property client.
I tried to plan and apply in cloud shell, storage account was created, but container existence check returned 403.

Error: Error checking for existence of existing Container "logs" (Account "stresourcecloud" / Resource Group "rg-canadacentral-shared"): containers.Client#GetProperties: Failure responding to request: StatusCode=403 -- Original Error: autorest/azure: Service returned an error. Status=403 Code="AuthorizationFailure" Message="This request is not authorized to perform this operation.\nRequestId:55766cd9-701e-0009-5b0a-f32c2f000000\nTime:2020-03-05T16:21:11.0882809Z"

[hashibot[bot]]

This has been released in version 2.1.0 of the provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. As an example:

provider "azurerm" {
    version = "~> 2.1.0"
}
# ... other configuration ...

[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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!