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

AuthorizationPermissionMismatch when creating a storage account in 2.0.0 #5914

Closed
krezreb opened this issue Feb 26, 2020 · 19 comments · Fixed by #6050
Closed

AuthorizationPermissionMismatch when creating a storage account in 2.0.0 #5914

krezreb opened this issue Feb 26, 2020 · 19 comments · Fixed by #6050
Assignees
Milestone

Comments

@krezreb
Copy link

krezreb commented Feb 26, 2020

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
Copy link
Contributor

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
Copy link

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

@krezreb
Copy link
Author

krezreb commented Feb 27, 2020

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

@krezreb krezreb changed the title AuthorizationPermissionMismatch when creating a storage account AuthorizationPermissionMismatch when creating a storage account in 2.0.0 Feb 27, 2020
@carldjohnston
Copy link

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

@DSakura207
Copy link
Contributor

DSakura207 commented Feb 28, 2020

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
Copy link
Author

krezreb commented Feb 28, 2020

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
Copy link
Author

krezreb commented Feb 28, 2020

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
Copy link
Contributor

DSakura207 commented Feb 28, 2020

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 #502 (comment), the command will refresh tokens.

@krezreb
Copy link
Author

krezreb commented Feb 28, 2020

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
Copy link
Contributor

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
Copy link
Author

krezreb commented Feb 28, 2020

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
Copy link

cdunford commented Mar 1, 2020

I have this issue as well

@shivamsriva31093
Copy link

Facing the same issue as well

@jackofallops
Copy link
Member

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"

@jackofallops jackofallops removed the bug label Mar 4, 2020
@krezreb
Copy link
Author

krezreb commented Mar 4, 2020

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 #5914 (comment)
The entire point is to be able to use StorageV2. And StorageV2 in the 1.44 plugin works

@eliog
Copy link

eliog commented Mar 4, 2020

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
Copy link
Contributor

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"

@tombuildsstuff tombuildsstuff self-assigned this Mar 9, 2020
@tombuildsstuff tombuildsstuff added this to the v2.1.0 milestone Mar 9, 2020
tombuildsstuff added a commit that referenced this issue Mar 10, 2020
This allows us to use SharedKey as an authorizer when AzureAD is not enabled
which is the case for the majority of users.

Fixes #6028
Fixes #5914
@ghost
Copy link

ghost commented Mar 11, 2020

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
Copy link

ghost commented Apr 10, 2020

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!

@ghost ghost locked and limited conversation to collaborators Apr 10, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.