Anthos Config Management を使用した Kubernetes の構成とポリシーの自動化
Google Cloud Japan Team
※この投稿は米国時間 2021 年 12 月 10 日に、Google Cloud blog に投稿されたものの抄訳です。
組織内でのコンテナの普及に伴い、Kubernetes は、コンテナ化アプリケーションのデプロイと運用における事実上の標準ツールになっています。Kubernetes のフットプリントが拡大するにつれ、成長を続けるフリート全体で一貫した構成ポリシーとセキュリティ ポリシーを作成・適用する際に、摩擦が生じることがあります。Anthos Config Management（ACM）は、Kubernetes リソースを構築・実行する際に、確実に一貫した構成とポリシーを設定・適用して、Google Cloud サービスを同じように管理できるようにすることで、この問題に対応します。Anthos Config Management を使用すると、事前に構築された、方向性が決められた（opinionated）構成とポリシーの自動化（安全なランディング ゾーンの作成やブループリントからの GKE クラスタのプロビジョニングなど）を追加することで、さらに簡単に YAML または JSON のリソースを宣言的に指定できます。
有名な格言のとおり「語らずに示す」べきでしょう。この投稿では、監査、トランザクション管理、バージョン管理が可能なデプロイ プロセスで、クラスタと環境全体に構成を一貫して適用するために、Config Sync を使用して、GitOps 手法を活用する方法例をお見せします。さらに Policy Controller を使用して、望ましい状態上の制約を表すプログラム可能なポリシーを適用します。
最初に、Git リポジトリのセットアップ プロセスに従い、インフラストラクチャを構築し、手順に沿ってサービスをデプロイします。
ご自身がプラットフォーム管理者であり、組織内で特定のサービスだけでなく、開発クラスタ、ステージング クラスタ、本番環境クラスタを含む Kubernetes 環境全体に責任を負っているとしましょう。アプリ デベロッパーは、摩擦を最小限に抑えて、コードをテストし、機能を本番環境にリリースすることを重視しますが、ご自分の関心は別のところにあります。重視するのはプラットフォーム全体の一貫性です。つまり、特定のベースライン構成とポリシーが常にデプロイされ、すべてのクラスタ全体で同期がとれていることです。（デベロッパーが、誤ってリソースの一つを kubectl apply -f することのないよう、特に、知らないうちにこの状況が起きないように注意します。）業界の規制へのコンプライアンスを重視し、必要なポリシーが施行されていることを確認するため、セキュリティ チームと直接作業することがあります。
つまり、プラットフォーム管理者として実際に重視すべきポイントは、Kubernetes Resource Model（KRM）に関する 2 つの要素、つまり1）一貫性、2）安全ではない構成からのクラスタの保護、となります。それでは、Anthos Config Management を使用して、この 2 つの目標をどのように実現しているか、見ていきましょう。
以下の例では、Cymbal-Bank という疑似バンキング アプリケーションをデプロイします。
この演習では、Config Sync と Policy Controller をクラスタにインストール済みであることを前提としています。
config-management-system 名前空間内にある最初の Pod のセットが Config Sync を実行します。これらのワークロードは GitHub ポリシー リポジトリを定期的にチェックして、ここに保存されている KRM の信頼できるソースに更新がないか確認し、更新があった場合はリソースをクラスタにデプロイします。ワークロードでは、CI / CD または Config Sync を通じて、クラスタにデプロイされるリソースが、設定したポリシーに準拠しているかを確認できます。
gatekeeper-system 名前空間内にあるワークロードの 2 番目のセットが Policy Controller を実行します。これはオープンソースの Gatekeeper プロジェクトをベースとしていますが、これは Cloud-Native Computing Foundation（Kubernetes をホスティングしている組織）の一部である OpenPolicyAgent プロジェクトを起因とするものです。
Policy Controller は、セキュリティ、規制、任意のビジネスルールに関連するポリシーへのクラスタの準拠を確認、監査、適用する Kubernetes 動的アドミッション コントローラです。Policy Controller ポリシーは、制約と制約テンプレートの 2 つのオブジェクトに分かれています。2 つの異なるオブジェクトが存在することで、ポリシーを定義（制約テンプレート）と適用（制約）に分割できます。
それではポリシーを展開してみましょう。アドミッション コントローラは、Kubernetes クラスタの「ゲート」に位置する Pod です。API サーバーで何を受信しているか監視し、受信リソースがクラスタの「内部で使用できる」ようになって etcd 内に保持される前に、リソースに対するオペレーションを実行します。「リソースに対するオペレーション」には、処理中のリソースの変更（MutatingAdmissionWebhook）や、リソース全体の却下（ValidatingAdmissionWebhook）などがあります。Policy Controller は後者の Webhook で、受信した構成を Policy Controller が把握しているポリシーと照らし合わせて検証し、ポリシーを許可または却下します。
Policy Controller が適用する制約は、実際にはどのように表示されるでしょうか？PolicyController を使用して、承認または却下する Kubernetes リソースの種類はどれでしょうか？
制約の一例をご覧ください。
ここで、「kind: K8sNoExternalServices」は、クラスタにインストール済みの k8snoexternalservices 制約テンプレートを指しています。このリソースの範囲を cymbal-dev クラスタのみに設定するため、Config Sync の cluster-name-selector アノテーションをどのように使用しているかも確認できます。
この制約で、K8sNoExternalServices 制約テンプレートが、環境に関する具体的な情報とともに実装されます。
想定される出力:
このコマンドによって、Config Sync を経由して Policy Controller ポリシーがデプロイされました。このポリシーの制約に違反するアプリケーションをデプロイしようとすると、ACM はそのリクエストを却下します。このラボをテスト運用したい場合、スタッフ デベロッパー リレーションズ エンジニアの Megan O’Keefe が開発したこちらの Git リポジトリのセットアップを実行してください。このたび、GKE を利用されているお客様には、安価なクラスタ単位の料金で Anthos Config Management をご利用いただけるようになりました。Anthos Config Management の詳細と、ベスト プラクティス、クイックスタート、チュートリアルについては、Google のドキュメント ページをご覧ください。
- プロダクト マネージャー Arun Ananthampalayam
