مشاركة عبر

توزيع نهج يمكن معالجته داخل اشتراك مفوض

  • مقالة

يسمح Azure Lighthouse لموفري الخدمة بإنشاء تعريفات النهج وتحريرها داخل اشتراك مفوض. لتوزيع النهج التي تستخدم مهمة معالجة (أي النهج ذات تأثير deployIfNotExists أو تعديل)، يجب إنشاء هوية مدارة في مستأجر العميل. يمكن استخدام هذه الهوية المدارة بواسطة Azure Policy لتوزيع القالب داخل النهج. توضح هذه المقالة الخطوات المطلوبة لتمكين هذا السيناريو، سواء عند إلحاق العميل ب Azure Lighthouse، وعند نشر النهج نفسه.

تلميح

رغم أننا نشير إلى موفري الخدمة والعملاء في هذا الموضوع، فإن المؤسسات التي تدير مستأجرين متعددين يمكنها استخدام نفس العمليات.

إنشاء مستخدم يمكنه تعيين أدوار إلى هوية مدارة في مستأجر العميل

عند إلحاق عميل ب Azure Lighthouse، فإنك تحدد التخويلات التي تمنح حق الوصول إلى الموارد المفوضة في مستأجر العميل. يحدد كل تخويل معرف أساسي يتوافق مع مستخدم Microsoft Entra أو مجموعة أو كيان خدمة في المستأجر الإداري، و roleDefinitionId يتوافق مع الدور المضمن في Azure الذي سيتم منحه.

للسماح لمعرف أساسي بتعيين أدوار لهوية مدارة في مستأجر العميل، يجب تعيين roleDefinitionId الخاص به إلى وصول المستخدم مسؤول istrator. في حين أن هذا الدور غير مدعوم بشكل عام ل Azure Lighthouse، يمكن استخدامه في هذا السيناريو المحدد. يسمح منح هذا الدور لهذا المعرف الأساسي بتعيين أدوار مضمنة محددة للهويات المدارة. يتم تعريف هذه الأدوار في الخاصية delegatedRoleDefinitionIds، ويمكن أن تتضمن أي دور Azure مضمن معتمد باستثناء وصول المستخدم مسؤول istrator أو المالك.

بعد إلحاق العميل، سيتمكن principalId الذي تم إنشاؤه في هذا التخويل من تعيين هذه الأدوار المضمنة للهويات المدارة في مستأجر العميل. لن يكون له أي أذونات أخرى مقترنة عادة بدور مسؤول وصول المستخدم.

إشعار

يجب إجراء تعيينات الأدوار عبر المستأجرين حاليًا من خلال واجهات برمجة التطبيقات، وليس في مدخل Azure.

يوضح المثال أدناه principalId سيكون له دور مسؤول وصول المستخدم. سيتمكن هذا المستخدم من تعيين دورين مضمنين للهويات المدارة في مستأجر العميل: Contributor وLog Analytics Contributor.

{
    "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 لتمكين هذا السيناريو.

يجب أن يتم إنشاء تعيين النهج لاستخدامه مع اشتراك مفوض حاليا من خلال واجهات برمجة التطبيقات، وليس في مدخل Microsoft 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)]"
            }

تلميح

يتوفر نموذج مماثل لتوضيح كيفية توزيع نهج يضيف علامة أو يزيلها (باستخدام تأثير التعديل) إلى اشتراك مفوض.

الخطوات التالية