はじめに
こんにちは、コンテナソリューション事業部の松崎です。
Azure Kubernetes Service (AKS) では Kubernetes 用の Azure Policy アドオン と呼ばれるオプション機能が利用可能です。2021年12月に発表された Microsoft Defender for Containers を構成する機能の１つであり、AKS のセキュリティを担保する上でとても有益な機能です。
本記事では、Kubernetes 用の Azure Policy アドオンの機能概要とその背後で使われている技術について調査した事項を共有します。まず最初に Kubernetes 用の Azure Policy アドオン の概要と全体アーキテクチャに触れ、その後、個別の要素について概要を説明していきます。
※ Microsoft Defender との連携については情報量が多くなるため、本記事の範囲外としています。
- はじめに
- 1. Kubernetes 用の Azure Policy アドオン の概要
- 2. Kubernetes 用の Azure Policy アドオン の内部の全体像
- 3. Kubernetes 用の Azure Policy アドオン の要素技術
- 終わりに
1. Kubernetes 用の Azure Policy アドオン の概要
Kubernetes 用の Azure Policy アドオン は、AKS を Azure Policy と連携させるための拡張機能です。Azure Policy は Azure リソースが組織のビジネスルールや標準( Standard )を満たすかどうかを評価するサービスで、Kubernetes 用の Azure Policy アドオン 機能を使うことで複数の AKS クラスタに一貫したガバナンスポリシーを適用することができます。より詳細な説明については以下の公式ドキュメントを参照ください。
2. Kubernetes 用の Azure Policy アドオン の内部の全体像
Kubernetes 用の Azure Policy アドオンのハイレベルなアーキテクチャは以下のようになっており、エンドツーエンドで見ると Kubernetes リソースの変更リクエストをトリガに Azure Policy で定義されたルールが検証を行う動きをします。これに際しGatekeeper v3.0 という名称の OSS 製品が中心的な機能を果たしています。(( Kubernetes 用のAzure Policy アドオンをデプロイすると、gatekeeper-system Namespace に監査用(gatekeeper-audit-xx) と Webhook 用(gatekeeper-controller-xx)計3個の pod がデプロイされます。公式ドキュメント にもその旨の記述があります。 ))(図1)
Gatekeeper v3.0 は Kubernetes の Admission Controller として動作し、Kubernetes リソースの変更リクエストに際し予め渡されたルールセットに基づき追加の検証を行います。(図2) このルールセットの定義には Rego という言語が使われます。
Kubernetes 用の Azure Policy アドオンでは、Azure Policy で定義の AKS 専用のルールセット(イニシアティブ) を Rego 形式に変換される形で実行しています。 *1
3. Kubernetes 用の Azure Policy アドオン の要素技術
Kubernetes 用の Azure Policy アドオンの内部的な動作については、前節での説明がほぼすべてなのですが、Azure Policy、Gatekeeper、Rego、Admission Control などについての知識がないと理解が難しいと思います。
そこで本節では、これらの要素技術の概要を紹介します。最初に Azure Policy の概要からスタートし、その後、その他の関連技術について説明を進めます。
3-1. Azure Policy
まず Azure Policy ですが、コンプライアンスを実現するために組織の定めた標準をポリシーとして適用させる Azure サービスです。Azure Policy を利用することで、生産性を損なわずにセキュリティ性を高める「ガードレール」*2を実現することができます。
Azure Policy では個別のポリシーを イニシアティブ(Initiatives) と呼ばれるルールセットに束ねて管理を行う仕様となっており(図3)、各 Azure サービス向けに専用のイニシアティブが用意されています。
Azure Kubernetes Service (AKS) 向けにも、以下の2種のイニシアティブが用意されています。
- Linux ベースのワークロードの Kubernetes クラスターポッドのセキュリティ ベースライン標準
- Linux ベースのワークロードの Kubernetes クラスターポッドのセキュリティで制限された標準
Kubernetes 用の Azure Policy アドオンでも、これらのルールが k8s リソースの更新リクエストの検証に使われます。
3-2. OPA Gatekeeper
次に Gatekeeper ですが、前述のイニシアティブと AKS の間を取り持つ役割を持ちます。 別の言い方をすると、Kubernetes 用の Azure policy ( Azure Policy for Kubernetes clusters ) は Gatekeeper を利用することで AKSクラスタにイニシアティブ(ルールセット)を適用します。
ここまでの説明を聞くと「OPA Gatekeeper ってどんな OSS 製品なの？」と疑問に思われると思います。 OPA Gatekeeper は Kubernetes のセキュリティポリシーの管理能力を高めることを目的にしたプロジェクトです。Open Policy Agent (OPA) と呼ばれる標準化仕様で書かれたルールを Kubernetes で利用できるよう必要な機能一式*3を提供します。
本記事を執筆の2022年3月現在、Gatekeeper v3.0 が最新のバージョンとなります。Gatekeeper v3.0 では専用の CRD - kind: ConstraintTemplate 、 kind: Constraint で定義されるリソース内に Rego のルールを埋め込む形でポリシーを定義します。サンプルとなる Manifest ファイルについてはこちらを参照ください。
Gatekeeper v3.0 では Kubernetes との連携に際し、Admission Web Hook と呼ばれる Kubernetes の拡張機能を利用します。この点については後述することとして、先にこれらの CRD と Open Policy Agent(OPA) , Rego について解説を行います。
3-3. ConstraintTemplate & Open Policy Agent (OPA) と Rego言語
図中のポリシー定義ファイルも同様に、Auzre Policy のイニシアティブと AKS の間を取り持つ役割を持ちます。
ここまで説明の通り、Kubernetes 用の Azure Policy アドオンは Azure Policy のイニシアティブ(ルールセット)を Gatekeeper を使ってAKS のリソース更新時に実行するよう設計されています。が、この実現に際し 「Gatekeeper は Azure Policy 形式のルールを実行できない」という制約があります。
そこで、Kubernetes 用の Azure Policy アドオンでは Azure Policy 形式のルールを Rego という言語に変換し、Gatekeeper 専用の CRD である kind: ConstraintTemplate に埋め込むことで、イニシアティブ（ルールセット）を Gatekeeper に実行させています。
Rego は Open Policy Agent (OPA) 仕様を満たすポリシー記述言語です。 Rego と Open Policy Agent (OPA) の詳細は以下のブログ記事に詳しいです。
Rego では、入力された情報がポリシーに適合しているか否かの判定を行うことができます。Rego によるポリシー定義のサンプルコードはこちらを参照ください。
3-4. Admission Control / Controller
Admission Control は Gatekeeper と AKS (Kubernetes) が連携するための I/F の役割を果たす、Kubernetes の拡張機能です。Kubernetes API へのリクエスト処理をフックし、認証・認可が終わったタイミングで、リソースの改変(Mutation)や検証(Validation)などの処理を追加することができます。Admission Control を実行する API サーバーは一般に Admission Controller と呼称されます。(図2) Gatekeeper は Kubernetes の Admission Controller として動作するよう設計されており、HTTP プロトコルで kube-apiserver と連携します。
Admission Control 機能を有効化する方法として、以下の2種が用意されています。Gatekeeper が採用しているのは後者の Admission Webhook 方式です。
- (1) プラグイン方式 : kube-apiserver のバイナリに含まれる Plugin を有効化する
- (2) Admission Webhook 方式 : Kubernetes の外部に Web サーバを設置し、webhook*4 で連携をする
Admission Control の概要は以下の記事に詳しいです。
KubernetesのDynamic Admission Controlを試してみる
終わりに
本記事では、Kubernetes 用の Azure Policy アドオンの概要とそれに使われる要素技術を概観してみました。この記事が皆様の AKS 運用の参考になれば幸いです。
*1: Kubernetes 用の Azure Policy アドオンによりデプロイされる kind: ConstraintTemplate 内の metadata.annotations.azure-policy-definition-id-x で定義のポリシーIDがGithubで管理のAKS向けAzureポリシー と整合するため、そのように判断しました。
*2:ガードレールの詳細につきましてはこちらの記事を参照ください。
*3:具体的には CRD と Operator を指します。
*4:Kubernetesリソースの操作に際し、kube-apiserver から外部に設置の Web サーバーに都度 POST リクエストが飛ぶようになります。Webhook の詳細についてはこちらの記事に詳しいです。
