如何使用Terraform从其他Azure账户的Blob创建托管磁盘及403报错解决

你碰到的LinkedAuthorizationFailed403报错，和Blob的匿名公开权限没有关系。触发报错的直接原因是你在Terraform配置里填写的source_resource_id字段——只要这个字段指向其他订阅的存储账户资源，Azure托管磁盘服务就会强制走跨订阅资源关联校验逻辑，完全绕过匿名访问通道，要求当前操作身份必须有权限访问源VHD所在的订阅，哪怕你的Blob已经完全公开可下载，也会因为跨订阅授权不匹配直接报权限错误。

• 适配现有匿名Blob场景的最简调整：
  直接把配置里的source_resource_id字段删掉，只保留公开可访问的VHD地址即可。调整后配置不会触发跨订阅校验，Azure计算服务会直接通过公开通道拉取VHD完成磁盘创建。
  调整后的正确配置示例：

  resource "azurerm_managed_disk" "MyDisk" {
    name                 = "MyDisk"
    location             = var.location
    resource_group_name  = azurerm_resource_group.rg.name
    storage_account_type = "Standard_LRS"
    create_option        = "Copy"
    source_uri           = "https://....blob.core.windows.net/images/mydisk.vhd"
    disk_size_gb         = "32"
  
    tags = {
      environment = "staging"
    }
  }
  

• 不想暴露公开Blob的正式授权方案：
  • 关闭Blob容器的匿名公开访问权限
  • 在源VHD所在的存储账户的资源范围，给当前Terraform使用的登录身份（服务主体/个人账号）分配Storage Blob Data Reader角色权限
  • 保留配置中的source_resource_id字段，让Azure走正规RBAC权限校验流程完成VHD复制
• 跨独立租户场景的处理：
  如果源VHD存在其他完全独立的Azure租户下，不需要配置source_resource_id，直接给VHD生成具备读权限的SAS签名URI，替换掉配置里的公开Blob地址即可。这种方式既不需要把Blob暴露给公网匿名访问，也不会触发跨租户的资源关联校验报错。

• 确认源VHD是固定大小格式，动态扩容的VHD无法被托管磁盘服务正常识别
• 确认VHD的实际文件大小不低于你配置的disk_size_gb值，不然Copy操作会因为磁盘容量不匹配失败
• 如果源存储账户开了网络防火墙，需要放行Azure计算服务的公共出口访问范围，不然服务拉取VHD时会被网络层拦截

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