Azure 原則定義修改效果
modify
效果用於在建立或更新期間在訂用帳戶或資源上新增、更新或移除屬性或標記。 現有的不符合規範的資源也可以使用補救工作來補救。 將效果設定為 Modify 的原則指派需要受控識別才能進行補救。 使用 modify
效果的常見範例是更新 『costCenter』 等資源上的標記。
資源屬性的修改行為有些細微差別。 深入瞭解略過修改時的案例。
單 modify
一規則可以有任意數目的作業。 支援的作業包括:
- 新增、 取代或 移除 資源標籤。 只能移除標籤。 針對標記,除非目標資源是資源群組,否則 Modify 原則應將 mode 設定為
indexed
。 - 新增 或 取代 虛擬機器和虛擬機器擴展集受控識別類型 (
identity.type
) 的值。 您只能修改虛擬機器或虛擬機器擴展集的identity.type
。 - 新增 或 取代 特定別名的值。
- 在 Azure PowerShell 4.6.0 或更高版本中使用
Get-AzPolicyAlias | Select-Object -ExpandProperty 'Aliases' | Where-Object { $_.DefaultMetadata.Attributes -eq 'Modifiable' }
,以取得可與modify
搭配使用的別名清單。
- 在 Azure PowerShell 4.6.0 或更高版本中使用
重要
如果您要管理標記,建議使用 Modify 而非 Append,因為 Modify 可提供更多的作業類型,且能補救現有的資源。 不過,如果您無法建立受控識別或 Modify 尚不支援資源屬性的別名,建議您使用 Append。
Modify 評估
在建立或更新資源期間,會先由 Modify 進行評估,然後才由「資源提供者」處理要求。 當符合原則規則的 if
條件時,modify
作業會套用至要求內容。 每個 modify
作業都可以指定條件,以決定套用的時間。
指定別名時會執行更多檢查,以確保 modify
作業變更要求內容的方式不會使資源提供者拒絕此變更:
- 別名對應的屬性會在要求的 API 版本中標示為「可修改」。
modify
作業中的權杖類型會符合要求 API 版本中屬性的預期權杖類型。
如果其中一項檢查失敗,原則評估會回復為指定的 conflictEffect
。
重要
建議包含別名的 Modify 定義使用 audit 衝突效果,以避免要求使用對應屬性不是「可修改」的 API 版本時失敗。 如果相同別名在 API 版本之間的運作方式不同,則可以使用條件式 modify
作業來判斷每個 API 版本所使用的修改作業。
略過修改
在某些情況下,評估期間會略過修改作業:
- 現有資源: 當使用
modify
效果的原則定義在評估週期中執行時,它不會對已經存在的資源進行變更。 相反地,它會將符合if
條件的任何資源標示為不符合規範,以便透過補救工作加以補救。 - 不適用: 當陣列中的
operations
作業條件評估為 false 時,會略過該特定作業。 - 屬性不可修改: 如果為作業指定的別名無法在要求的 API 版本中修改,則評估會使用衝突效果。 如果衝突效果設定為 拒絕,則會封鎖要求。 如果衝突效果設定為 稽核,則會允許透過 要求,但
modify
略過作業。 - 屬性不存在: 如果屬性不存在於要求的資源承載中,則可以略過修改。 在某些情況下,可修改的屬性會以巢狀方式存在於其他屬性內,而且具有類似
Microsoft.Storage/storageAccounts/blobServices/deleteRetentionPolicy.enabled
的別名。 如果在此案例deleteRetentionPolicy
中要求裡不存在「父代」屬性,則會略過修改,因為會假設刻意省略該屬性。 如需實用範例,請移至屬性不存在的範例一節。 - 非 VM 或 VMSS 身分識別作業: 當修改作業嘗試新增或取代
identity.type
虛擬機或虛擬機擴展集以外的資源上的欄位時,會完全略過原則評估,因此不會執行修改。 在此情況下,不會將資源視為 適用於 原則。
屬性不存在的範例
修改資源屬性取決於 API 要求和更新的資源承載。 承載取決於使用的用戶端,例如 Azure 入口網站,以及資源提供者等其他因素。
假設您套用原則來修改虛擬機 (VM) 上的標籤。 每次更新 VM,例如在重設大小或磁碟變更期間,無論 VM 承載的內容為何,標記都會隨之更新。 這是因為標籤與 VM 屬性無關。
不過,如果您套用原則來修改 VM 上的屬性,修改會取決於資源承載。 如果您嘗試修改更新承載中未包含的屬性,將不會進行修改。 例如,修補 VM 的 屬性時 assessmentMode
,可能會發生這種情況(別名 Microsoft.Compute/virtualMachines/osProfile.windowsConfiguration.patchSettings.assessmentMode
)。 屬性為「巢狀」,因此如果其父屬性未包含在要求中,則會假設此遺漏是刻意的,並略過修改。 若要進行修改,資源承載應包含此內容。
Modify 屬性
modify
效果的 details
屬性,含有用於定義修補所需權限的所有子屬性,以及可用於新增、更新或移除目標值的 operations
。
roleDefinitionIds
(必要)- 此屬性必須包含與訂用帳戶可存取之角色型存取控制角色識別碼相符的字串陣列。 如需詳細資訊,請參閱補救 - 設定原則定義。
- 定義的角色必須包含授與給參與者角色的所有作業。
conflictEffect
(選擇性)- 如果多個原則定義修改相同的屬性,或當
modify
作業無法在指定的別名上運作時,判斷哪一個原則定義「優先」。- 對於新的或更新的資源,具有 deny 的原則定義優先。 具有 audit 的原則定義會略過所有
operations
。 如果多個原則定義都有 deny 效果,則要求會因為衝突。 如果所有原則定義都有 audit,則不會處理衝突原則定義的任何operations
。 - 針對現有的資源,如果多個原則定義都有 deny 效果,則合規性狀態為衝突。 如果一個或較少原則定義具有 deny 效果,則每個指派都會傳回 Non-compliant 的合規性狀態。
- 對於新的或更新的資源,具有 deny 的原則定義優先。 具有 audit 的原則定義會略過所有
- 可用的值:audit、deny、disabled。
- 預設值是 deny。
- 如果多個原則定義修改相同的屬性,或當
operations
(必要)- 在比對資源上所有待完成標記作業的陣列。
- 屬性:
operation
(必要)- 定義要對相符資源採取的動作。 選項為:
addOrReplace
、Add
和Remove
。 Add
的行為類似於 Append 效果。Remove
僅支援資源標籤。
- 定義要對相符資源採取的動作。 選項為:
field
(必要)- 要新增、取代或移除的標記。 標記名稱必須遵守其他欄位的相同命名慣例。
value
(選擇性)- 標記所要設定的值。
- 如果
operation
為 addOrReplace 或 Add,則此屬性為必要。
condition
(選擇性)- 包含 Azure 原則語言運算式的字串,搭配會評估為 true 或 false 的原則函式。
- 不支援下列原則函式:
field()
、resourceGroup()
、subscription()
。
Modify 作業
operations
屬性陣列有數種不同的方法可更改單一原則定義中的數個標記。 每個作業都是由 operation
、field
和 value
屬性所組成。 operation
會決定工作要對標籤執行何種補救工作,field
會決定要更改的標籤,而 value
則會定義該標籤的新設定。 以下範例會進行下列標記變更:
- 將
environment
標記設定為 "Test",即使該標記已存在且具有不同的值。 - 移除標記
TempResource
。 - 將
Dept
標記設定為在原則指派上設定的原則參數 DeptName。
"details": {
...
"operations": [
{
"operation": "addOrReplace",
"field": "tags['environment']",
"value": "Test"
},
{
"operation": "Remove",
"field": "tags['TempResource']",
},
{
"operation": "addOrReplace",
"field": "tags['Dept']",
"value": "[parameters('DeptName')]"
}
]
}
operation
屬性具有以下選項:
作業 | 描述 |
---|---|
addOrReplace |
將定義的屬性或標記和值新增至資源,即使屬性或標記已經存在且具有不同的值。 |
add |
將定義的屬性或標記和值新增至資源。 |
remove |
將定義的標記從資源中移除。 僅支援標籤。 |
Modify 範例
範例 1:新增 environment
標記,並以 "Test" 取代現有的 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
的要求時,才會套用 modify
作業:
"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
}
]
}
}
下一步
- 在 Azure 原則範例檢閱範例。
- 檢閱 Azure 原則定義結構。
- 了解如何以程式設計方式建立原則。
- 了解如何取得合規性資料。
- 了解如何補救不符合規範的資源。
- 檢閱 Azure 管理群組。