Pahami efek Azure Policy

Setiap definisi kebijakan dalam Azure Policy memiliki satu efek. Efeknya menentukan apa yang terjadi ketika aturan kebijakan dievaluasi agar cocok. Efek berperilaku berbeda jika mereka digunakan untuk sumber daya baru, sumber daya yang diperbarui, atau sumber daya yang ada.

Efek tersebut saat ini didukung dalam definisi kebijakan:

Efek berikut tidak digunakan lagi:

Penting

Untuk menggantikan efek EnforceOPAConstraint atau EnforceRegoPolicy, gunakan audit dan tolak dengan mode Resource ProviderMicrosoft.Kubernetes.Data. Definisi kebijakan bawaan telah diperbarui. Ketika penugasan kebijakan yang ada dari definisi kebijakan bawaan ini dimodifikasi, parameter efek harus diubah menjadi nilai dalam daftar allowedValues yang diperbarui.

Urutan evaluasi

Permintaan untuk membuat atau memperbarui sumber daya dievaluasi oleh Azure Policy terlebih dahulu. Azure Policy membuat daftar semua penugasan yang berlaku untuk sumber daya lalu mengevaluasi sumber daya terhadap setiap definisi. Untuk mode Azure Resource Manager, Azure Policy memproses beberapa efek sebelum menyerahkan permintaan kepada Resource Provider yang sesuai. Urutan ini mencegah pemrosesan yang tidak perlu oleh Penyedia Sumber Daya saat sumber daya tidak memenuhi kontrol tata kelola Azure Policy yang dirancang. Dengan mode Resource Provider, Resource Provider mengelola evaluasi dan hasil serta melaporkan hasilnya kembali ke Azure Policy.

  • Dinonaktifkan diperiksa terlebih dahulu untuk menentukan apakah aturan kebijakan harus dievaluasi.
  • Tambahkan dan Ubah kemudian dievaluasi. Karena dapat mengubah permintaan, perubahan yang dilakukan dapat mencegah audit atau menolak efek dari pemicu. Efek ini hanya tersedia dengan mode Azure Resource Manager.
  • Tolak kemudian dievaluasi. Dengan mengevaluasi tolak sebelum audit, pencatatan ganda sumber daya yang tidak diinginkan dicegah.
  • Audit dievaluasi terakhir.

Setelah Resource Provider mengembalikan kode keberhasilan pada permintaan mode Resource Manager, AuditIfNotExists dan DeployIfNotExists mengevaluasi untuk menentukan apakah pencatatan atau tindakan kepatuhan tambahan diperlukan.

Selain itu, permintaan PATCH yang hanya memodifikasi bidang tags terkait membatasi evaluasi kebijakan terhadap kebijakan yang berisi kondisi yang memeriksa bidang tags terkait.

Tambah

Tambah digunakan untuk menambahkan bidang tambahan ke sumber daya yang diminta selama pembuatan atau pembaruan. Contoh umumnya adalah menentukan IP yang diizinkan untuk sumber daya penyimpanan.

Penting

Tambah ditujukan untuk digunakan dengan properti non-tag. Meskipun Tambah dapat menambahkan tag ke sumber daya selama permintaan buat atau perbarui, disarankan untuk menggunakan efek Mengubah untuk tag.

Evaluasi tambah

Tambah mengevaluasi sebelum permintaan diproses oleh Penyedia Sumber Daya selama pembuatan atau pembaruan sumber daya. Tambah menambahkan bidang ke sumber daya saat kondisi jika aturan kebijakan terpenuhi. Jika efek tambah akan menimpa nilai dalam permintaan asli dengan nilai yang berbeda, maka efek tersebut bertindak sebagai efek tolak dan menolak permintaan. Untuk menambahkan nilai baru ke array yang sudah ada, gunakan versi alias [*].

Ketika definisi kebijakan yang menggunakan efek penambahan dijalankan sebagai bagian dari siklus evaluasi, hal ini tidak membuat perubahan pada sumber daya yang sudah ada. Sebaliknya, hal ini menandai sumber daya apa pun yang memenuhi kondisi jika sebagai tidak patuh.

Properti tambah

Efek tambah hanya memiliki array detail, yang diperlukan. Karena detailnya adalah array, satu pasangan bidang/nilai atau kelipatannya. Lihat struktur definisi untuk daftar bidang yang dapat diterima.

Contoh tambah

Contoh 1: Pasangan bidang/nilai tunggal yang menggunakan alias non-[*] dengan nilai array untuk mengatur aturan IP pada akun penyimpanan. Saat alias non-[*] adalah array, efeknya akan menambahkan nilai sebagai seluruh array. Jika array sudah ada, peristiwa tolak terjadi dari konflik.

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

Contoh 2: Pasangan bidang/nilai tunggal yang menggunakan alias[*] dengan nilai array untuk mengatur aturan IP pada akun penyimpanan. Dengan menggunakan alias [*], efeknya akan menambahkan nilai ke array yang berpotensi sudah ada sebelumnya. Jika array belum ada, array akan dibuat.

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

Audit

Audit digunakan untuk membuat peristiwa peringatan di log aktivitas saat mengevaluasi sumber daya yang tidak mematuhi, tetapi tidak menghentikan permintaan.

Evaluasi audit

