使用Terraform部署Azure Open VPN相关项目时遭遇Storage Account AuthorizationPermissionMismatch错误求助

Overview #

I see you're diving into Azure OpenVPN configuration using a Terraform example project, and hit a frustrating 403 error when running terraform apply. Let's break down why this might be happening and walk through actionable fixes to get you back on track.

Your Error Context #

First, let's recap the key details to ensure we're aligned:

• Error: AuthorizationPermissionMismatch when reading queue properties for storage account examplehubw6sr1wyncn
• Terraform Version: 0.14.5
• AzureRM Provider Version: 2.74.0
• Permissions Attempted: Updated to include Get, List, Set for the storage account key
• Role: Azure Subscription Admin

The error specifically calls out queues.Client#GetServiceProperties—this is a critical clue about exactly what permission is missing.

Step-by-Step Solutions #

1. Ensure You Have the Exact Required Permission for Queue Service Properties #

The operation to read queue service properties requires the Microsoft.Storage/storageAccounts/queueServices/read action at the storage account level. Even with an Admin role, inherited or granular permissions might not cover this specific action.

• Go to your storage account in the Azure Portal
• Navigate to Access control (IAM) > Role assignments
• Check if your user/service principal has a role that includes this action (e.g., Storage Account Contributor is a reliable choice, or you can create a custom role with just this action if needed)
• If using a storage account access key, confirm the key has full Queue service permissions (not just the Get/List/Set you added—granular key permissions can exclude the read operation for service properties)

2. Validate Terraform Authentication Credentials #

Even with an Admin role, Terraform might be using stale or incorrect credentials. Try these quick checks:

• Run az login again and confirm you're logged into the correct subscription with az account show
• If using a service principal, verify that the client_id, client_secret, and tenant_id in your Terraform config or environment variables are accurate
• Clear your Terraform cache to rule out cached provider issues:

  rm -rf .terraform/ .terraform.lock.hcl
  terraform init
  

3. Check the Storage Account Configuration in Terraform #

Double-check the storage account resource in your Terraform code:

• Ensure account_kind is set to StorageV2 (this is required for queue service support in newer AzureRM versions)
• If the project uses a managed identity to access the storage account, confirm that identity has the necessary read permission for queue services
• Some older AzureRM provider versions require explicit configuration of the queue service—look for a azurerm_storage_queue_service resource in the code and ensure it's properly defined

4. Upgrade the AzureRM Provider (Carefully) #

You removed the provider version constraint, but v2.74.0 has known compatibility quirks with Terraform 0.14.5. Try upgrading to a stable, compatible version (v2.99.0 works well with Terraform 0.14.x):

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 2.99.0"
    }
  }
}

Run terraform init -upgrade to apply the upgrade, then re-run terraform apply.

5. Rule Out Azure Policy Restrictions #

Subscription-level Azure Policies can block even Admin users from performing certain actions. Check:

• Go to Azure Policy in the Azure Portal
• Search for policies that restrict storage account queue service operations or permission assignments
• If you have permissions, temporarily disable any relevant policies to test if that's the root cause

Debugging Next Steps #

If none of the above works, enable Terraform debug logging to get granular details about the API call:

TF_LOG=DEBUG terraform apply

This will show the exact request being sent to Azure, which can help you identify a missing permission, incorrect resource ID, or authentication issue that's not obvious from the basic error message.

内容的提问来源于stack exchange，提问作者Nayden Van