Развертывание политики, которую можно исправить в рамках делегированной подписки

  • Статья

Azure Lighthouse позволяет поставщикам служб создавать и редактировать определения политики в рамках делегированной подписки. Для развертывания политик, использующих задачу исправления (т. е. политики с эффектом deployIfNotExists или modify), в арендаторе клиента необходимо создать управляемое удостоверение. Это управляемое удостоверение может использоваться политикой Azure для развертывания шаблона в политике. В этой статье описаны шаги, необходимые для включения этого сценария, как при подключении клиента для Azure Lighthouse, так и при развертывании самой политики.

Совет

Хотя в этом разделе мы будем упоминать поставщиков услуг и их заказчиков, предприятия, управляющие несколькими клиентами, могут использовать такие же процессы.

Создание пользователя, который может назначать роли управляемому удостоверению в клиенте клиента

При подключении клиента к Azure Lighthouse вы определяете авторизацию, которая предоставляет доступ к делегированным ресурсам в клиенте клиента. Каждая авторизация указывает субъект-идентификатор , соответствующий пользователю Microsoft Entra, группе или субъекту-службе в управляющем клиенте, а также ролиDefinitionId , соответствующей встроенной роли Azure, которая будет предоставлена.

Чтобы разрешить субъект-идентификатору назначать роли управляемому удостоверению в клиенте клиента, необходимо задать для параметра roleDefinitionId значение User Access Администратор istrator. Хотя эта роль обычно не поддерживается для Azure Lighthouse, ее можно использовать в этом конкретном сценарии. Предоставление этой роли этому субъекту-идентификатору позволяет назначать определенные встроенные роли управляемым удостоверениям. Эти роли определяются в свойстве delegatedRoleDefinitionIds и могут включать все поддерживаемые встроенные роли Azure, за исключением администратора доступа пользователей или владельца.

После подключения клиента principalId, созданный в этой авторизации, сможет назначать эти встроенные роли управляемым удостоверениям в клиенте клиента. У них не будет никаких других разрешений, обычно связанных с ролью администратора доступа пользователей.

Примечание.

Назначения ролей для клиентов в настоящее время должны выполняться через API, а не на портале Azure.

В следующем примере показан principalId, которому будет назначена роль администратора доступа пользователей. Этот пользователь будет иметь возможность назначать две встроенные роли управляемым удостоверениям в клиенте клиента: участник и участник Log Analytics.

{
    "principalId": "3kl47fff-5655-4779-b726-2cf02b05c7c4",
    "principalIdDisplayName": "Policy Automation Account",
    "roleDefinitionId": "18d7d88d-d35e-4fb5-a5c3-7773c20a72d9",
    "delegatedRoleDefinitionIds": [
         "b24988ac-6180-42a0-ab88-20f7382dd24c",
         "92aaf0da-9dab-42b6-94a3-d43ce8d16293"
    ]
}

Развертывание политик, которые можно исправить

После создания пользователя с необходимыми разрешениями, как описано выше, этот пользователь может развернуть политики, использующие задачи по исправлению в делегированных подписках клиента.

Например, предположим, что вы хотите включить диагностику для ресурсов Azure Key Vault в клиенте клиента, как показано в этом примере. Пользователь в управляющем клиенте с соответствующими разрешениями (как описано выше) развернет шаблон Azure Resource Manager, чтобы включить этот сценарий.

Создание назначения политики для использования с делегированной подпиской должно выполняться через API, а не в портал Azure. При этом для apiVersion следует задать 2019-04-01-preview или более позднюю версию, чтобы включить новое свойство delegatedManagedIdentityResourceId. Это свойство позволяет включать управляемое удостоверение, которое находится в арендаторе клиента (в подписке или группе ресурсов, подключенной к Azure Lighthouse).

В следующем примере показано назначение роли с delegatedManagedIdentityResourceId.

"type": "Microsoft.Authorization/roleAssignments",
            "apiVersion": "2019-04-01-preview",
            "name": "[parameters('rbacGuid')]",
            "dependsOn": [
                "[variables('policyAssignment')]"
            ],
            "properties": {
                "roleDefinitionId": "[concat(subscription().id, '/providers/Microsoft.Authorization/roleDefinitions/', variables('rbacContributor'))]",
                "principalType": "ServicePrincipal",
                "delegatedManagedIdentityResourceId": "[concat(subscription().id, '/providers/Microsoft.Authorization/policyAssignments/', variables('policyAssignment'))]",
                "principalId": "[toLower(reference(concat('/providers/Microsoft.Authorization/policyAssignments/', variables('policyAssignment')), '2018-05-01', 'Full' ).identity.principalId)]"
            }

Совет

Доступен аналогичный пример, демонстрирующий, как развернуть политику, которая добавляет или удаляет тег (используя эффект изменения) в делегированной подписке.

Следующие шаги