Wdrażanie zasad, które można skorygować w ramach subskrypcji delegowanej

  • Artykuł

Usługa Azure Lighthouse umożliwia dostawcom usług tworzenie i edytowanie definicji zasad w ramach delegowanej subskrypcji. Aby wdrożyć zasady korzystające z zadania korygowania (czyli zasad z efektem wdrażaniaIfNotExists lub modyfikowania), należy utworzyć tożsamość zarządzaną w dzierżawie klienta. Ta tożsamość zarządzana może służyć przez usługę Azure Policy do wdrażania szablonu w ramach zasad. W tym artykule opisano kroki wymagane do włączenia tego scenariusza, zarówno podczas dołączania klienta do usługi Azure Lighthouse, jak i wdrażania samych zasad.

Napiwek

Chociaż w tym temacie odwołujemy się do dostawców usług i klientów, przedsiębiorstwa zarządzające wieloma dzierżawami mogą używać tych samych procesów.

Tworzenie użytkownika, który może przypisywać role do tożsamości zarządzanej w dzierżawie klienta

Po dołączeniu klienta do usługi Azure Lighthouse należy zdefiniować autoryzacje, które udzielają dostępu do delegowanych zasobów w dzierżawie klienta. Każda autoryzacja określa identyfikator principalId odpowiadający użytkownikowi, grupie lub jednostce usługi firmy Microsoft w dzierżawie zarządzającej oraz roliDefinitionId odpowiadającej wbudowanej roli platformy Azure, która zostanie udzielona.

Aby zezwolić identyfikatorowi principalId na przypisywanie ról do tożsamości zarządzanej w dzierżawie klienta, należy ustawić jego rolęDefinitionId na Administracja istrator dostępu użytkowników. Chociaż ta rola nie jest ogólnie obsługiwana w usłudze Azure Lighthouse, może być używana w tym konkretnym scenariuszu. Przyznanie tej roli temu identyfikatorowi principalId umożliwia przypisanie określonych wbudowanych ról do tożsamości zarządzanych. Te role są definiowane we właściwości delegatedRoleDefinitionIds i mogą zawierać dowolną obsługiwaną rolę wbudowaną platformy Azure, z wyjątkiem funkcji User Access Administracja istrator lub Owner.

Po dołączeniu klienta identyfikator principalId utworzony w tej autoryzacji będzie mógł przypisać te wbudowane role do tożsamości zarządzanych w dzierżawie klienta. Nie będzie mieć żadnych innych uprawnień skojarzonych zwykle z rolą Administracja istratora dostępu użytkowników.

Uwaga

Przypisania ról między dzierżawami muszą być obecnie wykonywane za pośrednictwem interfejsów API, a nie w witrynie Azure Portal.

W poniższym przykładzie przedstawiono identyfikator principalId, który będzie miał rolę Administracja istratora dostępu użytkowników. Ten użytkownik będzie mógł przypisać dwie wbudowane role do tożsamości zarządzanych w dzierżawie klienta: Współautor i Współautor usługi 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"
    ]
}

Wdrażanie zasad, które można skorygować

Po utworzeniu użytkownika z niezbędnymi uprawnieniami zgodnie z powyższym opisem użytkownik może wdrożyć zasady korzystające z zadań korygujących w ramach delegowanych subskrypcji klienta.

Załóżmy na przykład, że chcesz włączyć diagnostykę zasobów usługi Azure Key Vault w dzierżawie klienta, jak pokazano w tym przykładzie. Użytkownik zarządzający dzierżawą z odpowiednimi uprawnieniami (zgodnie z powyższym opisem) wdroży szablon usługi Azure Resource Manager w celu włączenia tego scenariusza.

Tworzenie przypisania zasad do użycia z delegowana subskrypcją musi być obecnie wykonywane za pośrednictwem interfejsów API, a nie w witrynie Azure Portal. W tym przypadku parametr apiVersion musi być ustawiony na wartość 2019-04-01-preview lub nowszą, aby uwzględnić nową właściwość delegatedManagedIdentityResourceId. Ta właściwość umożliwia dołączenie tożsamości zarządzanej, która znajduje się w dzierżawie klienta (w subskrypcji lub grupie zasobów, która została dołączona do usługi Azure Lighthouse).

W poniższym przykładzie przedstawiono przypisanie roli z delegowanym identyfikatoremManagedIdentityResourceId.

"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)]"
            }

Napiwek

Podobny przykład jest dostępny, aby zademonstrować sposób wdrażania zasad, które dodaje lub usuwa tag (przy użyciu efektu modyfikacji) do delegowanej subskrypcji.

Następne kroki