Поделиться через

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

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

В этой статье описаны шаги по включению этого сценария, как при подключении клиента к Azure Lighthouse, так и при развертывании политики.

Совет

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

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

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

Чтобы разрешить principalId назначать роли управляемому удостоверению в клиентском окружении, задайте для параметра roleDefinitionId значение "Администратор доступа пользователей". Хотя эта роль обычно не поддерживается для Azure Lighthouse, ее можно использовать в этом конкретном сценарии. Назначьте эту роль principalId, чтобы можно было назначать определенные встроенные роли управляемым удостоверениям. Эти роли определяются в свойстве delegatedRoleDefinitionIds . Вы можете включить любую встроенную роль Azure , за исключением администратора доступа пользователей или владельца.

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

Примечание.

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

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

{
    "principalId": "00000000-0000-0000-0000-000000000000",
    "principalIdDisplayName": "Policy Automation Account",
    "roleDefinitionId": "18d7d88d-d35e-4fb5-a5c3-7773c20a72d9",
    "delegatedRoleDefinitionIds": [
         "b24988ac-6180-42a0-ab88-20f7382dd24c",
         "92aaf0da-9dab-42b6-94a3-d43ce8d16293"
    ]
}

Внедрите политики, поддающиеся исправлению

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

Например, предположим, что вы хотите включить диагностику ресурсов Azure Key Vault в клиентском tenantе, как показано в этом примере. Пользователь в клиенте управления с соответствующими разрешениями (как описано ранее) развертывает шаблон 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)]"
            }

Совет

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

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

  • Last updated on