【问题标题】:Azure ARM template ResourceNotFound error when referencing managed identity in key vault access policy在密钥保管库访问策略中引用托管标识时出现 Azure ARM 模板 ResourceNotFound 错误
【发布时间】:2019-10-06 15:22:31
【问题描述】:

在启用的逻辑应用上部署具有托管身份访问策略的 KeyVault 服务时,它会失败,因为它尚不存在。我确实为逻辑应用添加了依赖项。

奇怪的是这个模板已经工作了几个星期,现在每次都失败,所以我有点困惑。我从 MS 的快速入门模板中复制了这个。但这不是问题,因为如果您查看错误,它指向正确的目标资源。如果我在失败后单击重新部署,此模板也可以工作,因为那时托管标识已经存在。我测试了它,但它还是失败了。

这是我的 ARM 模板

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "logicAppName": {
            "type": "string",
            "minLength": 1,
            "metadata": {
                "description": "Describes the name of the Logic App resource"
            },
            "defaultValue": "demo"
        },
        "location": {
            "type": "string",
            "defaultValue": "[resourceGroup().location]",
            "metadata": {
                "description": "Specifies the Azure location where the key vault should be created."
            }
        }
    },
    "variables": {
        "keyVaultName": "[concat('eakeyvault', uniquestring(resourceGroup().id))]",
        "logicAppName": "[parameters('logicAppName')]"
    },
    "resources": [
        {
            "type": "Microsoft.KeyVault/vaults",
            "name": "[variables('keyVaultName')]",
            "apiVersion": "2018-02-14",
            "location": "[parameters('location')]",
            "dependsOn": [
                "[resourceId('Microsoft.Logic/workflows', variables('logicAppName'))]"
            ],
            "properties": {
                "enabledForDeployment": false,
                "enabledForDiskEncryption": false,
                "enabledForTemplateDeployment": false,
                "tenantId": "[subscription().tenantId]",
                "accessPolicies": [
                    {
                        "objectId": "[reference(concat(resourceId('Microsoft.Logic/workflows/', variables('logicAppName')), '/providers/Microsoft.ManagedIdentity/Identities/default'), '2018-11-30').principalId]",
                        "tenantId": "[subscription().tenantId]",
                        "permissions": {
                            "secrets": ["get"]
                        }
                    }
                ],
                "sku": {
                    "name": "standard",
                    "family": "A"
                },
                "networkAcls": {
                    "value": {
                        "defaultAction": "Allow",
                        "bypass": "AzureServices"
                    }
                }
            }
        },
        {
            "type": "Microsoft.Logic/workflows",
            "apiVersion": "2017-07-01",
            "name": "[variables('logicAppName')]",
            "location": "[resourceGroup().location]",
            "identity": {
                "type": "SystemAssigned"
            },
            "properties": {
                "state": "Disabled",
                "definition": {
                    "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
                    "actions": {

                    },
                    "contentVersion": "1.0.0.0",
                    "outputs": {},
                    "parameters": {
                        "$connections": {
                            "defaultValue": {},
                            "type": "Object"
                        }
                    },
                    "triggers": {
                        "Recurrence": {
                            "recurrence": {
                                "frequency": "Day",
                                "interval": 1,
                                "schedule": {
                                    "hours": [
                                        "3"
                                    ]
                                }
                            },
                            "type": "Recurrence"
                        }
                    }
                },
                "parameters": {

                }
            }
        }
    ]
}

还有错误

{
   "id":"/subscriptions/x/resourceGroups/demo6/providers/Microsoft.Resources/deployments/Microsoft.Template/operations/272BE07B42936635",
   "operationId":"272BE07B42936635",
   "properties":{
      "provisioningOperation":"Read",
      "provisioningState":"Failed",
      "timestamp":"2019-10-06T15:09:38.8112774Z",
      "duration":"PT1.3818083S",
      "trackingId":"faf54706-3f6f-469a-9917-a65bdba9768f",
      "statusCode":"NotFound",
      "statusMessage":{
         "error":{
            "code":"ResourceNotFound",
            "message":"The Resource 'Microsoft.Logic/workflows/demo' under resource group 'demo6' was not found."
         }
      },
      "targetResource":{
         "id":"/subscriptions/x/resourceGroups/demo6/providers/Microsoft.Logic/workflows/demo/providers/Microsoft.ManagedIdentity/Identities/default",
         "resourceType":"Microsoft.ManagedIdentity/Identities",
         "resourceName":"default",
         "apiVersion":"2018-11-30"
      }
   }
}

