Azure 原則 定義結構基本概念
Azure 原則 定義會描述資源合規性條件,以及符合條件時要採取的效果。 條件會與必要值比較資源屬性欄位或值。 資源屬性欄位是使用別名來存取。 當資源屬性欄位是陣列時,您可以使用特殊的陣列別名,選取所有陣列成員的值,並套用條件至每個陣列成員。 深入了解 條件。
藉由使用原則指派,您可以控制成本及管理資源。 例如,您可以指定只允許特定的虛擬機器類型。 或者,您可以要求資源具備特定標籤。 範圍中的指派會套用至該範圍和以下的所有資源。 如果套用原則指派至資源群組,即適用於該資源群組中的所有資源。
您可以使用 JSON 來建立包含下列項目的原則定義:
displayName
description
mode
metadata
parameters
policyRule
- 邏輯評估
effect
例如,下列 JSON 會顯示限制部署資源的原則:
{
"properties": {
"displayName": "Allowed locations",
"description": "This policy enables you to restrict the locations your organization can specify when deploying resources.",
"mode": "Indexed",
"metadata": {
"version": "1.0.0",
"category": "Locations"
},
"parameters": {
"allowedLocations": {
"type": "array",
"metadata": {
"description": "The list of locations that can be specified when deploying resources",
"strongType": "location",
"displayName": "Allowed locations"
},
"defaultValue": [
"westus2"
]
}
},
"policyRule": {
"if": {
"not": {
"field": "location",
"in": "[parameters('allowedLocations')]"
}
},
"then": {
"effect": "deny"
}
}
}
}
如需詳細資訊,請移至原則 定義架構。 Azure 原則 內建和模式位於 Azure 原則 範例中。
顯示名稱和描述
displayName
您可以使用和 description
來識別原則定義,並在使用定義時提供內容。 displayName
的長度上限為 128 個字元,description
最大長度為 512 個字元。
注意
在建立或更新原則定義期間, id
、 type
和 name
是由 JSON 外部的屬性所定義,而且在 JSON 檔案中並非必要。 透過 SDK 擷取原則定義會 id
傳回、 type
和 name
屬性作為 JSON 的一部分,但每個屬性都是與原則定義相關的唯讀資訊。
原則類型
policyType
雖然無法設定 屬性,但 SDK 會傳回三個值,並在入口網站中顯示:
Builtin
:Microsoft 提供和維護這些原則定義。Custom
:客戶建立的所有原則定義都有此值。Static
:表示具有 Microsoft 擁有權的法規合規性原則定義。 這些原則定義的合規性結果是非 Microsoft 基礎結構稽核的結果。 在 Azure 入口網站 中,此值有時會顯示為 Microsoft 管理。 如需詳細資訊,請參閱 雲端中的共同責任。
[模式]
mode
會根據原則是否以 Azure Resource Manager 屬性或 Resource Provider 屬性為目標來設定 。
Resource Manager 模式
會 mode
決定要針對原則定義評估哪些資源類型。 支援的模式如下:
all
:評估資源群組、訂用帳戶和所有資源類型indexed
:只評估支援標籤和位置的資源類型
例如,資源 Microsoft.Network/routeTables
支援標籤和位置,並在這兩種模式中進行評估。 不過,無法標記資源 Microsoft.Network/routeTables/routes
,而且不會在模式中 Indexed
評估。
建議您在大部分情況下會設定 mode
為 all
。 透過入口網站建立的所有原則定義都會 all
使用 模式。 如果您使用 PowerShell 或 Azure CLI,您可以手動指定 mode
參數。 如果原則定義不包含 mode
值,則會預設為 all
Azure PowerShell 中的 與 null
Azure CLI 中的 。 null
模式與使用 indexed
來支援回溯相容性相同。
indexed
建立強制執行標籤或位置的原則時,應該使用。 雖然不需要,但它可防止不支持標籤和位置的資源在合規性結果中顯示為不符合規範。 例外狀況是資源群組和訂用帳戶。 在資源群組或訂用帳戶上強制執行位置或標籤的原則定義應該設定mode
為 all
或類型,並特別設定或Microsoft.Resources/subscriptions/resourceGroups
Microsoft.Resources/subscriptions
類型。 如需範例,請參閱 模式:卷標 - 範例 #1。 如需支援標籤的資源清單,請參閱 標記 Azure 資源的標籤支援。
資源提供者模式
完全支援下列資源提供者模式:
Microsoft.Kubernetes.Data
用於管理 Kubernetes 叢集和元件,例如 Pod、容器和輸入。 支援 Azure Kubernetes Service 叢集和 已啟用 Azure Arc 的 Kubernetes 叢集。 使用此資源提供者模式的定義會使用效果 稽核、 拒絕和 停用。Microsoft.KeyVault.Data
用於管理 Azure 金鑰保存庫 中的保存庫和憑證。 如需這些原則定義的詳細資訊,請參閱整合 Azure 金鑰保存庫 與 Azure 原則。Microsoft.Network.Data
用於使用 Azure 原則 管理 Azure 虛擬網絡 Manager 自定義成員資格原則。
目前支援下列資源提供者模式作為 預覽:
Microsoft.ManagedHSM.Data
用於使用 Azure 原則 管理受控硬體安全性模組 (HSM) 金鑰。Microsoft.DataFactory.Data
表示使用 Azure 原則 拒絕允許清單中未指定的 Azure Data Factory 輸出流量功能變數名稱。 此資源提供者模式只會強制執行,而且不會在公開預覽版中回報合規性。Microsoft.MachineLearningServices.v2.Data
用於管理 Azure 機器學習 模型部署。 此資源提供者模式會報告新建立和更新元件的合規性。 在公開預覽期間,合規性記錄會保留 24 小時。 指派這些原則定義之前存在的模型部署不會回報合規性。
注意
除非明確指出,否則資源提供者模式僅支援內建原則定義,而且元件層級不支援豁免。
中繼資料
選擇性 metadata
屬性會儲存原則定義的相關信息。 客戶可以在 中 metadata
定義任何對組織有用的屬性和值。 不過,Azure 原則 和內建有一些常用的屬性。每個metadata
屬性的限制為1,024個字元。
一般元數據屬性
version
(string):追蹤原則定義內容版本的詳細數據。category
(string):決定 Azure 入口網站 顯示原則定義的類別。preview
(布爾值):如果原則定義為 預覽,則為 True 或 false 旗標。deprecated
(布爾值):如果原則定義標示為 已被取代,則為 True 或 false 旗標。portalReview
(string):決定是否應該在入口網站中檢閱參數,而不論所需的輸入為何。
注意
Azure 原則 服務會使用version
、 preview
和 deprecated
屬性,將變更層級傳達至內建原則定義或計劃與狀態。 的格式 version
為: {Major}.{Minor}.{Patch}
。 特定狀態,例如 已被取代 或 預覽,會附加至 version
屬性或另一個屬性中做為 布爾值。 如需 Azure 原則 內建版本方式的詳細資訊,請參閱內建版本控制。
若要深入了解原則即將淘汰或預覽的意義,請參閱預覽和已淘汰的原則。
定義位置
建立方案或原則時,必須指定定義位置。 定義位置必須是管理群組或訂用帳戶。 此位置會決定方案或原則可指派的範圍。 資源必須是定義位置階層內的直接成員或子系,才能以指派為目標。
如果定義位置是:
- 訂 用帳戶 - 只有該訂用帳戶內的資源可以指派原則定義。
- 管理群組 - 只有子管理群組和子訂閱內的資源可以指派原則定義。 如果您打算將原則定義套用至數個訂用帳戶,位置必須是包含每個訂用帳戶的管理群組。
如需詳細資訊,請參閱了解 Azure 原則範圍。
下一步
- 如需原則定義結構的詳細資訊,請移至 參數、 原則規則和 別名。
- 針對計劃,請移至 方案定義結構。
- 在 Azure 原則範例檢閱範例。
- 檢閱了解原則效果。
- 了解如何以程式設計方式建立原則。
- 了解如何取得合規性資料。
- 了解如何補救不符合規範的資源。
- 透過使用 Azure 管理群組來組織資源來檢閱何謂管理群組。
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應