Audit adalah efek terakhir yang dicentang oleh Azure Policy selama pembuatan atau pembaruan sumber daya. Untuk mode Azure Resource Manager, Azure Policy kemudian mengirim sumber daya ke Resource Provider. Saat mengevaluasi permintaan buat atau perbarui sumber daya, Azure Policy menambahkan operasi Microsoft.Authorization/policies/audit/action ke log aktivitas dan menandai sumber daya sebagai tidak patuh. Selama siklus evaluasi kepatuhan standar, hanya status kepatuhan pada sumber daya yang diperbarui.

Properti audit

Untuk mode Azure Resource Manager, efek audit tidak memiliki properti tambahan untuk digunakan dalam kondisi saat itu dari definisi kebijakan.

Untuk mode Resource Provider Microsoft.Kubernetes.Data, efek audit memiliki subpropertidetail tambahan berikut. Penggunaan templateInfo diperlukan untuk definisi kebijakan baru atau yang diperbarui karena constraintTemplate sudah tidak digunakan lagi.

  • templateInfo (wajib)
    • Tidak dapat digunakan dengan constraintTemplate.
    • sourceType (wajib)
      • Mendefinisikan jenis sumber untuk templat batasan. Nilai yang diizinkan: PublicURL atau Base64Encoded.

      • Jika PublicURL, dipasangkan dengan properti url untuk menyediakan lokasi templat batasan. Lokasi harus dapat diakses publik.

        Peringatan

        Jangan gunakan SAS URI atau token di url atau apa pun yang dapat mengekspos rahasia.

      • Jika Base64Encoded, dipasangkan dengan properti content untuk menyediakan templat batasan dikodekan base 64. Lihat Membuat definisi kebijakan dari templat batasan untuk membuat definisi kustom dari templat batasan Open Policy Agent (OPA) GateKeeper v3 yang ada.

  • batasan (tidak digunakan lagi)
    • Tidak dapat digunakan dengan templateInfo.
    • Implementasi CRD dari templat Batasan. Menggunakan parameter yang diteruskan melalui nilai sebagai {{ .Values.<valuename> }}. Dalam contoh 2 di bawah ini, nilai-nilai ini adalah {{ .Values.excludedNamespaces }} dan {{ .Values.allowedContainerImagesRegex }}.
  • namespace layanan (opsional)
    • Sebuah array pada namespace layanan Kubernetes untuk membatasi kebijakan.
    • Nilai yang kosong atau hilang menyebabkan evaluasi kebijakan menyertakan semua namespace layanan, kecuali yang ditentukan dalam excludedNamespaces.
  • excludedNamespaces (wajib)
  • labelSelector (wajib)
    • Objek yang menyertakan properti matchLabels (objek) dan matchExpression (array) untuk memungkinkan penentuan sumber Kubernetes mana yang akan disertakan untuk evaluasi kebijakan yang cocok dengan label dan pemilih yang disediakan.
    • Nilai yang kosong atau hilang menyebabkan evaluasi kebijakan menyertakan semua label dan pemilih, kecuali namespace layanan yang ditentukan dalam excludedNamespaces.
  • apiGroups (diperlukan saat menggunakan templateInfo)
    • Array yang menyertakan grup API untuk dicocokkan. Array kosong ([""]) adalah grup API inti.
    • Tidak diizinkan untuk mendefinisikan ["*"] pada apiGroups.
  • jenis-jenis (diperlukan saat menggunakan templateInfo)
    • Array yang menyertakan jenis objek Kubernetes untuk membatasi evaluasi.
    • Tidak diizinkan untuk mendefinisikan ["*"] pada jenis.
  • nilai (opsional)
    • Menentukan parameter dan nilai apa pun untuk diteruskan ke Batasan. Setiap nilai harus ada di CRD templat Batasan.
  • constraintTemplate (tidak digunakan lagi)
    • Tidak dapat digunakan dengan templateInfo.
    • Harus diganti dengan templateInfo saat membuat atau memperbarui ketentuan kebijakan.
    • CustomResourceDefinition (CRD) templat Batasan yang menentukan Batasan baru. Templat menentukan logika Rego, skema Batasan, dan parameter Batasan yang diteruskan melalui nilai dari Azure Policy.

Contoh audit

Contoh 1: Menggunakan efek audit untuk mode Resource Manager.

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

Contoh 2: Menggunakan efek audit untuk mode Resource Provider Microsoft.Kubernetes.Data. Informasi tambahan di details.templateInfo mendeklarasikan penggunaan PublicURL dan menetapkan url ke lokasi templat Batasan untuk digunakan di Kubernetes guna membatasi gambar kontainer yang diizinkan.

"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 memungkinkan audit sumber daya yang terkait dengan sumber daya yang cocok dengan kondisi jika, tetapi tidak memiliki properti yang ditentukan dalam detail dari kondisi saat itu.

Evaluasi AuditIfNotExists

Hal ini berjalan setelah Resource Provider menangani permintaan membuat atau memperbarui sumber daya dan evaluasi telah mengembalikan kode status keberhasilan. Audit terjadi jika tidak ada sumber daya terkait atau jika sumber daya yang ditentukan oleh ExistenceCondition tidak mengevaluasi ke true. Untuk sumber daya baru dan yang diperbarui, Azure Policy menambahkan operasi Microsoft.Authorization/policies/audit/action ke log aktivitas dan menandai sumber daya sebagai tidak patuh. Ketika dipicu, sumber daya yang memenuhi kondisi jika adalah sumber daya yang ditandai sebagai tidak patuh.

