فهم تأثيرات نهج Azure

كل تعريف نهج في نهج Azure له تأثير واحد. يحدد هذا التأثير ما يحدث عند تقييم قاعدة السياسة لمطابقتها. تتصرف التأثيرات بشكل مختلف إذا كانت لمورد جديد أو مورد محدث أو مورد موجود.

وهذه الآثار مدعومة حاليا في تعريف للسياسة:

يتم إهمال التأثيرات التالية:

هام

بدلا من تأثيرات EnforceOPAConstraint أو EnforceRegoPolicy ، استخدم التدقيقوالرفض باستخدام وضع Microsoft.Kubernetes.Dataموفر الموارد . تم تحديث تعريفات السياسة المضمنة. عند تعديل تعيينات النهج الموجودة لتعريفات النهج المضمنة هذه، يجب تغيير معلمة التأثير إلى قيمة في القائمة allowedValues المحدثة.

ترتيب التقييم

يتم تقييم طلبات إنشاء مورد أو تحديثه بواسطة نهج Azure أولا. ينشئ Azure Policy قائمة بكافة المهام التي تنطبق على المورد ثم يقوم بتقييم المورد مقابل كل تعريف. بالنسبة لوضع Resource Manager، يعالج Azure Policy العديد من التأثيرات قبل تسليم الطلب إلى موفر الموارد المناسب. يمنع هذا الترتيب المعالجة غير الضرورية بواسطة موفر الموارد عندما لا يفي المورد بعناصر التحكم في الحوكمة المصممة لنهج Azure. باستخدام وضع موفر الموارد، يدير موفر الموارد التقييم والنتائج ويبلغ عن النتائج مرة أخرى إلى نهج Azure.

  • يتم التحقق من التعطيل أولا لتحديد ما إذا كان يجب تقييم قاعدة النهج أم لا.
  • ثم يتم تقييم الإلحاق والتعديل. وبما أن أي منهما يمكن أن يغير الطلب، فإن التغيير الذي يتم إجراؤه قد يمنع مراجعة الحسابات أو ينكر التأثير من التسبب. تتوفر هذه التأثيرات فقط مع وضع إدارة الموارد.
  • ثم يتم تقييم الرفض. بتقييم الرفض قبل التدقيق، يتم منع تسجيل مزدوج لمورد غير مرغوب فيه.
  • يتم تقييم التدقيق أخيرا.

بعد أن يقوم موفر الموارد بإرجاع رمز نجاح على طلب وضع Resource Manager، يقوم AuditIfNotExists وDeployIfNotExists بالتقييم لتحديد ما إذا كان تسجيل الامتثال الإضافي أو الإجراء مطلوبا.

بالإضافة إلى ذلك، PATCH تقيد الطلبات التي تعدل tags الحقول ذات الصلة فقط تقييم النهج على النهج التي تحتوي على شروط تفحص الحقول tags ذات الصلة.

إلحاق

يستخدم الإلحاق لإضافة حقول إضافية إلى المورد المطلوب أثناء الإنشاء أو التحديث. مثال شائع هو تحديد عناوين IP المسموح بها لمورد تخزين.

هام

الإلحاق مخصص للاستخدام مع الخصائص التي لا تحتوي على علامة. على الرغم من أن الإلحاق يمكن أن يضيف علامات إلى مورد أثناء طلب إنشاء أو تحديث، فمن المستحسن استخدام تأثير تعديل العلامات بدلا من ذلك.

إلحاق التقييم

يتم إجراء تقييمات الإلحاق قبل معالجة الطلب من قبل موفر الموارد أثناء إنشاء مورد أو تحديثه. يضيف إلحاق حقول إلى المورد عند استيفاء شرط if لقاعدة النهج. إذا كان تأثير الإلحاق سيتجاوز قيمة في الطلب الأصلي بقيمة مختلفة، فإنه يعمل كأثر رفض ويرفض الطلب. لإلحاق قيمة جديدة بصفيف موجود، استخدم الإصدار [*] من الاسم المستعار.

عندما يتم تشغيل تعريف نهج باستخدام تأثير الإلحاق كجزء من دورة تقييم، فإنه لا يجري تغييرات على الموارد الموجودة بالفعل. بدلا من ذلك، فإنه يضع علامة على أي مورد يفي بشرط if على أنه غير متوافق.

إلحاق الخصائص

يحتوي تأثير الإلحاق فقط على صفيف تفاصيل ، وهو مطلوب. نظرا لأن التفاصيل عبارة عن صفيف ، فقد يستغرق الأمر إما زوجا واحدا من الحقول / القيم أو مضاعفات. ارجع إلى بنية التعريف لقائمة الحقول المقبولة.

إلحاق أمثلة

مثال 1: زوج حقل/قيمة واحد باستخدام اسم مستعار غير [*] مع قيمة صفيف لتعيين قواعد IP على حساب تخزين. عندما يكون الاسم المستعار غير [*] عبارة عن صفيف، يقوم التأثير بإلحاق القيمة بالمصفوفة بأكملها. إذا كان الصفيف موجودا بالفعل، يحدث حدث رفض من التعارض.

"then": {
    "effect": "append",
    "details": [{
        "field": "Microsoft.Storage/storageAccounts/networkAcls.ipRules",
        "value": [{
            "action": "Allow",
            "value": "134.5.0.0/21"
        }]
    }]
}

مثال 2: زوج حقل/قيمة واحد باستخدام اسم مستعار[*] مع قيمة صفيف لتعيين قواعد IP على حساب تخزين. باستخدام الاسم المستعار [*] ، يقوم التأثير بإلحاق القيمة بصفيف يحتمل أن يكون موجودا مسبقا. إذا لم يكن الصفيف موجودا بعد، إنشاؤه.

"then": {
    "effect": "append",
    "details": [{
        "field": "Microsoft.Storage/storageAccounts/networkAcls.ipRules[*]",
        "value": {
            "value": "40.40.40.40",
            "action": "Allow"
        }
    }]
}

تدقيق

يستخدم التدقيق لإنشاء حدث تحذير في سجل النشاط عند تقييم مورد غير متوافق، ولكنه لا يوقف الطلب.

