次の方法で共有

Azure Policy 割り当ての安全なデプロイ

  • [アーティクル]

環境が拡大するにつれて、段階的な露出制御を備えた、制御された継続的デプロイ (CD) パイプラインの需要も増加します。 そのため、Microsoft では、DevOps チームが安全なデプロイ プラクティス (SDP) フレームワークに従うことをお勧めしています。 Azure Policy の定義と割り当ての安全なデプロイは、ポリシー リソースの意図しない動作の影響を制限するのに役立ちます。

Azure Policy を使用して SDP を実装する大まかなアプローチは、リング単位でポリシーの割り当てを徐々にロールアウトし、環境に影響を与えるポリシーの変更を、重要なクラウド インフラストラクチャに影響を与える前に早い段階で検出するというものです。

デプロイのリングは、さまざまな方法で編成できます。 この攻略チュートリアルでは、リングは、異なる Azure リージョンで分割されています。"リング 0" は、重要ではないトラフィックの少ない場所を表し、"リング 5" は、最も重要でトラフィックの最も多い場所を示します。

拒否または追加の効果を持つ Azure Policy 割り当てを安全にデプロイするための手順

deny または append のポリシー効果を使用する Azure Policy 割り当てに SDP フレームワークを適用する方法を説明していくなかで、次のフローチャートをリファレンスとして使用します。

注意

Azure ポリシー効果の詳細については、「効果のしくみを理解する」を参照してください。

新しい Azure Policy 定義の安全なデプロイ プラクティスを示す、ステップ 1 から 8 のフローチャート。

フローチャートのステップ番号:

  1. ポリシー定義を選択したら、すべての展開リングを含む最上位レベルのスコープでポリシーを割り当てます。 "リソース セレクター" を適用し、"kind": "resource location" プロパティを使用して最も重要度の低いリングに適用対象を絞り込みます。 "割り当てのオーバーライド" を使用して audit 効果の種類を構成します。 eastUS の場所と audit の効果を使用するサンプル セレクター:

    "resourceSelectors": [{ 
  "name": "SDPRegions", 
  "selectors": [{
      "kind": "resourceLocation",
      "in": [ "eastUS" ] 
  }]
}], 
"overrides":[{ 
  "kind": "policyEffect", 
  "value": "Audit" 
}]

  2. 割り当てがデプロイされ、最初のコンプライアンス スキャンが完了したら、コンプライアンスの結果が期待どおりであることを検証します。

    コンプライアンス チェックを実行する自動テストも構成する必要があります。 コンプライアンス チェックには、次のロジックが含まれている必要があります。

    • コンプライアンスの結果を収集する
    • コンプライアンスの結果が期待どおりの場合は、パイプラインを続行する
    • コンプライアンスの結果が期待どおりでない場合は、パイプラインを失敗とし、デバッグを開始する

    たとえば、特定の継続的インテグレーション/継続的デプロイ (CI/CD) パイプライン内で他のツールを使用して、コンプライアンス チェックを構成できます。

    ロールアウトの各段階で、アプリケーションの正常性チェックによって、サービスの安定性とポリシーの影響を確認する必要があります。 アプリケーションの構成が原因で結果が期待どおりでない場合は、必要に応じてアプリケーションをリファクターします。

  3. リソース セレクターのプロパティ値を展開して次のリングの場所を含めるとともに、 想定されるコンプライアンス結果とアプリケーションの正常性を検証して、繰り返します。 場所の値を追加したセレクターの例を以下に示します。

    "resourceSelectors": [{ 
  "name": "SDPRegions", 
  "selectors": [{
      "kind": "resourceLocation",
      "in": [ "eastUS", "westUS"] 
  }]
}]

  4. audit モードを使用してポリシーがすべてのリングに正常に割り当てられたら、パイプラインはポリシー効果を deny に変更するタスクをトリガーし、リソース セレクターを "リング 0" に関連付けられている場所にリセットする必要があります。 1 つのリージョンと効果を deny に設定したセレクターの例を以下に示します。

    "resourceSelectors": [{ 
  "name": "SDPRegions", 
  "selectors": [{
      "kind": "resourceLocation",
      "in": [ "eastUS" ] 
  }]
}], 
"overrides":[{ 
  "kind": "policyEffect", 
  "value": "Deny" 
}]

  5. 効果が変更されたら、自動テストでは、想定どおりに適用されているかどうかをチェックする必要があります。

  6. リソース セレクターの構成にリングを追加して、繰り返します。

  7. 運用環境のすべてリングに対してこのプロセスを繰り返します。

modify または deployIfNotExists 効果を使用してAzure Policy 割り当てを安全にデプロイするための手順

modify 効果や deployIfNotExists 効果を使用するポリシーの手順では、前に説明した手順と同様に、"適用モード" を使用して修復タスクをトリガーする追加のアクションを使用します。 手順 5 から 9 が変更された次のフローチャートを確認してください。

Azure Policy の安全なデプロイ プラクティスのワークフローの手順 5 から 9 を示すフローチャート。

