Azure Policy 定義の modify 効果
modify
効果は、作成時または更新時に、サブスクリプションまたはリソースのプロパティまたはタグを追加、更新、または削除するために使用されます。 また、既存の非準拠リソースを修復タスクで修復することもできます。 Modify として設定された有効なポリシー割り当てには、修復を行うための マネージド ID が必要です。
modify
を使用する一般的な例としては、'costCenter' などのリソースでタグを更新することが挙げられます。
リソース プロパティの変更動作には、いくつかの微妙な違いがあります。 変更がスキップされるシナリオの詳細について説明します。
1 つの modify
規則には、任意の数の操作を含めることができます。 サポートされている操作は次のとおりです。
- リソース タグの追加、置換、または削除。 タグのみを削除できます。 タグに関して、ターゲット リソースがリソース グループでない限り、Modify ポリシーでは常に mode が
indexed
に設定されている必要があります。 - 仮想マシンと仮想マシン スケール セットのマネージド ID の種類 (
identity.type
) の値の追加または置換。 仮想マシンまたは Virtual Machine Scale Sets では、identity.type
のみを変更できます。 - 特定のエイリアスの値の追加または置換。
-
modify
で使用できるエイリアスの一覧を取得するには、Azure PowerShell 4.6.0 以降でGet-AzPolicyAlias | Select-Object -ExpandProperty 'Aliases' | Where-Object { $_.DefaultMetadata.Attributes -eq 'Modifiable' }
を使用します。
-
重要
タグを管理している場合は、Append ではなく Modify を使用することをお勧めします。Modify ではより多くの操作タイプと、既存のリソースを修復する機能が提供されるためです。 ただし、マネージド ID を作成できない場合や、リソース プロパティのエイリアスが Modify でまだサポートされていない場合は、Append を使用することをお勧めします。
Modify の評価
リソースを作成中または更新中に、リソース プロバイダーによって要求が処理される前に Modify による評価が行われます。 ポリシー ルールの if
条件が満たされた場合、要求コンテンツに modify
操作が適用されます。 各 modify
操作では、適用されるタイミングを決定する条件を指定できます。
エイリアスが指定されているときは、modify
操作による要求コンテンツの変更の結果としてリソース プロバイダーに拒否されることがないようにするために、次の追加のチェックが実行されます。
- エイリアスのマップ先のプロパティは、要求の API バージョンでは Modifiable としてマークされています。
-
modify
操作のトークンの種類は、要求の API バージョンのプロパティで想定されるトークンの種類と一致します。
これらのチェックのいずれかが失敗した場合、ポリシー評価は指定された conflictEffect
にフォールバックします。
重要
エイリアスを含む Modify の定義では、auditconflict 効果を使用して、マッピングされたプロパティが Modifiable でないバージョンの API を使用して要求を送信した場合に、その要求が失敗する事態を避けることをお勧めします。 API バージョン間で同じエイリアスの動作が異なる場合は、条件付き modify 操作を使用して、各 API バージョンで使用される modify
操作を決定できます。
スキップされる変更
次のように、評価時に変更操作がスキップされる場合があります。
-
既存のリソース:
modify
効果を使用するポリシー定義が評価サイクルの一部として実行される場合、既存のリソースに対する変更は行われません。 代わりに、if
条件を満たすリソースはすべて非準拠としてマークされるため、それらを修復タスクを通じて修復できます。 -
適用外:
operations
配列内の操作の条件を評価した結果が false のときは、その操作はスキップされます。 -
変更不可のプロパティ: ある操作に対して指定されたエイリアスが要求の API バージョンでは変更不可の場合は、conflict effect が評価に使用されます。 conflict effect が deny に設定されている場合は、その要求はブロックされます。 conflict effect が audit に設定されている場合は、その要求は許可されますが、
modify
操作はスキップされます。 -
存在しないプロパティ: 要求のリソース ペイロードにプロパティが存在しない場合は、変更がスキップされる可能性があります。 場合によっては、変更可能なプロパティが他のプロパティ内に入れ子になっていて
Microsoft.Storage/storageAccounts/blobServices/deleteRetentionPolicy.enabled
のようなエイリアスを持つことがあります。 "親" プロパティ (この例ではdeleteRetentionPolicy
) が要求内に存在しない場合は、そのプロパティが意図的に省略されたと見なされるため、変更はスキップされます。 実際の例については、「存在しないプロパティの例」セクションを参照してください。 -
非 VM または VMSS の ID 操作: 仮想マシンまたは仮想マシン スケール セット以外のリソースの
identity.type
フィールドの追加または置換を変更操作で試みたときは、ポリシー評価全体がスキップされ、したがって変更は実行されません。 この場合は、そのリソースはポリシーに適用可能とは見なされません。
存在しないプロパティの例
リソース プロパティの変更は、API 要求および更新されるリソース ペイロードによって異なります。 ペイロードは、Azure portal などの使用されるクライアントと、リソース プロバイダーなどのその他の要因によって異なります。
仮想マシン (VM) のタグを変更するポリシーを適用するとします。 サイズ変更中やディスクの変更中など、VM が更新されるたびに、VM ペイロードの内容に関係なくタグが更新されます。 これは、タグが VM のプロパティに依存しないためです。
ただし、VM のプロパティを変更するポリシーを適用する場合、変更はリソース ペイロードに依存します。 更新ペイロードに含まれていないプロパティを変更しようとしても、変更は行われません。 たとえば、これは、VM の assessmentMode
プロパティ (エイリアス Microsoft.Compute/virtualMachines/osProfile.windowsConfiguration.patchSettings.assessmentMode
) にパッチを適用するときに発生する可能性があります。 プロパティは "入れ子になっている" ため、その親プロパティが要求に含まれていない場合、この省略は意図的なものとみなされ、変更はスキップされます。 変更を行うには、リソース ペイロードにこのコンテキストが含まれている必要があります。
Modify のプロパティ
modify
効果の details
プロパティには、修復に必要なアクセス許可を定義するすべてのサブプロパティと、タグ値の追加、更新、または削除に使用する operations
が含まれます。
-
roleDefinitionIds
(必須)- このプロパティには、サブスクリプションでアクセス可能なロールベースのアクセス制御ロール ID と一致する文字列の配列を含める必要があります。 詳細については、修復 - ポリシー定義の構成に関するページを参照してください。
- 定義されたロールには、Contributor ロールに与えられているすべての操作が含まれている必要があります。
-
conflictEffect
(省略可)- 複数のポリシー定義によって同じプロパティが変更された場合、または
modify
操作が指定したエイリアスで動作しない場合に、どのポリシー定義を "優先" するかを決定します。- 新規または更新されたリソースについては、Deny を持つポリシー定義が優先されます。
Audit のポリシー定義では、すべての
operations
がスキップされます。 複数のポリシー定義に Deny 効果がある場合、その要求は競合として拒否されます。 すべてのポリシー定義に Audit がある場合、競合しているポリシー定義のどのoperations
も処理されません。 - 既存のリソースについては、複数のポリシー定義に Deny 効果がある場合、コンプライアンス状態は競合になります。 Deny 効果があるポリシー定義が 1 つ以下の場合、各割り当ては非準拠のコンプライアンス状態を返します。
- 新規または更新されたリソースについては、Deny を持つポリシー定義が優先されます。
Audit のポリシー定義では、すべての
- 使用可能な値は、Audit、Deny、Disabled です。
- 既定値は Deny です。
- 複数のポリシー定義によって同じプロパティが変更された場合、または
-
operations
(必須)- 一致するリソースで完了されるすべてのタグ操作の配列です。
- プロパティ:
-
operation
(必須)- 一致するリソースに対して実行するアクションを定義します。 オプションは
addOrReplace
、Add
、Remove
です。 -
Add
の動作は append 効果に似ています。 -
Remove
はリソース タグに対してのみサポートされます。
- 一致するリソースに対して実行するアクションを定義します。 オプションは
-
field
(必須)- 追加、置換、または削除するタグです。 タグ名は、他の fields と同じ名前付け規則に従う必要があります。
-
value
(省略可)- タグに設定する値です。
- このプロパティは、
operation
が addOrReplace または Add の場合に必要です。
-
condition
(省略可)- true または false として評価されるポリシー関数による Azure Policy 言語式を含む文字列です。
-
field()
、resourceGroup()
、subscription()
の各ポリシー関数はサポートされていません。
-
Modify の操作
operations
プロパティ配列を使用すると、1 つのポリシー定義から複数のタグを異なる方法で変更できます。 各操作は、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
タグを追加し、既存の environment
タグを "Test" に置き換えます。
"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 のパブリック アクセスが許可されていないことを確認します。次のように、modify
操作は、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
}
]
}
}
次のステップ
- Azure Policy のサンプルを確認します。
- 「Azure Policy の定義の構造」を確認します。
- プログラムによってポリシーを作成する方法を理解します。
- コンプライアンス データを取得する方法を学習します。
- 準拠していないリソースを修復する方法を学習します。
- Azure 管理グループを確認する。