تقييم مراجعة الحسابات

التدقيق هو التأثير الأخير الذي تم التحقق منه بواسطة Azure Policy أثناء إنشاء مورد أو تحديثه. بالنسبة لوضع Resource Manager، يقوم Azure Policy بعد ذلك بإرسال المورد إلى موفر الموارد. عند تقييم طلب إنشاء مورد أو تحديثه، يضيف Microsoft.Authorization/policies/audit/action Azure Policy عملية إلى سجل النشاط ويضع علامة على المورد على أنه غير متوافق. أثناء دورة تقييم الامتثال القياسية، يتم تحديث حالة الامتثال على المورد فقط.

خصائص التدقيق

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

بالنسبة لوضع "موفر الموارد" ، يكون لتأثير Microsoft.Kubernetes.Dataالتدقيق الخصائص الفرعية الإضافية التالية للتفاصيل. مطلوب استخدام لتعريفات السياسة الجديدة أو المحدثة templateInfo كما constraintTemplate هو مهمل.

  • قالبمعلومات (مطلوب)
    • لا يمكن استخدامها مع constraintTemplate.
    • نوع المصدر (مطلوب)
      • يحدد نوع المصدر لقالب القيد. القيم المسموح بها: PublicURL أو Base64Encoded.

      • إذا كان عنوان URL العام، مقترنا بخاصية url لتوفير موقع قالب القيد. يجب أن يكون الموقع متاحا للجمهور.

        تحذير

        لا تستخدم عناوين SAS URI أو الرموز المميزة في url أو أي شيء آخر يمكن أن يفضح سرا.

      • إذا تم ترميز Base64، مقترنا بخاصية content لتوفير قالب القيد المشفر الأساسي 64. راجع إنشاء تعريف نهج من قالب قيد لإنشاء تعريف مخصص من قالب قيد GateKeeper v3 موجود في عامل النهج المفتوح (OPA).

  • القيد (مهمل)
    • لا يمكن استخدامها مع templateInfo.
    • تنفيذ CRD لقالب القيد. يستخدم المعلمات التي تم تمريرها عبر القيم ك {{ .Values.<valuename> }}. في المثال 2 أدناه ، هذه القيم هي {{ .Values.excludedNamespaces }} و {{ .Values.allowedContainerImagesRegex }}.
  • مساحات الأسماء (اختياري)
    • مجموعة من مساحات أسماء Kubernetes للحد من تقييم السياسة إلى.
    • تؤدي القيمة الفارغة أو المفقودة إلى تضمين تقييم النهج كافة مساحات الأسماء، باستثناء تلك المعرفة في مساحات الأسماء المستبعدة.
  • مساحات الأسماء المستثناة (مطلوب)
  • labelSelector (مطلوب)
    • كائن يتضمن خصائص matchLabels (كائن) و matchExpression (صفيف) للسماح بتحديد موارد Kubernetes التي يجب تضمينها لتقييم النهج الذي يطابق التسميات والمحددات المتوفرة.
    • تؤدي القيمة الفارغة أو المفقودة إلى تضمين تقييم النهج لجميع التسميات والمحددات، باستثناء مساحات الأسماء المعرفة في مساحات الأسماء المستبعدة.
  • apiGroups (مطلوب عند استخدام templateInfo)
  • الأنواع (مطلوبة عند استخدام templateInfo)
    • صفيف يتضمن نوع كائن Kubernetes لقصر التقييم عليه.
    • تعريف ["*"]الأنواع غير مسموح به.
  • القيم (اختياري)
    • يحدد أي معلمات وقيم لتمريرها إلى القيد. يجب أن توجد كل قيمة في قالب القيد CRD.
  • constraintTemplate (مهمل)
    • لا يمكن استخدامها مع templateInfo.
    • يجب استبداله عند templateInfo إنشاء تعريف سياسة أو تحديثه.
    • قالب القيد CustomResourceDefinition (CRD) الذي يعرف القيود الجديدة. يحدد القالب منطق Rego ومخطط القيد ومعلمات القيد التي يتم تمريرها عبر قيم من Azure Policy.

مثال على مراجعة الحسابات

مثال 1: استخدام تأثير التدقيق لأوضاع Resource Manager.

"then": {
    "effect": "audit"
}

مثال 2: استخدام تأثير التدقيق لوضع موفر الموارد .Microsoft.Kubernetes.Data تعلن المعلومات الإضافية الواردة في details.templateInfo عن استخدام PublicURL وتعين url إلى موقع قالب القيد لاستخدامه في Kubernetes للحد من صور الحاوية المسموح بها.

"then": {
    "effect": "audit",
    "details": {
        "templateInfo": {
            "sourceType": "PublicURL",
            "url": "https://store.policy.core.windows.net/kubernetes/container-allowed-images/v1/template.yaml",
        },
        "values": {
            "imageRegex": "[parameters('allowedContainerImagesRegex')]"
        },
        "apiGroups": [""],
        "kinds": ["Pod"]
    }
}

AuditIfNotExists

يتيح AuditIfNotExists تدقيق الموارد المتعلقة بالمورد الذي يطابق الشرط if ، ولكن ليس لديك الخصائص المحددة في تفاصيل الشرط التالي .

تقييم AuditIfNotExists

يتم تشغيل AuditIfNotExists بعد أن يعالج موفر الموارد طلب إنشاء مورد أو تحديثه وإرجاع رمز حالة نجاح. يحدث التدقيق إذا لم تكن هناك موارد ذات صلة أو إذا لم يتم تقييم الموارد المحددة بواسطة ExistenceCondition إلى true. بالنسبة للموارد الجديدة والمحدثة، يضيف Microsoft.Authorization/policies/audit/action Azure Policy عملية إلى سجل النشاط ويضع علامة على المورد على أنه غير متوافق. عند تشغيله، يكون المورد الذي استوفى الشرط if هو المورد الذي تم وضع علامة عليه على أنه غير متوافق.

خصائص AuditIfNotExists