【问题讨论】:

    标签: azure azure-resource-manager arm-template azure-managed-identity


    【解决方案1】:

    我已将此作为应用服务的参考:

    [reference(resourceId('Microsoft.Web/sites', variables('webAppName')), '2016-08-01', 'Full').identity.principalId]
    

    当然还有依赖:

    [resourceId('Microsoft.Web/sites', variables('webAppName'))]
    

    【讨论】:

    • 这实际上可能有效,似乎对身份提供者的引用无法正常工作。此外,在使用引用函数时,您不需要 dependsOn。它的多余
    • 是的,应该没有必要。我刚刚发现了一些不是多余的情况,没有它就会出现问题:(
    • 你有什么例子吗?我从来没有见过这样的事情。不是刻薄,只是对这些情况感兴趣
    • Nope :\ 那是很久以前的事了,我已经完成了dependsOn解决方法
    • 不幸的是,我正在使用逻辑应用程序,但我确实使用了与您完全相同的逻辑。对逻辑应用主体的引用并取决于逻辑应用。也许这只是 Azure 错误?
    【解决方案2】:

    您的 resourceId() 函数中有错字:

    reference(concat(resourceId('Microsoft.Logic/workflows', variables('logicAppName')), '/providers/Microsoft.ManagedIdentity/Identities/default'), '2018-11-30').principalId
    

    注意workflows 后面的额外/

    【讨论】:

    • 没错,我是从 MS 的快速入门模板中复制的。但这不是问题,因为如果您查看错误,它指向正确的目标资源。如果我在失败后单击重新部署,此模板也可以工作,因为那时托管标识已经存在。我测试了它,但它还是失败了;(
    • 现在我想知道为什么您认为不在问题中指定所有这些是个好主意?经过一番摸索,这看起来像是一个错误,tbh。您很可能可以使用嵌套部署来解决问题
    • 是的,这是重要的信息。我会将其添加到原始问题中。这不是故意的,我只是在写作时忘记添加它。
    【解决方案3】:

    这是一个理论,但请尝试使用额外的 dependsOn 更新您的访问策略:

    "dependsOn:" [
    "[resourceId('Microsoft.Logic/workflows', variables('logicAppName'))]"
    ]
    

    access policy components 的想法与实际的 Key Vault 创建不同。

    两个平面都使用 Azure Active Directory (Azure AD) 进行身份验证。 对于授权,管理平面使用基于角色的访问控制 (RBAC) 和数据平面使用 Key Vault 访问策略

    这对于错误是有道理的,因为如果尚未创建工作流,则无法分配访问策略。

    【讨论】:

      【解决方案4】:

      我想补充的非常重要的一点是这里的官方文档中所述:

      https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/error-not-found#solution-1---set-dependencies

      引用函数和 list* 函数创建对所引用资源的隐式依赖,当该资源部署在同一模板中并通过其名称(而非资源 ID)进行引用时

      我遇到的问题是我用这样的资源 ID 声明“dependsOn”:

      "dependsOn": [
                      "[resourceId('Microsoft.Web/sites', parameters('serv_webjobs_as_name'))]"
                  ],
      

      这仍然导致创建失败并让创建过程忽略我的依赖。 但是,当我将依赖项放在“名称”而不是 ID 上时,它就开始起作用了:

      "dependsOn": [
                      "[parameters('serv_webjobs_as_name')]"
                  ],
      

      【讨论】:

      • 文档还说,如果你有隐式依赖,你不应该添加dependsOn。我知道这里的原始问题有它,这是错误的,但在这种情况下与问题无关。 “使用引用函数并传入资源名称来设置需要共享属性的资源之间的隐式依赖关系。当您已经定义了隐式依赖关系时,不要添加显式的dependsOn元素。这种方法可以降低风险不必要的依赖。”
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2020-12-28
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多