こんにちは、コンテナソリューション事業部の髙井です。
今回は「爆速で理解する」シリーズの第1弾、Azure Policyです。
いつまで続くかわかりませんが、勝手に始めようと思います。できるだけ初学者でもわかるように書いていくつもりです。
Azure Policyとは
いきなり言われてもポカーンなので、理解のためにまず、Azure Policyがない場合を考えましょう。
あなたの所属する組織で、お偉いさんAから「コスト削減のため検証環境ではAzure Firewallを使わないように」という通達があったとします。
このルールは、通達を読んだ人にしか伝わらないですし、管理者は検証環境にAzure Firewallがデプロイされていないか、逐一チェックしておかなければなりません。
さらにお偉いさんAが異動になって、お偉いさんBが来ました。さて、この通達は変わらず有効なんでしょうか？
もう、こういうの考えただけでもウンザリしますよね。
上のようなケースでなくても、たとえばAzure利用上のルールブックが5000ページあったら、到底読み切れなくて準拠しているかどうか、すぐには分かりっこないですよね。
そこで、「システムが自動で判別してくれ、なんなら勝手に直してくれ」と思うのが人情でしょう。
はい、そうです。それがAzure Policyです。
RBACとの違い
似てるようで違う概念にRBACがあります。ここで違いをしっかり押さえておきましょう。
公式ドキュメントでは、Azure Policyは「既定で許可し、明示的に拒否するシステム」と書かれていたりします。
人によっては、ホワイトリスト形式とブラックリスト形式と呼んだほうが、なじみ深いかもしれません。
また、RBACはあくまで〈ユーザー〉に焦点が置かれています。より厳密にいうと、ユーザーは人間に限らないので〈操作主体〉と言うべきかもしれません。
対するAzure Policyは〈対象範囲〉に焦点が置かれています。これをAzureでは〈スコープ〉と表現します。
「このサブスクリプションではダメ」とか「このリソースグループではダメ」といったイメージですね。
Azure Policyのスコープ
Azure Policyがとれるスコープは、Microsoft Learnの言葉を借りると、以下の範囲です。
"スコープ" という用語は、ポリシー定義が割り当てられる、すべてのリソース、リソース グループ、サブスクリプション、または管理グループのことを指します。
管理グループからリソースまで、好きな範囲でポリシーを適用することができるということです。くどいですが、適用範囲は〈だれ〉ではなく〈どこ〉です。
Azure Policyは重ね掛けが有効
ここで、親子関係にあるスコープに別々のポリシーを設定した場合を考えてみましょう。
図の右側、サブスクリプションAにおいてポリシーが重ね掛けされていることがわかるかと思います。
このようにAzure Policyでは上位スコープの設定は原則として下位まで及びます。
ちなみに現在はプレビューですが、より柔軟な使用方法として、下位スコープの一部を除外スコープとして設定可能な〈適用除外〉という機能もあります。
Azure Policyの効果6種類
では、具体的にAzure Policyでどんな制御が可能なのかを見ていきましょう。6種類ありますが、これらはポリシーの〈効果〉と呼ばれます。
これだけだと、少し理解が難しいかもしれません。これらはポリシーがどんなタイミングで評価されるのかと密接に絡んでおり、そちらの理解が必要になるからです。
ポリシー効果ごとの評価タイミング
ポリシーの評価がいつ行われるかですが、基本的にはリソースのデプロイ時に評価されます1。
ここで、デプロイというのは、新規作成も変更もどちらも含みます。
このように、効果によって評価されるタイミングが異なります。
なかでもIfNotExistsの2つはピンとこないかもしれません。これのキモは、いま直接デプロイしているリソースではないリソースも含めた評価をしたいときに使えることです。
たとえば、「App Serviceを使っているときは、Microsoft Defender for App Serviceを有効にする必要がある」などです。
Microsoft Defender for App Serviceは、App Serviceそのものとはまったく別のサービスです。しかし、実現したいルールとしては依存関係があります。
そんなときにdeployIfNotExistsを使って、App Serviceデプロイ後にMicrosoft Defender for App Serviceを自動で有効にするなどの利用ケースが考えられます。
どんなルールを設定できるのか
次に気になるのがどこまで細かい制御ができるのか、という点だと思います。
ちょっと大雑把な書き方ですが、このあたりは日進月歩で設定できる項目が増えたりしているので、実際に試してみるのが早い領域でもあります。
ARMテンプレートと利用するエイリアスは共通ですので、ARMテンプレートに書けることは一部の例外を除いてPolicyルールとして指定できます。
エイリアスとは、指定する各プロパティやリソースの種別の指定子のことで、たとえばMicrosoft.Web/serverfarmsなどです。ARMテンプレートを見たことがないとわからないかもしれません。
組み込みポリシー
エイリアスやARMテンプレートに関する知識は、ユーザーが定義するカスタムポリシーで必要になりますが、分からない方も安心してください。
汎用的なルールはAzureが〈組み込みポリシー〉として前もって用意してくれているので、最初はそれらを利用することができます。
具体的な手順は省きますが、Azure Portalで何回かポチポチするだけで設定完了できます。便利です。
ちなみに、Azure Portalでポリシーを設定しようとすると〈イニシアチブ〉という単語が出てきますが、これは複数のポリシーをまとめて1つとして扱えるようにしたものだと思ってください。
たとえばポリシーが100個あったとして、いちいち1つずつ設定してたらキリがないですよね。ですので、100個まとめて適用できるようにセットとして事前にまとめておくのがイニシアチブです。
カスタムポリシー
より細やかな制御を必要とする場合は、〈カスタムポリシー〉を自分で作成します。
具体的には、ポリシーを定義するJSONファイルを記述することになります。このあたりはIaCについて事前に学んでおくと効率がよいかもしれません。
ARMテンプレートをより簡潔に記述できるAzure Bicep入門のシリーズ記事がありますので、そちらでIaCについて学ぶことができます。
おわりに
今回はAzure Policyの概観について爆速でお届けしました。
カスタムポリシーの記述方法なども、機会があれば2また別の記事でまとめようかと思います！
それでは、今回はここまで！
