نشر نهج يمكن معالجته ضمن اشتراك مفوض
يسمح Azure Lighthouse لموفري الخدمات بإنشاء تعريفات السياسة وتحريرها ضمن اشتراك مفوض. ومع ذلك، لنشر النهج التي تستخدم مهمة معالجة (أي النهج ذات تأثير DeployIfNotExists أو التعديل )، ستحتاج إلى إنشاء هوية مدارة في مستأجر العميل. يمكن استخدام هذه الهوية المدارة بواسطة Azure Policy لنشر القالب داخل النهج. هناك خطوات مطلوبة لتمكين هذا السيناريو، سواء عند إعداد العميل ل Azure Lighthouse، أو عند نشر النهج نفسه.
تلميح
على الرغم من أننا نشير إلى مزودي الخدمات والعملاء في هذا الموضوع ، إلا أن الشركات التي تدير مستأجرين متعددين يمكنها استخدام نفس العمليات.
إنشاء مستخدم يمكنه تعيين أدوار لهوية مدارة في مستأجر العميل
عندما تقوم بإعداد عميل إلى Azure Lighthouse، فإنك تستخدم قالب Azure Resource Manager إلى جانب ملف معلمات لتحديد التفويضات التي تمنح حق الوصول إلى الموارد المفوضة في مستأجر العميل. يحدد كل تفويض معرف أساسي يتوافق مع مستخدم Azure AD أو مجموعة أو مدير خدمة في المستأجر الإداري، و roleDefinitionId يتوافق مع دور Azure المضمن الذي سيتم منحه.
للسماح ل principalId بإنشاء هوية مدارة في مستأجر العميل، يجب تعيين roleDefinitionId الخاص به إلى مسؤول وصول المستخدم. على الرغم من أن هذا الدور غير مدعوم بشكل عام، إلا أنه يمكن استخدامه في هذا السيناريو المحدد، مما يسمح لحسابات المستخدمين التي لديها هذا الإذن بتعيين دور مضمن محدد واحد أو أكثر للهويات المدارة. يتم تعريف هذه الأدوار في الخاصية delegatedRoleDefinitionIds ، ويمكن أن تتضمن أي دور مضمن في Azure مدعوم باستثناء مسؤول وصول المستخدم أو المالك.
بعد إعداد العميل، سيتمكن principalId الذي تم إنشاؤه في هذا التفويض من تعيين هذه الأدوار المضمنة للهويات المدارة في مستأجر العميل. ومع ذلك، لن يكون لديهم أي أذونات أخرى مقترنة عادة بدور مسؤول وصول المستخدم.
ملاحظة
يجب حاليا إجراء تعيينات الأدوار عبر المستأجرين من خلال واجهات برمجة التطبيقات، وليس في مدخل Azure.
يوضح المثال أدناه معرف رئيسي سيكون له دور مسؤول وصول المستخدم. سيتمكن هذا المستخدم من تعيين دورين مضمنين للهويات المدارة في مستأجر العميل: المساهم والمساهم في 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 لتمكين هذا السيناريو.
لاحظ أن إنشاء تعيين النهج لاستخدامه مع اشتراك مفوض يجب أن يتم حاليا من خلال واجهات برمجة التطبيقات، وليس في مدخل Azure. عند القيام بذلك، يجب تعيين apiVersion إلى معاينة 2019-04-01 أو إصدار أحدث لتضمين الخاصية الجديدة المفوضةManagedIdentityResourceId . تسمح لك هذه الخاصية بتضمين هوية مدارة موجودة في مستأجر العميل (في اشتراك أو مجموعة موارد تم إعدادها إلى Azure Lighthouse).
يوضح المثال التالي تعيين دور باستخدام معرف مفوض ManagedIdentityResourceId.
"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)]"
}
تلميح
تتوفر عينة مماثلة لتوضيح كيفية نشر نهج يضيف علامة أو يزيلها (باستخدام تأثير التعديل) إلى اشتراك مفوض.
الخطوات التالية
- تعرف على سياسة Azure.
- تعرف على الهويات المدارة لموارد Azure.