Properti AuditIfNotExists

Properti detail dari efek AuditIfNotExists memiliki semua subproperti yang menentukan sumber daya terkait yang cocok.

  • Jenis (diperlukan)
    • Menentukan jenis sumber daya terkait yang cocok.
    • Jika type adalah jenis sumber daya di bawah sumber daya kondisi if, kueri kebijakan untuk sumber daya type ini dalam cakupan sumber daya yang dievaluasi. Jika tidak, kueri kebijakan dalam grup sumber daya atau langganan yang sama dengan sumber daya yang dievaluasi bergantung pada existenceScope.
  • Nama (opsional)
    • Menentukan nama persis sumber daya yang cocok dan menyebabkan kebijakan mengambil satu sumber daya tertentu, bukan semua sumber daya dari jenis yang ditentukan.
    • Ketika nilai kondisi untuk if.field.type dan then.details.type cocok, maka Nama menjadi diperlukan dan harus [field('name')], atau [field('fullName')] untuk sumber daya anak. Namun, efek audit harus dipertimbangkan.
  • ResourceGroupName (opsional)
    • Memungkinkan pencocokan sumber daya terkait berasal dari grup sumber daya yang berbeda.
    • Tidak berlaku jika jenis adalah sumber daya yang akan berada di bawah sumber daya kondisi jika.
    • Defaultnya adalah grup sumber daya dari sumber daya kondisijika.
  • ExistenceScope (opsional)
    • Nilai yang diperbolehkan adalah Langganan dan ResourceGroup.
    • Mengatur lingkup tempat mengambil sumber daya terkait untuk dicocokkan.
    • Tidak berlaku jika jenis adalah sumber daya yang akan berada di bawah sumber daya kondisi jika.
    • Untuk ResourceGroup, akan membatasi sumber daya grup dari kondisi sumber daya jika yang ditentukan dalam ResourceGroupName.
    • Untuk Langganan, kueri seluruh langganan untuk sumber daya terkait. Lingkup penetapan harus ditetapkan pada langganan atau yang lebih tinggi untuk evaluasi yang tepat.
    • Defaultnya adalah ResourceGroup.
  • EvaluationDelay (opsional)
    • Menentukan kapan keberadaan sumber daya terkait harus dievaluasi. Penundaan hanya digunakan untuk evaluasi yang merupakan hasil dari permintaan pembuatan atau pembaruan sumber daya.
    • Nilai yang diizinkan adalah AfterProvisioning, AfterProvisioningSuccess, AfterProvisioningFailure, atau durasi ISO 8601 antara 0 dan 360 menit.
    • Nilai AfterProvisioning memeriksa hasil provisi sumber daya yang dievaluasi dalam kondisi IF aturan kebijakan. AfterProvisioning berjalan setelah provisi selesai, terlepas apapun hasilnya. Jika provisi membutuhkan waktu lebih dari 6 jam, provisi tersebut dianggap sebagai gagal saat menentukan penundaan evaluasi AfterProvisioning.
    • Defaultnya adalah PT10M (10 menit).
    • Menentukan penundaan evaluasi yang lama dapat menyebabkan status kepatuhan sumber daya yang tercatat tidak diperbarui hingga pemicu evaluasi berikutnya.
  • ExistenceCondition (opsional)
    • Jika tidak ditentukan, sumber daya jenis terkait memenuhi efek dan tidak memicu audit.
    • Menggunakan bahasa yang sama dengan aturan kebijakan untuk kondisi if, tetapi dievaluasi terhadap setiap sumber daya terkait satu per satu.
    • Jika ada sumber daya terkait yang cocok yang dievaluasi ke true, efeknya puas dan tidak memicu audit.
    • Dapat menggunakan [field()] untuk memeriksa kesetaraan dengan nilai dalam kondisi if.
    • Misalnya, dapat digunakan untuk memvalidasi bahwa sumber daya induk (dalam kondisi jika) berada di lokasi sumber daya yang sama dengan sumber daya terkait yang cocok.

Contoh AuditIfNotExists

Contoh: Mengevaluasi Microsoft Azure Virtual Machines untuk menentukan apakah ekstensi Antimalware ada kemudian mengaudit saat hilang.

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

Tolak

Tolak digunakan untuk mencegah permintaan sumber daya yang tidak sesuai dengan standar yang ditentukan melalui definisi kebijakan dan mengagalkan permintaan.

Evaluasi tolak

Saat membuat atau memperbarui sumber daya yang cocok dalam mode Azure Resource Manager, tolak akan mencegah permintaan sebelum dikirim ke Resource Provider. Permintaan dikembalikan sebagai 403 (Forbidden). Di portal, Terlarang dapat dilihat sebagai status pada penyebaran yang dicegah oleh penugasan kebijakan. Untuk mode Resource Provider, penyedia sumber daya mengelola evaluasi sumber daya.

Selama evaluasi sumber daya yang ada, sumber daya yang cocok dengan definisi kebijakan tolak ditandai sebagai tidak patuh.

Properti tolak

Untuk mode Azure Resource Manager, efek audit tidak memiliki properti tambahan untuk digunakan dalam kondisi saat itu dari definisi kebijakan.