フローチャートのステップ番号:

  1. ポリシー定義を選択したら、すべての展開リングを含む最上位レベルのスコープでポリシーを割り当てます。 "リソース セレクター" を適用し、"kind": "resource location" プロパティを使用して最も重要度の低いリングに適用対象を絞り込みます。 DoNotEnforce への割り当ての "適用モード" を構成します。 eastUS の場所と、enforcementMode を DoNotEnforce として使用するサンプル セレクターは次のとおりです。

    "resourceSelectors": [{ 
  "name": "SDPRegions", 
  "selectors": [{
      "kind": "resourceLocation",
      "in": [ "eastUS" ] 
  }]
}], 
"enforcementMode": "DoNotEnforce"

  2. 割り当てがデプロイされ、最初のコンプライアンス スキャンが完了したら、コンプライアンスの結果が期待どおりであることを検証します。

    コンプライアンス チェックを実行する自動テストも構成する必要があります。 コンプライアンス チェックには、次のロジックが含まれている必要があります。

    • コンプライアンスの結果を収集する
    • コンプライアンスの結果が期待どおりの場合は、パイプラインを続行する
    • コンプライアンスの結果が期待どおりでない場合は、パイプラインを失敗とし、デバッグを開始する

    コンプライアンス チェックは、継続的インテグレーションと継続的デプロイ (CI/CD) パイプライン内の他のツールを使用して構成できます。

    ロールアウトの各段階で、アプリケーションの正常性チェックによって、サービスの安定性とポリシーの影響を確認する必要があります。 アプリケーションの構成が原因で結果が期待どおりでない場合は、必要に応じてアプリケーションをリファクターします。

    また、既存の準拠していないリソースを修復するには、修復タスクをトリガーすることもできます。 修復タスクによってリソースが想定どおりにコンプライアンスに移行していることを確認します。

  3. リソース セレクターのプロパティ値を展開して次のリングの場所を含めるとともに、想定されるコンプライアンス結果とアプリケーションの正常性を検証して、繰り返します。 場所の値を追加したセレクターの例を以下に示します。

    "resourceSelectors": [{ 
  "name": "SDPRegions", 
  "selectors": [{
      "kind": "resourceLocation",
      "in": [ "eastUS", "westUS"] 
  }]
}]

  4. DoNotEnforce モードを使用してすべてのリングにポリシーを正常に割り当てたら、パイプラインによって、ポリシー enforcementMode を "既定の" 有効化に変更するタスクがトリガーされ、リソース セレクターは Ring 0 に関連付けられている場所にリセットされます。 1 つのリージョンと効果を deny に設定したセレクターの例を以下に示します。

    "resourceSelectors": [{ 
  "name": "SDPRegions", 
  "selectors": [{
      "kind": "resourceLocation",
      "in": [ "eastUS" ] 
  }]
}], 
"enforcementMode": "Default",

  5. 効果が変更されたら、自動テストでは、想定どおりに適用されているかどうかをチェックする必要があります。

  6. リソース セレクターの構成にリングを追加して、繰り返します。

  7. 運用環境のすべてリングに対してこのプロセスを繰り返します。

Azure Policy 割り当て内の組み込み定義バージョンを安全に更新する手順

  1. 既存の割り当て内で、overrides を適用して、最も重要度の低いリングの定義のバージョンを更新します。 overrides の組み合わせを使用して、definitionVersion を変更し、overrides 条件内の selectors を変更して、"kind": "resource location" プロパティによって適用範囲を絞り込んでいます。 指定された場所の外部にあるリソースは、割り当て内の definitionVersion 最上位プロパティのバージョンに対して引き続き評価されます。 例では、定義のバージョン更新を 2.0.* にオーバーライドし、それを EastUs のリソースにのみ適用します。

    "overrides":[{ 
  "kind": "definitionVersion", 
  "value": "2.0.*",
  "selectors": [{
    "kind": "resourceLocation",
    "in": [ "eastus"]
  }]
}]

  2. 割り当てが更新され、最初のコンプライアンス スキャンが完了したら、コンプライアンスの結果が期待どおりであることを検証します。

    コンプライアンス チェックを実行する自動テストも構成する必要があります。 コンプライアンス チェックには、次のロジックが含まれている必要があります。

    • コンプライアンスの結果を収集する
    • コンプライアンスの結果が期待どおりの場合は、パイプラインを続行する
    • コンプライアンスの結果が期待どおりでない場合は、パイプラインを失敗とし、デバッグを開始する

    たとえば、特定の継続的インテグレーション/継続的デプロイ (CI/CD) パイプライン内で他のツールを使用して、コンプライアンス チェックを構成できます。

    ロールアウトの各段階で、アプリケーションの正常性チェックによって、サービスの安定性とポリシーの影響を確認する必要があります。 アプリケーションの構成が原因で結果が期待どおりでない場合は、必要に応じてアプリケーションをリファクターします。

  3. リソース セレクターのプロパティ値を展開して次のリングの場所を含めるとともに、 想定されるコンプライアンス結果とアプリケーションの正常性を検証して、繰り返します。 場所の値を追加した例を以下に示します。

     "overrides":[{ 
  "kind": "definitionVersion", 
  "value": "2.0",
  "selectors": [{
    "kind": "resourceLocation",
    "in": [ "eastus", "westus"]
  }]
}]

  4. _selectors 内に必要な場所をすべて正常に含めることができたら、オーバーライドを削除して、割り当て内の definitionVersion プロパティを更新できます。

"properties": {
        "displayName": "Enforce resource naming rules",
        "description": "Force resource names to begin with DeptA and end with -LC",
        "definitionVersion": "2.0.*",
}

次のステップ