تحتوي خاصية التفاصيل الخاصة بتأثيرات AuditIfNotExists على كافة الخصائص الفرعية التي تحدد الموارد ذات الصلة لمطابقتها.

  • النوع (مطلوب)
    • يحدد نوع المورد ذي الصلة المراد مطابقته.
    • إذا كان النوع هو نوع مورد أسفل مورد if condition، فإن النهج يستفسر عن موارد من هذا النوع ضمن نطاق المورد الذي تم تقييمه. وإلا، فإن استعلامات النهج داخل نفس مجموعة الموارد أو الاشتراك مثل المورد الذي تم تقييمه اعتمادا على الوجودنطاق.
  • الاسم (اختياري)
    • يحدد الاسم الدقيق للمورد المراد مطابقته ويتسبب في جلب النهج موردا معينا بدلا من كافة الموارد من النوع المحدد.
    • عندما تتطابق قيم الشرط ل if.field.type و then.details.type ، يصبح الاسممطلوبا ويجب أن يكون [field('name')]، أو [field('fullName')] لمورد تابع. ومع ذلك ، ينبغي النظر في تأثير مراجعة الحسابات بدلا من ذلك.
  • اسم مجموعة الموارد (اختياري)
    • يسمح بمطابقة المورد ذي الصلة من مجموعة موارد مختلفة.
    • لا ينطبق إذا كان النوع موردا سيكون أسفل مورد الشرط if .
    • الافتراضي هو مجموعة موارد مورد الشرط if .
  • ExistScope (اختياري)
    • القيم المسموح بها هي الاشتراك ومجموعة الموارد.
    • يضبط نطاق مكان جلب المورد ذي الصلة لمطابقته.
    • لا ينطبق إذا كان النوع موردا سيكون أسفل مورد الشرط if .
    • بالنسبة إلى ResourceGroup، سيقتصر على مجموعة موارد مورد الشرط if أو مجموعة الموارد المحددة في ResourceGroupName.
    • بالنسبة للاشتراك، يمكنك الاستعلام عن الاشتراك بالكامل للمورد ذي الصلة. يجب تعيين نطاق التعيين عند الاشتراك أو أعلى للتقييم المناسب.
    • الافتراضي هو ResourceGroup.
  • تأخير التقييم (اختياري)
    • يحدد متى ينبغي تقييم وجود الموارد ذات الصلة. يتم استخدام التأخير فقط للتقييمات التي تكون نتيجة لطلب إنشاء مورد أو تحديثه.
    • القيم المسموح بها هي AfterProvisioning، ، AfterProvisioningFailureAfterProvisioningSuccessأو مدة ISO 8601 بين 0 و 360 دقيقة.
    • تقوم قيم AfterProvisioning بفحص نتيجة التوفير للمورد الذي تم تقييمه في حالة IF الخاصة بقاعدة النهج. AfterProvisioning يعمل بعد اكتمال التوفير، بغض النظر عن النتيجة. إذا استغرق توفير الحسابات أكثر من 6 ساعات، التعامل معه على أنه فشل عند تحديد تأخيرات تقييم ما بعد التوفير .
    • الافتراضي هو PT10M (10 دقائق).
    • قد يؤدي تحديد تأخير طويل في التقييم إلى عدم تحديث حالة الامتثال المسجلة للمورد حتى يتم تشغيل التقييم التالي.
  • الوجودشرط (اختياري)
    • إذا لم يتم تحديده، فإن أي مورد ذي صلة من النوع يفي بالتأثير ولا يؤدي إلى تشغيل التدقيق.
    • يستخدم نفس لغة قاعدة النهج لشرط if ، ولكن يتم تقييمه مقابل كل مورد ذي صلة على حدة.
    • إذا تم تقييم أي مورد ذي صلة مطابق إلى true، فإن التأثير يكون راضيا ولا يؤدي إلى تشغيل التدقيق.
    • يمكن استخدام [field()] للتحقق من التكافؤ مع القيم في حالة if .
    • على سبيل المثال، يمكن استخدامها للتحقق من أن المورد الأصل (في حالة if ) موجود في نفس موقع المورد مثل المورد ذي الصلة المطابق.

مثال على AuditIfNotExists

مثال: تقييم الأجهزة الظاهرية لتحديد ما إذا كانت إضافة مكافحة البرامج الضارة موجودة أم لا، ثم التدقيق عند فقدانها.

{
    "if": {
        "field": "type",
        "equals": "Microsoft.Compute/virtualMachines"
    },
    "then": {
        "effect": "auditIfNotExists",
        "details": {
            "type": "Microsoft.Compute/virtualMachines/extensions",
            "existenceCondition": {
                "allOf": [{
                        "field": "Microsoft.Compute/virtualMachines/extensions/publisher",
                        "equals": "Microsoft.Azure.Security"
                    },
                    {
                        "field": "Microsoft.Compute/virtualMachines/extensions/type",
                        "equals": "IaaSAntimalware"
                    }
                ]
            }
        }
    }
}

رفض

يستخدم الرفض لمنع طلب مورد لا يتطابق مع المعايير المحددة من خلال تعريف نهج ويفشل الطلب.

رفض التقييم

عند إنشاء مورد مطابق أو تحديثه في وضع Resource Manager، يمنع الرفض الطلب قبل إرساله إلى موفر الموارد. يتم إرجاع الطلب ك 403 (Forbidden). في البوابة الإلكترونية، يمكن عرض "محظور" كحالة على النشر الذي تم منعه بواسطة تعيين النهج. بالنسبة لوضع موفر الموارد، يدير موفر الموارد تقييم المورد.

أثناء تقييم الموارد الموجودة، يتم وضع علامة على الموارد التي تتطابق مع تعريف سياسة الرفض على أنها غير متوافقة.

رفض الخصائص

بالنسبة لوضع Resource Manager، لا يحتوي تأثير الرفض على أي خصائص إضافية للاستخدام في الشرط التالي لتعريف النهج.