Untuk mode Resource Provider Microsoft.Kubernetes.Data, efek tolak memiliki subproperti detail tambahan berikut. Penggunaan templateInfo diperlukan untuk definisi kebijakan baru atau yang diperbarui karena constraintTemplate sudah tidak digunakan lagi.

  • templateInfo (wajib)
    • Tidak dapat digunakan dengan constraintTemplate.
    • sourceType (wajib)
      • Mendefinisikan jenis sumber untuk templat batasan. Nilai yang diizinkan: PublicURL atau Base64Encoded.

      • Jika PublicURL, dipasangkan dengan properti url untuk menyediakan lokasi templat batasan. Lokasi harus dapat diakses publik.

        Peringatan

        Jangan gunakan SAS URI atau token di url atau apa pun yang dapat mengekspos rahasia.

      • Jika Base64Encoded, dipasangkan dengan properti content untuk menyediakan templat batasan dikodekan base 64. Lihat Membuat definisi kebijakan dari templat batasan untuk membuat definisi kustom dari templat batasan Open Policy Agent (OPA) GateKeeper v3 yang ada.

  • batasan (opsional)
    • Tidak dapat digunakan dengan templateInfo.
    • Implementasi CRD dari templat Batasan. Menggunakan parameter yang diteruskan melalui nilai sebagai {{ .Values.<valuename> }}. Dalam contoh 2 di bawah ini, nilai-nilai ini adalah {{ .Values.excludedNamespaces }} dan {{ .Values.allowedContainerImagesRegex }}.
  • namespace layanan (opsional)
    • Sebuah array pada namespace layanan Kubernetes untuk membatasi kebijakan.
    • Nilai yang kosong atau hilang menyebabkan evaluasi kebijakan menyertakan semua namespace layanan, kecuali yang ditentukan dalam excludedNamespaces.
  • excludedNamespaces (wajib)
  • labelSelector (wajib)
    • Objek yang menyertakan properti matchLabels (objek) dan matchExpression (array) untuk memungkinkan penentuan sumber Kubernetes mana yang akan disertakan untuk evaluasi kebijakan yang cocok dengan label dan pemilih yang disediakan.
    • Nilai yang kosong atau hilang menyebabkan evaluasi kebijakan menyertakan semua label dan pemilih, kecuali namespace layanan yang ditentukan dalam excludedNamespaces.
  • apiGroups (diperlukan saat menggunakan templateInfo)
    • Array yang menyertakan grup API untuk dicocokkan. Array kosong ([""]) adalah grup API inti.
    • Tidak diizinkan untuk mendefinisikan ["*"] pada apiGroups.
  • jenis-jenis (diperlukan saat menggunakan templateInfo)
    • Array yang menyertakan jenis objek Kubernetes untuk membatasi evaluasi.
    • Tidak diizinkan untuk mendefinisikan ["*"] pada jenis.
  • nilai (opsional)
    • Menentukan parameter dan nilai apa pun untuk diteruskan ke Batasan. Setiap nilai harus ada di CRD templat Batasan.
  • constraintTemplate (tidak digunakan lagi)
    • Tidak dapat digunakan dengan templateInfo.
    • Harus diganti dengan templateInfo saat membuat atau memperbarui ketentuan kebijakan.
    • CustomResourceDefinition (CRD) templat Batasan yang menentukan Batasan baru. Templat menentukan logika Rego, skema Batasan, dan parameter Batasan yang diteruskan melalui nilai dari Azure Policy. Disarankan untuk menggunakan templateInfo yang lebih baru untuk menggantikan constraintTemplate.

Contoh tolak

Contoh 1: Menggunakan efek tolak untuk mode Resource Manager.

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

Contoh 2: Menggunakan efek tolak untuk mode Resource Provider Microsoft.Kubernetes.Data. Informasi tambahan di details.templateInfo mendeklarasikan penggunaan PublicURL dan menetapkan url ke lokasi templat Batasan untuk digunakan di Kubernetes guna membatasi gambar kontainer yang diizinkan.

"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

Seperti halnya AuditIfNotExists, definisi kebijakan DeployIfNotExists menjalankan penerapan templat saat kondisi terpenuhi. Penetapan kebijakan dengan efek yang ditetapkan sebagai DeployIfNotExists memerlukan identitas terkelola untuk melakukan remediasi.

Catatan

Templat bertumpuk didukung dengan deployIfNotExists, tetapi templat yang ditautkan saat ini tidak didukung.

Evaluasi DeployIfNotExists

Evaluasi DeployIfNotExists berjalan setelah penundaan yang dapat dikonfigurasi saat Resource Provider menangani pembuatan atau pembaruan langganan atau permintaan sumber daya dan telah mengembalikan kode status berhasil. Penyebaran templat terjadi jika tidak ada sumber daya terkait atau jika sumber daya yang ditentukan oleh ExistenceCondition tidak mengevaluasi ke true. Durasi penyebaran tergantung pada kompleksitas sumber daya yang disertakan dalam templat.

Selama siklus evaluasi, definisi kebijakan dengan efek DeployIfNotExists yang cocok dengan sumber daya ditandai sebagai tidak patuh, tetapi tidak ada tindakan yang diambil pada sumber daya tersebut. Sumber daya yang tidak sesuai dapat diremediasi dengan tugas remediasi.

Properti DeployIfNotExists

