hashicorp / terraform-provider-azurerm

Terraform provider for Azure Resource Manager
https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs
Mozilla Public License 2.0
4.53k stars 4.61k forks source link

AuthorizationPermissionMismatch when creating a storage account in 2.0.0 #5914

Closed krezreb closed 4 years ago

krezreb commented 4 years ago

Community Note

Terraform (and AzureRM Provider) Version

terraform v0.12.21 AzureRM Provider Version 2.0.0

Affected Resource(s)

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

DSakura207 commented 4 years ago

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

Here are what I have done:

Hope it helps.

adrianhall commented 4 years ago

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

krezreb commented 4 years ago

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

carldjohnston commented 4 years ago

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

DSakura207 commented 4 years ago

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:

krezreb commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

I have this issue as well

shivamsriva31093 commented 4 years ago

Facing the same issue as well

jackofallops commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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"
ghost commented 4 years ago

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 ...
ghost commented 4 years ago

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 👉 hashibot-feedback@hashicorp.com. Thanks!