بالنسبة لوضع Microsoft.Kubernetes.Data"موفر الموارد" ، يحتوي تأثير الرفض على الخصائص الفرعية الإضافية التالية للتفاصيل. مطلوب استخدام لتعريفات السياسة الجديدة أو المحدثة templateInfo كما constraintTemplate هو مهمل.

  • قالبمعلومات (مطلوب)
    • لا يمكن استخدامها مع constraintTemplate.
    • نوع المصدر (مطلوب)
      • يحدد نوع المصدر لقالب القيد. القيم المسموح بها: PublicURL أو Base64Encoded.

      • إذا كان عنوان URL العام، مقترنا بخاصية url لتوفير موقع قالب القيد. يجب أن يكون الموقع متاحا للجمهور.

        تحذير

        لا تستخدم عناوين SAS URI أو الرموز المميزة في url أو أي شيء آخر يمكن أن يفضح سرا.

      • إذا تم ترميز Base64، مقترنا بخاصية content لتوفير قالب القيد المشفر الأساسي 64. راجع إنشاء تعريف نهج من قالب قيد لإنشاء تعريف مخصص من قالب قيد GateKeeper v3 موجود في عامل النهج المفتوح (OPA).

  • القيد (اختياري)
    • لا يمكن استخدامها مع templateInfo.
    • تنفيذ CRD لقالب القيد. يستخدم المعلمات التي تم تمريرها عبر القيم ك {{ .Values.<valuename> }}. في المثال 2 أدناه ، هذه القيم هي {{ .Values.excludedNamespaces }} و {{ .Values.allowedContainerImagesRegex }}.
  • مساحات الأسماء (اختياري)
    • مجموعة من مساحات أسماء Kubernetes للحد من تقييم السياسة إلى.
    • تؤدي القيمة الفارغة أو المفقودة إلى تضمين تقييم النهج كافة مساحات الأسماء، باستثناء تلك المعرفة في مساحات الأسماء المستبعدة.
  • مساحات الأسماء المستثناة (مطلوب)
  • labelSelector (مطلوب)
    • كائن يتضمن خصائص matchLabels (كائن) و matchExpression (صفيف) للسماح بتحديد موارد Kubernetes التي يجب تضمينها لتقييم النهج الذي يطابق التسميات والمحددات المتوفرة.
    • تؤدي القيمة الفارغة أو المفقودة إلى تضمين تقييم النهج لجميع التسميات والمحددات، باستثناء مساحات الأسماء المعرفة في مساحات الأسماء المستبعدة.
  • apiGroups (مطلوب عند استخدام templateInfo)
  • الأنواع (مطلوبة عند استخدام templateInfo)
    • صفيف يتضمن نوع كائن Kubernetes لقصر التقييم عليه.
    • تعريف ["*"]الأنواع غير مسموح به.
  • القيم (اختياري)
    • يحدد أي معلمات وقيم لتمريرها إلى القيد. يجب أن توجد كل قيمة في قالب القيد CRD.
  • constraintTemplate (مهمل)
    • لا يمكن استخدامها مع templateInfo.
    • يجب استبداله عند templateInfo إنشاء تعريف سياسة أو تحديثه.
    • قالب القيد CustomResourceDefinition (CRD) الذي يعرف القيود الجديدة. يحدد القالب منطق Rego ومخطط القيد ومعلمات القيد التي يتم تمريرها عبر قيم من Azure Policy. يوصى باستخدام الأحدث templateInfo لاستبدال constraintTemplate.

مثال على الرفض

مثال 1: استخدام تأثير الرفض لأوضاع Resource Manager.

"then": {
    "effect": "deny"
}

مثال 2: استخدام تأثير الرفض لوضع موفر الموارد .Microsoft.Kubernetes.Data تعلن المعلومات الإضافية الواردة في details.templateInfo عن استخدام PublicURL وتعين url إلى موقع قالب القيد لاستخدامه في Kubernetes للحد من صور الحاوية المسموح بها.

"then": {
    "effect": "deny",
    "details": {
        "templateInfo": {
            "sourceType": "PublicURL",
            "url": "https://store.policy.core.windows.net/kubernetes/container-allowed-images/v1/template.yaml",
        },
        "values": {
            "imageRegex": "[parameters('allowedContainerImagesRegex')]"
        },
        "apiGroups": [""],
        "kinds": ["Pod"]
    }
}

DeployIfNotExists

على غرار AuditIfNotExists، يقوم تعريف نهج DeployIfNotExists بتنفيذ نشر قالب عند استيفاء الشرط. تتطلب تعيينات النهج التي تم تعيينها كDeployIfNotExists هوية مدارة لإجراء المعالجة.

ملاحظة

يتم دعم القوالب المتداخلة مع deployIfNotExists، ولكن القوالب المرتبطة غير معتمدة حاليا.

تقييم DeployIfNotExists

يتم تشغيل DeployIfNotExists بعد تأخير قابل للتكوين عندما يعالج موفر الموارد طلب إنشاء أو تحديث اشتراك أو مورد وإرجاع رمز حالة نجاح. يحدث نشر قالب إذا لم تكن هناك موارد ذات صلة أو إذا لم يتم تقييم الموارد المحددة بواسطة ExistenceCondition إلى true. تعتمد مدة النشر على مدى تعقيد الموارد المضمنة في القالب.

أثناء دورة التقييم، تؤثر تعريفات السياسة ذات التأثير DeployIfNotExists على أن الموارد المطابقة يتم تمييزها على أنها غير متوافقة، ولكن لا يتم اتخاذ أي إجراء بشأن هذا المورد. يمكن معالجة الموارد الحالية غير المتوافقة من خلال مهمة معالجة.

خصائص DeployIfNotExists