Properti detail efek DeployIfNotExists memiliki semua subproperti yang menentukan sumber daya terkait yang cocok dan penyebaran templat untuk dijalankan.

  • Jenis (diperlukan)

    • Menentukan jenis sumber daya terkait yang cocok.
    • Jika type adalah jenis sumber daya di bawah sumber daya kondisi if, kueri kebijakan untuk sumber daya type ini dalam cakupan sumber daya yang dievaluasi. Jika tidak, kueri kebijakan dalam grup sumber daya atau langganan yang sama dengan sumber daya yang dievaluasi bergantung pada existenceScope.
  • Nama (opsional)

    • Menentukan nama persis sumber daya yang cocok dan menyebabkan kebijakan mengambil satu sumber daya tertentu, bukan semua sumber daya dari jenis yang ditentukan.
    • Ketika nilai kondisi untuk if.field.type dan then.details.type cocok, maka Nama menjadi diperlukan dan harus [field('name')], atau [field('fullName')] untuk sumber daya anak.
  • ResourceGroupName (opsional)

    • Memungkinkan pencocokan sumber daya terkait berasal dari grup sumber daya yang berbeda.
    • Tidak berlaku jika jenis adalah sumber daya yang akan berada di bawah sumber daya kondisi jika.
    • Defaultnya adalah grup sumber daya dari sumber daya kondisijika.
    • Jika penyebaran templat dijalankan, penyebaran templat akan diterapkan dalam grup sumber daya dari nilai ini.
  • ExistenceScope (opsional)

    • Nilai yang diperbolehkan adalah Langganan dan ResourceGroup.
    • Mengatur lingkup tempat mengambil sumber daya terkait untuk dicocokkan.
    • Tidak berlaku jika jenis adalah sumber daya yang akan berada di bawah sumber daya kondisi jika.
    • Untuk ResourceGroup, akan membatasi sumber daya grup dari kondisi sumber daya jika yang ditentukan dalam ResourceGroupName.
    • Untuk Langganan, kueri seluruh langganan untuk sumber daya terkait. Lingkup penetapan harus ditetapkan pada langganan atau yang lebih tinggi untuk evaluasi yang tepat.
    • Defaultnya adalah ResourceGroup.
  • EvaluationDelay (opsional)

    • Menentukan kapan keberadaan sumber daya terkait harus dievaluasi. Penundaan hanya digunakan untuk evaluasi yang merupakan hasil dari permintaan pembuatan atau pembaruan sumber daya.
    • Nilai yang diizinkan adalah AfterProvisioning, AfterProvisioningSuccess, AfterProvisioningFailure, atau durasi ISO 8601 antara 0 dan 360 menit.
    • Nilai AfterProvisioning memeriksa hasil provisi sumber daya yang dievaluasi dalam kondisi IF aturan kebijakan. AfterProvisioning berjalan setelah provisi selesai, terlepas apapun hasilnya. Jika provisi membutuhkan waktu lebih dari 6 jam, provisi tersebut dianggap sebagai gagal saat menentukan penundaan evaluasi AfterProvisioning.
    • Defaultnya adalah PT10M (10 menit).
    • Menentukan penundaan evaluasi yang lama dapat menyebabkan status kepatuhan sumber daya yang tercatat tidak diperbarui hingga pemicu evaluasi berikutnya.
  • ExistenceCondition (opsional)

    • Jika tidak ditentukan, sumber daya jenis terkait memenuhi efek dan tidak memicu audit.
    • Menggunakan bahasa yang sama dengan aturan kebijakan untuk kondisi if, tetapi dievaluasi terhadap setiap sumber daya terkait satu per satu.
    • Jika ada sumber daya terkait yang cocok yang dievaluasi ke true, efeknya puas dan tidak memicu audit.
    • Dapat menggunakan [field()] untuk memeriksa kesetaraan dengan nilai dalam kondisi if.
    • Misalnya, dapat digunakan untuk memvalidasi bahwa sumber daya induk (dalam kondisi jika) berada di lokasi sumber daya yang sama dengan sumber daya terkait yang cocok.
  • roleDefinitionIds (diperlukan)

    • Properti ini harus menyertakan serangkaian untai (karakter) yang cocok dengan ID peran kontrol akses berbasis peran yang dapat diakses oleh langganan. Untuk informasi selengkapnya, lihat remediasi - mengonfigurasi definisi kebijakan.
  • DeploymentScope (opsional)

    • Nilai yang diperbolehkan adalah Langganan dan ResourceGroup.
    • Menyiapkan jenis penyebaran yang akan dipicu. Langganan menunjukkan penyebaran di tingkat langganan, ResourceGroup menunjukkan penyebaran ke grup sumber daya.
    • Properti lokasi harus ditentukan dalam Penyebaran saat menggunakan penyebaran tingkat langganan.
    • Defaultnya adalah ResourceGroup.
  • Penyebaran (diperlukan)

    • Properti ini harus menyertakan penyebaran templat lengkap karena akan diteruskan ke PUT API Microsoft.Resources/deployments. Untuk informasi selengkapnya, lihat REST API Penyebaran.
    • Microsoft.Resources/deployments berlapis dalam templat harus menggunakan nama unik untuk menghindari pertentangan antara beberapa evaluasi kebijakan. Nama penyebaran induk dapat digunakan sebagai bagian dari nama penyebaran berlapis melalui [concat('NestedDeploymentName-', uniqueString(deployment().name))].

    Catatan

    Semua fungsi di dalam properti Penyebaran dievaluasi sebagai komponen templat, bukan kebijakan. Pengecualiannya adalah properti parameter yang meneruskan nilai dari kebijakan ke templat. Nilai di bagian ini di bawah nama parameter templat digunakan untuk melakukan passing nilai ini (lihat fullDbName dalam contoh DeployIfNotExists).