تحتوي خاصية التفاصيل الخاصة بتأثير DeployIfNotExists على كافة الخصائص الفرعية التي تحدد الموارد ذات الصلة للمطابقة ونشر القالب المراد تنفيذه.

  • النوع (مطلوب)

    • يحدد نوع المورد ذي الصلة المراد مطابقته.
    • إذا كان النوع هو نوع مورد أسفل مورد if condition، فإن النهج يستفسر عن موارد من هذا النوع ضمن نطاق المورد الذي تم تقييمه. وإلا، فإن استعلامات النهج داخل نفس مجموعة الموارد أو الاشتراك مثل المورد الذي تم تقييمه اعتمادا على الوجودنطاق.
  • الاسم (اختياري)

    • يحدد الاسم الدقيق للمورد المراد مطابقته ويتسبب في جلب النهج موردا معينا بدلا من كافة الموارد من النوع المحدد.
    • عندما تتطابق قيم الشرط ل if.field.type و then.details.type ، يصبح الاسممطلوبا ويجب أن يكون [field('name')]، أو [field('fullName')] لمورد تابع.
  • اسم مجموعة الموارد (اختياري)

    • يسمح بمطابقة المورد ذي الصلة من مجموعة موارد مختلفة.
    • لا ينطبق إذا كان النوع موردا سيكون أسفل مورد الشرط if .
    • الافتراضي هو مجموعة موارد مورد الشرط if .
    • إذا تم تنفيذ نشر قالب، نشره في مجموعة الموارد بهذه القيمة.
  • ExistScope (اختياري)

    • القيم المسموح بها هي الاشتراك ومجموعة الموارد.
    • يضبط نطاق مكان جلب المورد ذي الصلة لمطابقته.
    • لا ينطبق إذا كان النوع موردا سيكون أسفل مورد الشرط if .
    • بالنسبة إلى ResourceGroup، سيقتصر على مجموعة موارد مورد الشرط if أو مجموعة الموارد المحددة في ResourceGroupName.
    • بالنسبة للاشتراك، يمكنك الاستعلام عن الاشتراك بالكامل للمورد ذي الصلة. يجب تعيين نطاق التعيين عند الاشتراك أو أعلى للتقييم المناسب.
    • الافتراضي هو ResourceGroup.
  • تأخير التقييم (اختياري)

    • يحدد متى ينبغي تقييم وجود الموارد ذات الصلة. يتم استخدام التأخير فقط للتقييمات التي تكون نتيجة لطلب إنشاء مورد أو تحديثه.
    • القيم المسموح بها هي AfterProvisioning، ، AfterProvisioningFailureAfterProvisioningSuccessأو مدة ISO 8601 بين 0 و 360 دقيقة.
    • تقوم قيم AfterProvisioning بفحص نتيجة التوفير للمورد الذي تم تقييمه في حالة IF الخاصة بقاعدة النهج. AfterProvisioning يعمل بعد اكتمال التوفير، بغض النظر عن النتيجة. إذا استغرق توفير الحسابات أكثر من 6 ساعات، التعامل معه على أنه فشل عند تحديد تأخيرات تقييم ما بعد التوفير .
    • الافتراضي هو PT10M (10 دقائق).
    • قد يؤدي تحديد تأخير طويل في التقييم إلى عدم تحديث حالة الامتثال المسجلة للمورد حتى يتم تشغيل التقييم التالي.
  • الوجودشرط (اختياري)

    • إذا لم يتم تحديده، فإن أي مورد ذي صلة من النوع يفي بالتأثير ولا يؤدي إلى تشغيل النشر.
    • يستخدم نفس لغة قاعدة النهج لشرط if ، ولكن يتم تقييمه مقابل كل مورد ذي صلة على حدة.
    • إذا تم تقييم أي مورد ذي صلة مطابق إلى true، فسيكون التأثير راضيا ولا يؤدي إلى تشغيل النشر.
    • يمكن استخدام [field()] للتحقق من التكافؤ مع القيم في حالة if .
    • على سبيل المثال، يمكن استخدامها للتحقق من أن المورد الأصل (في حالة if ) موجود في نفس موقع المورد مثل المورد ذي الصلة المطابق.
  • roleDefinitionIds (مطلوب)

    • يجب أن تتضمن هذه الخاصية مجموعة من السلاسل التي تطابق معرف دور التحكم في الوصول المستند إلى الدور الذي يمكن الوصول إليه بواسطة الاشتراك. لمزيد من المعلومات، راجع المعالجة - تكوين تعريف النهج.
  • DeploymentScope (اختياري)

    • القيم المسموح بها هي الاشتراك ومجموعة الموارد.
    • يضبط نوع النشر المراد تشغيله. يشير الاشتراك إلى نشر على مستوى الاشتراك، ويشير ResourceGroup إلى نشر إلى مجموعة موارد.
    • يجب تحديد خاصية الموقع في النشر عند استخدام عمليات النشر على مستوى الاشتراك.
    • الافتراضي هو ResourceGroup.
  • النشر (مطلوب)

    • يجب أن تتضمن هذه الخاصية نشر القالب الكامل حيث سيتم تمريره إلى Microsoft.Resources/deployments واجهة برمجة تطبيقات PUT. لمزيد من المعلومات، راجع واجهة برمجة تطبيقات REST لعمليات النشر.
    • يجب أن تستخدم المتداخلة Microsoft.Resources/deployments داخل القالب أسماء فريدة لتجنب الخلاف بين تقييمات السياسات المتعددة. يمكن استخدام اسم النشر الأصل كجزء من اسم النشر المتداخل عبر [concat('NestedDeploymentName-', uniqueString(deployment().name))].

    ملاحظة

    يتم تقييم كافة الوظائف داخل خاصية النشر كمكونات للقالب، وليس كنهج. الاستثناء هو خاصية المعلمات التي تمرر القيم من النهج إلى القالب. يتم استخدام القيمة الموجودة في هذا القسم ضمن اسم معلمة قالب لتنفيذ تمرير هذه القيمة (راجع fullDbName في مثال DeployIfNotExists).

مثال على DeployIfNotExists

مثال: يقيم قواعد بيانات SQL Server لتحديد ما إذا كان قد تم تمكين transparentDataEncryption أم لا. إذا لم يكن الأمر كذلك ، تنفيذ نشر لتمكينه.

"if": {
    "field": "type",
    "equals": "Microsoft.Sql/servers/databases"
},
"then": {
    "effect": "DeployIfNotExists",
    "details": {
        "type": "Microsoft.Sql/servers/databases/transparentDataEncryption",
        "name": "current",
        "evaluationDelay": "AfterProvisioning",
        "roleDefinitionIds": [
            "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/{roleGUID}",
            "/providers/Microsoft.Authorization/roleDefinitions/{builtinroleGUID}"
        ],
        "existenceCondition": {
            "field": "Microsoft.Sql/transparentDataEncryption.status",
            "equals": "Enabled"
        },
        "deployment": {
            "properties": {
                "mode": "incremental",
                "template": {
                    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
                    "contentVersion": "1.0.0.0",
                    "parameters": {
                        "fullDbName": {
                            "type": "string"
                        }
                    },
                    "resources": [{
                        "name": "[concat(parameters('fullDbName'), '/current')]",
                        "type": "Microsoft.Sql/servers/databases/transparentDataEncryption",
                        "apiVersion": "2014-04-01",
                        "properties": {
                            "status": "Enabled"
                        }
                    }]
                },
                "parameters": {
                    "fullDbName": {
                        "value": "[field('fullName')]"
                    }
                }
            }
        }
    }
}

⁧⁩مُعطل⁧⁩

هذا التأثير مفيد لاختبار المواقف أو عندما يكون تعريف السياسة قد حدد معلمات التأثير. تتيح هذه المرونة تعطيل مهمة واحدة بدلا من تعطيل جميع تعيينات هذا النهج.

بديل للتأثير المعطل هو enforceMode ، الذي تم تعيينه على تعيين النهج. عند تعطيلوضع التنفيذ، لا يزال يتم تقييم الموارد. لا يحدث تسجيل الدخول، مثل سجلات النشاط، وتأثير النهج. لمزيد من المعلومات، راجع تعيين النهج - وضع التنفيذ.

EnforceOPAConstraint

يتم استخدام هذا التأثير مع وضع تعريف السياسة ل Microsoft.Kubernetes.Data. يتم استخدامه لتمرير قواعد التحكم في القبول Gatekeeper v3 المحددة باستخدام إطار عمل قيود OPA لفتح عامل النهج (OPA) إلى مجموعات Kubernetes على Azure.

هام

يتم إهمال تعريفات نهج المعاينة المحدودة مع تأثير EnforceOPAConstraint وفئة خدمة Kubernetes ذات الصلة. بدلا من ذلك، استخدم تدقيق التأثيرات ورفضها باستخدام وضع Microsoft.Kubernetes.Dataموفر الموارد.

EnforceOPACتقييم أونسلينت

تقوم وحدة التحكم في قبول وكيل النهج المفتوح بتقييم أي طلب جديد على المجموعة في الوقت الفعلي. كل 15 دقيقة، يتم الانتهاء من فحص كامل للمجموعة وإبلاغ النتائج إلى Azure Policy.

EnforceOPAConstraint properties

تحتوي خاصية تفاصيل تأثير EnforceOPAConstraint على الخصائص الفرعية التي تصف قاعدة التحكم في قبول Gatekeeper v3.

  • constraintTemplate (مطلوب)
    • قالب القيد CustomResourceDefinition (CRD) الذي يعرف القيود الجديدة. يحدد القالب منطق Rego ومخطط القيد ومعلمات القيد التي يتم تمريرها عبر قيم من Azure Policy.
  • القيد (مطلوب)
    • تنفيذ CRD لقالب القيد. يستخدم المعلمات التي تم تمريرها عبر القيم ك {{ .Values.<valuename> }}. في المثال التالي، هذه القيم هي {{ .Values.cpuLimit }} و {{ .Values.memoryLimit }}.
  • القيم (اختياري)
    • يحدد أي معلمات وقيم لتمريرها إلى القيد. يجب أن توجد كل قيمة في قالب القيد CRD.

EnforceOPAConstraint example

مثال: قاعدة التحكم في قبول Gatekeeper v3 لتعيين حدود وحدة المعالجة المركزية وموارد الذاكرة في Kubernetes.

"if": {
    "allOf": [
        {
            "field": "type",
            "in": [
                "Microsoft.ContainerService/managedClusters",
                "AKS Engine"
            ]
        },
        {
            "field": "location",
            "equals": "westus2"
        }
    ]
},
"then": {
    "effect": "enforceOPAConstraint",
    "details": {
        "constraintTemplate": "https://raw.githubusercontent.com/Azure/azure-policy/master/built-in-references/Kubernetes/container-resource-limits/template.yaml",
        "constraint": "https://raw.githubusercontent.com/Azure/azure-policy/master/built-in-references/Kubernetes/container-resource-limits/constraint.yaml",
        "values": {
            "cpuLimit": "[parameters('cpuLimit')]",
            "memoryLimit": "[parameters('memoryLimit')]"
        }
    }
}

EnforceRegoPolicy

يتم استخدام هذا التأثير مع وضع تعريف السياسة ل Microsoft.ContainerService.Data. يتم استخدامه لتمرير قواعد التحكم في القبول Gatekeeper v2 المحددة مع Rego إلى Open Policy Agent (OPA) على Azure Kubernetes Service.

هام

يتم إهمال تعريفات نهج المعاينة المحدودة مع تأثير EnforceRegoPolicy وفئة خدمة Kubernetes ذات الصلة. بدلا من ذلك، استخدم تدقيق التأثيرات ورفضها باستخدام وضع Microsoft.Kubernetes.Dataموفر الموارد.

تقييم EnforceRegoPolicy

تقوم وحدة التحكم في قبول وكيل النهج المفتوح بتقييم أي طلب جديد على المجموعة في الوقت الفعلي. كل 15 دقيقة، يتم الانتهاء من فحص كامل للمجموعة وإبلاغ النتائج إلى Azure Policy.

خصائص EnforceRegoPolicy

تحتوي الخاصية التفصيلية لتأثير EnforceRegoPolicy على الخصائص الفرعية التي تصف قاعدة التحكم في قبول Gatekeeper v2.

  • policyId (مطلوب)
    • تم تمرير اسم فريد كمعلمة إلى قاعدة التحكم في قبول Rego.
  • السياسة (مطلوب)
    • يحدد عنوان URI لقاعدة التحكم في قبول Rego.
  • السياسةالمعلمات (اختياري)
    • يحدد أي معلمات وقيم لتمريرها إلى سياسة الإعادة.

مثال على EnforceRegoPolicy

مثال: قاعدة التحكم في قبول Gatekeeper v2 للسماح فقط بصور الحاوية المحددة في AKS.