Contoh DeployIfNotExists

Contoh: Mengevaluasi database SQL Server untuk menentukan apakah transparentDataEncryption diaktifkan. Jika tidak, maka penyebaran untuk mengaktifkan dijalankan.

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

Nonaktifkan

Efek ini berguna untuk menguji situasi atau ketika definisi kebijakan telah melakukan parameter pada efek. Fleksibilitas ini memungkinkan untuk menonaktifkan satu tugas, bukan menonaktifkan semua tugas kebijakan tersebut.

Alternatif untuk efek Dinonaktifkan adalah enforcementMode, yang ditetapkan pada penugasan kebijakan. Ketika enforcementModeDinonaktifkan, sumber daya masih dievaluasi. Pencatatan, seperti Log aktivitas, dan efek kebijakan tidak terjadi. Untuk informasi selengkapnya, lihat penugasan kebijakan - mode pemberlakuan.

EnforceOPAConstraint

Efek ini digunakan dengan mode definisi kebijakan Microsoft.Kubernetes.Data. Efek ini digunakan untuk meneruskan aturan kontrol penerimaan Gatekeeper v3 yang didefinisikan dengan OPA Constraint Framework ke Open Policy Agent (OPA) ke klaster Kubernetes di Azure.

Penting

Definisi kebijakan pratinjau terbatas dengan efek EnforceOPAConstraint dan kategori Layanan Kubernetes terkait ditolak. Atau, gunakan audit efek dan tolak dengan Microsoft.Kubernetes.Data mode Resource Provider.

Evaluasi EnforceOPAConstraint

Pengontrol penerimaan Open Policy Agent mengevaluasi permintaan baru pada kluster secara real time. Setiap 15 menit, pemindaian penuh kluster selesai dan hasilnya dilaporkan ke Azure Policy.

Properti EnforceOPAConstraint

Properti detail efek EnforceOPAConstraint memiliki subproperti yang menjelaskan aturan kontrol penerimaan Gatekeeper v3.

  • constraintTemplate (diperlukan)
    • CustomResourceDefinition (CRD) templat Batasan yang menentukan Batasan baru. Templat menentukan logika Rego, skema Batasan, dan parameter Batasan yang diteruskan melalui nilai dari Azure Policy.
  • batasan (diperlukan)
    • Implementasi CRD dari templat Batasan. Menggunakan parameter yang diteruskan melalui nilai sebagai {{ .Values.<valuename> }}. Dalam contoh berikut, nilai-nilai ini adalah {{ .Values.cpuLimit }} dan {{ .Values.memoryLimit }}.
  • nilai (opsional)
    • Menentukan parameter dan nilai apa pun untuk diteruskan ke Batasan. Setiap nilai harus ada di CRD templat Batasan.

Contoh EnforceOPAConstraint

Contoh: Aturan kontrol penerimaan Gatekeeper v3 untuk mengatur batas CPU kontainer dan sumber daya memori di 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

Efek ini digunakan dengan mode definisi kebijakan Microsoft.ContainerService.Data. Efek ini digunakan untuk melewati aturan kontrol penerimaan Gatekeeper v2 yang didefinisikan dengan Rego ke Open Policy Agent (OPA) pada Azure Kubernetes Service.

Penting

Definisi kebijakan pratinjau terbatas dengan efek EnforceOPAConstraint dan kategori Layanan Kubernetes terkait ditolak. Atau, gunakan audit efek dan tolak dengan Microsoft.Kubernetes.Data mode Resource Provider.

Evaluasi EnforceRegoPolicy

Pengontrol penerimaan Open Policy Agent mengevaluasi permintaan baru pada kluster secara real time. Setiap 15 menit, pemindaian penuh kluster selesai dan hasilnya dilaporkan ke Azure Policy.

Properti EnforceRegoPolicy

Properti detail efek EnforceOPAConstraint memiliki subproperti yang menjelaskan aturan kontrol penerimaan Gatekeeper v2.

  • policyId (diperlukan)
    • Nama unik yang diteruskan sebagai parameter ke aturan kontrol penerimaan Rego.
  • kebijakan (diperlukan)
    • Menentukan URI aturan kontrol penerimaan Rego.
  • policyParameters (opsional)
    • Menentukan parameter dan nilai apa pun untuk diteruskan ke kebijakan rego.

Contoh EnforceRegoPolicy

Contoh: Aturan kontrol penerimaan Gatekeeper v2 hanya mengizinkan gambar kontainer yang ditentukan dalam 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')]"
        }
    }
}

Mengubah

Mengubah digunakan untuk menambahkan, memperbarui, atau menghapus properti atau tag pada langganan atau sumber daya selama pembuatan atau pembaruan. Contoh umumnya adalah memperbarui tag pada sumber daya seperti costCenter. Sumber daya yang tidak sesuai dapat diremediasi dengan tugas remediasi. Satu aturan Mengubah dapat memiliki sejumlah operasi. Penetapan kebijakan dengan efek yang ditetapkan sebagai Modifikasi memerlukan identitas terkelola untuk melakukan remediasi.