"if": {
    "allOf": [
        {
            "field": "type",
            "equals": "Microsoft.ContainerService/managedClusters"
        },
        {
            "field": "location",
            "equals": "westus2"
        }
    ]
},
"then": {
    "effect": "EnforceRegoPolicy",
    "details": {
        "policyId": "ContainerAllowedImages",
        "policy": "https://raw.githubusercontent.com/Azure/azure-policy/master/built-in-references/KubernetesService/container-allowed-images/limited-preview/gatekeeperpolicy.rego",
        "policyParameters": {
            "allowedContainerImagesRegex": "[parameters('allowedContainerImagesRegex')]"
        }
    }
}

"Modify"

يستخدم التعديل لإضافة خصائص أو علامات أو تحديثها أو إزالتها على اشتراك أو مورد أثناء الإنشاء أو التحديث. مثال شائع هو تحديث العلامات على موارد مثل costCenter. يمكن معالجة الموارد الحالية غير المتوافقة من خلال مهمة معالجة. يمكن أن تحتوي قاعدة تعديل واحدة على أي عدد من العمليات. تتطلب تعيينات النهج التي تم تعيينها كتعديل هوية مدارة لإجراء المعالجة.

يتم دعم العمليات التالية بواسطة تعديل:

  • إضافة علامات الموارد أو استبدالها أو إزالتها. بالنسبة للعلامات، كان يجب mode تعيين نهج تعديل إلى مفهرس ما لم يكن المورد الهدف مجموعة موارد.
  • إضافة أو استبدال قيمة نوع الهوية المدارة (identity.type) للأجهزة الظاهرية ومجموعات مقياس الجهاز الظاهري.
  • إضافة قيم أسماء مستعارة معينة أو استبدالها.
    • استخدم Get-AzPolicyAlias | Select-Object -ExpandProperty 'Aliases' | Where-Object { $_.DefaultMetadata.Attributes -eq 'Modifiable' } في Azure PowerShell 4.6.0 أو أعلى للحصول على قائمة بالأسماء المستعارة التي يمكن استخدامها مع تعديل.

هام

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

تعديل التقييم

يتم تقييم التعديل قبل معالجة الطلب من قبل موفر الموارد أثناء إنشاء مورد أو تحديثه. يتم تطبيق عمليات التعديل على محتوى الطلب عند استيفاء شرط if الخاص بقاعدة النهج. يمكن لكل عملية تعديل تحديد شرط يحدد وقت تطبيقه. يتم تخطي العمليات ذات الشروط التي يتم تقييمها على أنها خاطئة .

عند تحديد اسم مستعار، يتم إجراء عمليات التحقق الإضافية التالية للتأكد من أن عملية "تعديل" لا تغير محتوى الطلب بطريقة تؤدي إلى رفض موفر الموارد له:

  • يتم وضع علامة على الخاصية التي يرمز إليها الاسم المستعار على أنها "قابلة للتعديل" في إصدار واجهة برمجة التطبيقات للطلب.
  • يتطابق نوع الرمز المميز في عملية التعديل مع نوع الرمز المميز المتوقع للخاصية في إصدار واجهة برمجة التطبيقات للطلب.

في حالة فشل أي من هذه التحققات، يعود تقييم النهج إلى تأثير التعارض المحدد.

هام

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

عندما يتم تشغيل تعريف نهج باستخدام تأثير تعديل كجزء من دورة تقييم، فإنه لا يقوم بإجراء تغييرات على الموارد الموجودة بالفعل. بدلا من ذلك، فإنه يضع علامة على أي مورد يفي بشرط if على أنه غير متوافق.

تعديل الخصائص

تحتوي خاصية تفاصيل تأثير التعديل على كافة الخصائص الفرعية التي تحدد الأذونات اللازمة للمعالجة والعمليات المستخدمة لإضافة قيم علامات تمييز أو تحديثها أو إزالتها.

  • roleDefinitionIds (مطلوب)
    • يجب أن تتضمن هذه الخاصية مجموعة من السلاسل التي تطابق معرف دور التحكم في الوصول المستند إلى الدور الذي يمكن الوصول إليه بواسطة الاشتراك. لمزيد من المعلومات، راجع المعالجة - تكوين تعريف النهج.
    • يجب أن يتضمن الدور المحدد جميع العمليات الممنوحة لدور المساهم .
  • تأثير التعارض (اختياري)
    • يحدد تعريف النهج الذي "يفوز" إذا قام أكثر من تعريف نهج واحد بتعديل الخاصية نفسها أو عندما لا تعمل عملية التعديل على الاسم المستعار المحدد.
      • بالنسبة للموارد الجديدة أو المحدثة، يكون لتعريف السياسة مع الرفض الأسبقية. تعريفات السياسة مع التدقيق تخطي جميع العمليات. إذا تم رفض أكثر من تعريف سياسة واحد، يتم رفض الطلب باعتباره تعارضا. إذا كانت جميع تعريفات السياسة تخضع للتدقيق، فلن تتم معالجة أي من عمليات تعريفات السياسة المتضاربة.
      • بالنسبة للموارد الموجودة، إذا تم رفض أكثر من تعريف واحد للسياسة، تكون حالة الامتثال هي التعارض. إذا تم رفض تعريف نهج واحد أو أقل، فسيقوم كل تعيين بإرجاع حالة امتثال غير متوافقة.
    • القيم المتوفرة: التدقيق، الرفض، التعطيل.
    • القيمة الافتراضية هي رفض.
  • العمليات (مطلوب)
    • مجموعة من جميع عمليات العلامة التي سيتم إكمالها على الموارد المطابقة.
    • الخصائص:
      • العملية (مطلوب)
        • يحدد الإجراء الذي يجب اتخاذه بشأن مورد مطابق. الخيارات هي: addOrاستبدال، إضافة، إزالة. إضافة تصرفات مشابهة لتأثير الإلحاق .
      • حقل (مطلوب)
        • العلامة المراد إضافتها أو استبدالها أو إزالتها. يجب أن تلتزم أسماء العلامات بنفس اصطلاح التسمية للحقول الأخرى.
      • القيمة (اختياري)
        • القيمة المراد تعيين العلامة إليها.
        • هذه الخاصية مطلوبة إذا كانت العملية هي addOrReplace أو Add.
      • الشرط (اختياري)
        • سلسلة تحتوي على تعبير لغة نهج Azure مع دالات النهج التي يتم تقييمها إلى صواب أو خطأ.
        • لا يدعم وظائف النهج التالية: field(), , resourceGroup()subscription().