Operasi berikut didukung oleh Mengubah:

  • Menambahkan, mengganti, atau menghapus tag sumber daya. Untuk tag, kebijakan Mengubah seharusnya mode diatur ke Terindeks kecuali jika sumber daya target adalah grup sumber daya.
  • Menambahkan atau mengganti nilai jenis identitas terkelola (identity.type) mesin virtual dan set skala mesin virtual.
  • Menambahkan atau mengganti nilai alias tertentu.
    • PenggunaanGet-AzPolicyAlias | Select-Object -ExpandProperty 'Aliases' | Where-Object { $_.DefaultMetadata.Attributes -eq 'Modifiable' } di Azure PowerShell 4.6.0 atau yang lebih tinggi untuk mendapatkan daftar alias yang dapat digunakan dengan Modifikasi.

Penting

Jika Anda mengelola tag, disarankan untuk menggunakan Mengubah alih-alih Tambah karena Mengubah menyediakan jenis operasi tambahan dan kemampuan untuk memulihkan sumber daya yang ada. Namun, Tambah disarankan jika Anda tidak dapat membuat identitas terkelola atau Mengubahi belum mendukung alias untuk properti sumber daya.

Evaluasi mengubah

Mengubah mengevaluasi sebelum permintaan diproses oleh Resource Provider selama pembuatan atau pembaruan sumber daya. Operasi Mengubah diterapkan ke konten permintaan saat kondisi jika dari aturan kebijakan terpenuhi. Setiap operasi Mengubah dapat menentukan kondisi yang menentukan kapan efek ini diterapkan. Operasi dengan kondisi yang dievaluasi ke false dilewati.

Saat alias ditentukan, pemeriksaan tambahan berikut dilakukan untuk memastikan bahwa operasi Mengubah tidak mengubah konten permintaan dengan menyebabkan penyedia sumber daya menolaknya:

  • Properti tempat peta alias ditandai sebagai 'Dapat Diubah' dalam versi API permintaan.
  • Jenis token dalam operasi Mengubah cocok dengan jenis token yang diharapkan untuk properti dalam versi API permintaan.

Jika salah satu dari pemeriksaan ini gagal, evaluasi kebijakan akan kembali ke conflictEffect yang ditentukan.

Penting

Definisi Modifikasi yang menyertakan alias disarankan untuk menggunakan efek konflikaudit guna menghindari permintaan yang gagal menggunakan versi API ketika properti yang dipetakan tidak 'Dapat Diubah’. Jika alias yang sama berperilaku berbeda antara versi API, operasi mengubah bersyarat dapat digunakan untuk menentukan operasi mengubah yang digunakan untuk setiap versi API.

Ketika definisi kebijakan yang menggunakan efek Mengubah dijalankan sebagai bagian dari siklus evaluasi, hal ini tidak membuat perubahan pada sumber daya yang sudah ada. Sebaliknya, hal ini menandai sumber daya apa pun yang memenuhi kondisi jika sebagai tidak patuh.

Properti mengubah

Properti detail efek Mengubah memiliki semua subproperi yang menentukan izin yang diperlukan untuk perbaikan dan operasi yang digunakan untuk menambahkan, memperbarui, atau menghapus nilai tag.

  • roleDefinitionIds (diperlukan)
    • Properti ini harus menyertakan serangkaian untai (karakter) yang cocok dengan ID peran kontrol akses berbasis peran yang dapat diakses oleh langganan. Untuk informasi selengkapnya, lihat remediasi - mengonfigurasi definisi kebijakan.
    • Peran yang ditentukan harus mencakup semua operasi yang diberikan kepada peran Kontributor.
  • konflikEffect (opsional)
    • Menentukan definisi kebijakan mana yang "menang" jika lebih dari satu definisi kebijakan mengubah properti yang sama atau ketika operasi mengubah tidak berfungsi pada alias yang ditentukan.
      • Untuk sumber daya baru atau yang diperbarui, definisi kebijakan dengan tolak diutamakan. Definisi kebijakan dengan audit melewati semua operasi. Jika lebih dari satu definisi kebijakan memiliki tolak, permintaan ditolak sebagai konflik. Jika semua definisi kebijakan memiliki audit, maka tidak ada operasi definisi kebijakan yang bertentangan yang diproses.
      • Untuk sumber daya yang ada, jika lebih dari satu definisi kebijakan memiliki tolak, status kepatuhan adalah Konflik. Jika satu atau lebih sedikit definisi kebijaka memiliki tolak, setiap penugasan mengembalikan status kepatuhan Yang tidak mematuhi.
    • Nilai yang tersedia: audit, , tolak. dinonaktifkan.
    • Nilai defaultnya adalah tolak.
  • operasi (diperlukan)
    • Array semua operasi tag yang akan diselesaikan pada sumber daya yang cocok.
    • Properti:
      • operasi (diperlukan)
        • Menentukan tindakan apa yang harus diambil pada sumber daya yang cocok. Opsinya adalah: addOrReplace, Tambahkan, Hapus. Tambah berperilaku mirip dengan efek Tambah.
      • bidang (diperlukan)
        • Tag untuk menambahkan, mengganti, atau menghapus. Nama tag harus mematuhi konvensi penamaan yang sama untuk bidang lain.
      • nilai (opsional)
        • Nilai untuk mengatur tag ke.
        • Properti ini diperlukan jika operasi adalah addOrReplace atau Tambahkan.
      • kondisi (opsional)
        • Untai (karakter) yang berisi ekspresi bahasa Azure Policy dengan Fungsi kebijakan yang dievaluasi ke true atau false.
        • Tidak mendukung fungsi Azure Policy berikut: field(), resourceGroup(), subscription().

Operasi mengubah

Array properti operasi memungkinkan untuk mengubah beberapa tag dengan cara yang berbeda dari satu definisi kebijakan. Setiap operasi terdiri dari operasi, , bidang, dan properti nilai. Operasi menentukan apa yang dilakukan tugas remediasi pada tag, bidang menentukan tag mana yang diubah, dan nilai menentukan pengaturan baru untuk tag tersebut. Contoh berikut membuat perubahan tag berikut:

  • Mengatur environment tag ke "Uji", bahkan jika sudah ada dengan nilai yang berbeda.
  • Menghapus tag TempResource.
  • Menyetel Dept tag ke parameter kebijakan DeptName yang dikonfigurasi pada penugasan kebijakan.
"details": {
    ...
    "operations": [
        {
            "operation": "addOrReplace",
            "field": "tags['environment']",
            "value": "Test"
        },
        {
            "operation": "Remove",
            "field": "tags['TempResource']",
        },
        {
            "operation": "addOrReplace",
            "field": "tags['Dept']",
            "value": "[parameters('DeptName')]"
        }
    ]
}

Properti operasi memiliki opsi berikut:

Operasi Deskripsi
addOrReplace Menambahkan properti atau tag dan nilai yang ditentukan ke sumber daya, meskipun properti atau tag sudah ada dengan nilai yang berbeda.
Menambahkan Menambahkan properti atau tag dan nilai yang ditentukan ke sumber daya.
Hapus Menghapus properti atau tag yang ditentukan dari sumber daya.

Contoh mengubah

Contoh 1: Tambahkan environment tag dan ganti environment tag yang ada dengan "Uji":

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

Contoh 2: Hapus env tag dan tambahkan environment tag atau ganti environment tag yang ada dengan nilai parameter:

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

Contoh 3: Pastikan bahwa akun penyimpanan tidak mengizinkan akses publik blob, operasi Mengubah hanya diterapkan saat mengevaluasi permintaan dengan versi API yang lebih besar atau sama dengan '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
            }
        ]
    }
}

Definisi kebijakan lapisan

Sumber daya mungkin dipengaruhi oleh beberapa penugasan. Penugasan in mungkin berada pada lingkup yang sama atau pada cakupan yang berbeda. Masing-masing penugasan ini juga cenderung memiliki efek yang berbeda yang ditentukan. Kondisi dan efek untuk setiap kebijakan dievaluasi secara independen. Contohnya:

  • Azure Policy 1
    • Membatasi lokasi sumber daya ke 'westus'
    • Ditetapkan ke langganan A
    • Efek tolak
  • Azure Policy 2
    • Membatasi lokasi sumber daya ke 'eastus'
    • Ditugaskan ke grup sumber daya B dalam langganan A
    • Efek audit

Penyiapan ini akan memberikan hasil berikut:

  • Sumber daya apa pun yang sudah berada di grup sumber daya B di 'eastus' mematuhi kebijakan 2 dan tidak mematuhi kebijakan 1
  • Sumber daya apa pun yang sudah berada di grup sumber daya B yang bukan di 'eastus' mematuhi kebijakan 2 dan tidak mematuhi kebijakan 1 jika tidak berada di ‘westus’
  • Sumber daya baru dalam langganan A yang tidak ada di 'westus' ditolak oleh kebijakan 1
  • Setiap sumber daya baru dalam langganan A dan grup sumber daya B di 'westus' dibuat dan tidak mematuhi kebijakan 2

Jika kebijakan 1 dan kebijakan 2 berpengaruh pada efek tolak, situasi berubah menjadi:

  • Sumber daya apa pun yang sudah ada di grup sumber daya B yang tidak berada di 'eastus' tidak mematuhi kebijakan 2
  • Sumber daya apa pun yang sudah ada di grup sumber daya B yang tidak berada di 'eastus' tidak mematuhi kebijakan 1
  • Sumber daya baru dalam langganan A yang tidak ada di 'westus' ditolak oleh kebijakan 1
  • Sumber daya baru dalam grup sumber daya B langganan A ditolak

Setiap penugasan dievaluasi satu per satu. Dengan demikian, tidak ada kesempatan bagi sumber daya untuk menyelinap melalui celah dari perbedaan ruang lingkup. Hasil bersih dari definisi kebijakan lapisan dianggap kumulatif yang paling ketat. Misalnya, jika kebijakan 1 dan 2 memiliki efek tolak, sumber daya akan diblokir oleh definisi kebijakan yang tumpang tindih dan bertentangan. Jika Anda masih memerlukan sumber daya untuk dibuat dalam lingkup target, tinjau pengecualian pada setiap tugas untuk memvalidasi penetapan kebijakan yang tepat memengaruhi cakupan yang tepat.

Langkah berikutnya