تعديل العمليات

يتيح صفيف خصائص العمليات إمكانية تغيير عدة علامات بطرق مختلفة عن تعريف نهج واحد. تتكون كل عملية من خصائص التشغيلوالحقلوالقيمة . تحدد العملية ما تفعله مهمة المعالجة للعلامات التجارية، ويحدد الحقل العلامة التي يتم تغييرها، وتحدد القيمة الإعداد الجديد لتلك العلامة. يقوم المثال التالي بإجراء تغييرات العلامة التالية:

  • يضبط العلامة على environment "اختبار"، حتى لو كانت موجودة بالفعل بقيمة مختلفة.
  • يزيل العلامة TempResource.
  • تعيين العلامة إلى معلمة النهج DeptName التي تم تكوينها في تعيين Dept النهج.
"details": {
    ...
    "operations": [
        {
            "operation": "addOrReplace",
            "field": "tags['environment']",
            "value": "Test"
        },
        {
            "operation": "Remove",
            "field": "tags['TempResource']",
        },
        {
            "operation": "addOrReplace",
            "field": "tags['Dept']",
            "value": "[parameters('DeptName')]"
        }
    ]
}

تحتوي خاصية العملية على الخيارات التالية:

‏‏التشغيل الوصف
addOrReplace يضيف الخاصية المحددة أو العلامة والقيمة إلى المورد، حتى إذا كانت الخاصية أو العلامة موجودة بالفعل بقيمة مختلفة.
إضافة يضيف الخاصية المحددة أو العلامة والقيمة إلى المورد.
إزالة يزيل الخاصية أو العلامة المعرفة من المورد.

تعديل الأمثلة

مثال 1: إضافة environment العلامة واستبدال العلامات الموجودة environment ب "اختبار":

"then": {
    "effect": "modify",
    "details": {
        "roleDefinitionIds": [
            "/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"
        ],
        "operations": [
            {
                "operation": "addOrReplace",
                "field": "tags['environment']",
                "value": "Test"
            }
        ]
    }
}

مثال 2: إزالة env العلامة وإضافة environment العلامة أو استبدال العلامات الموجودة environment بقيمة معلمة:

"then": {
    "effect": "modify",
    "details": {
        "roleDefinitionIds": [
            "/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"
        ],
        "conflictEffect": "deny",
        "operations": [
            {
                "operation": "Remove",
                "field": "tags['env']"
            },
            {
                "operation": "addOrReplace",
                "field": "tags['environment']",
                "value": "[parameters('tagValue')]"
            }
        ]
    }
}

مثال 3: تأكد من أن حساب التخزين لا يسمح بالوصول العام إلى blob ، يتم تطبيق عملية التعديل فقط عند تقييم الطلبات باستخدام إصدار API أكبر أو يساوي "2019-04-01":

"then": {
    "effect": "modify",
    "details": {
        "roleDefinitionIds": [
            "/providers/microsoft.authorization/roleDefinitions/17d1049b-9a84-46fb-8f53-869881c3d3ab"
        ],
        "conflictEffect": "audit",
        "operations": [
            {
                "condition": "[greaterOrEquals(requestContext().apiVersion, '2019-04-01')]",
                "operation": "addOrReplace",
                "field": "Microsoft.Storage/storageAccounts/allowBlobPublicAccess",
                "value": false
            }
        ]
    }
}

تعريفات سياسة الطبقات

قد يتأثر المورد بعدة تعيينات. وقد تكون هذه التخصيصات في نفس النطاق أو في نطاقات مختلفة. ومن المرجح أيضا أن يكون لكل من هذه المهام أثر مختلف محدد. يتم تقييم حالة وتأثير كل بوليصة بشكل مستقل. على سبيل المثال:

  • السياسة 1
    • يقيد موقع المورد إلى "ويستوس"
    • تم تعيينه للاشتراك A
    • رفض التأثير
  • السياسة 2
    • يقيد موقع المورد إلى "Eastus"
    • تم تعيينه إلى مجموعة الموارد B في الاشتراك A
    • تأثير التدقيق

سيؤدي هذا الإعداد إلى النتيجة التالية:

  • أي مورد موجود بالفعل في مجموعة الموارد B في "eastus" متوافق مع السياسة 2 وغير متوافق مع السياسة 1
  • أي مورد موجود بالفعل في مجموعة الموارد B وليس في "eastus" غير متوافق مع السياسة 2 وغير متوافق مع السياسة 1 إن لم يكن في "westus"
  • يتم رفض أي مورد جديد في الاشتراك A ليس في "westus" بواسطة السياسة 1
  • يتم إنشاء أي مورد جديد في الاشتراك A ومجموعة الموارد B في "westus" وغير متوافق مع السياسة 2

إذا كان لكل من السياسة 1 والسياسة 2 تأثير الإنكار ، فإن الوضع يتغير إلى:

  • أي مورد موجود بالفعل في مجموعة الموارد B وليس في "eastus" غير متوافق مع السياسة 2
  • أي مورد موجود بالفعل في مجموعة الموارد B وليس في "westus" غير متوافق مع السياسة 1
  • يتم رفض أي مورد جديد في الاشتراك A ليس في "westus" بواسطة السياسة 1
  • يتم رفض أي مورد جديد في مجموعة الموارد B من الاشتراك A

يتم تقييم كل مهمة على حدة. على هذا النحو ، لا توجد فرصة لمورد للانزلاق من خلال فجوة من الاختلافات في النطاق. وتعتبر النتيجة الصافية لتعريفات نهج الطبقات تراكمية أكثر تقييداً. وكمثال على ذلك، إذا كان لكل من السياستين 1 و2 أثر إنكار، فإن موردا ما سيمنع بسبب تعاريف السياسة العامة المتداخلة والمتضاربة. إذا كنت لا تزال بحاجة إلى إنشاء المورد في النطاق الهدف، فراجع الاستثناءات الموجودة في كل مهمة للتحقق من صحة تعيينات النهج الصحيحة التي تؤثر على النطاقات الصحيحة.

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