第20章. Kubernetesクラスタのポリシーとガバナンス
この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている:translation-feedback@oreilly.com
本書を通じて、Kubernetesのさまざまなリソースタイプを紹介してきたが、それぞれが特定の目的を持っている。 Kubernetesクラスタ上のリソースが、単一のマイクロサービスアプリケーションのための数個から、完全な分散アプリケーションのための数百、数千になるまでに時間はかからない。本番クラスタのコンテキストでは、何千ものリソースを管理することに関連する課題を想像するのは難しくない。
この章では、ポリシーとガバナンスの概念を紹介する。ポリシーとは、Kubernetesリソースをどのように設定できるかに関する制約と条件のセットである。ガバナンスは、Kubernetesクラスタにデプロイされたすべてのリソースに対して、すべてのリソースが現在のベストプラクティスを使用していること、セキュリティポリシーに準拠していること、会社の慣例に準拠していることなどを確認し、組織のポリシーを実施する機能を提供する。 どのようなケースであれ、クラスタ上で定義されたすべてのリソースが組織の定義したポリシーに準拠するように、ツールは柔軟でスケーラブルである必要がある。
なぜ政策とガバナンスが重要なのか
Kubernetesには様々な種類のポリシーがある。例えばNetworkPolicyでは、Podが接続できるネットワークサービスやエンドポイントを指定できる。PodSecurityPolicyでは、Podのセキュリティ要素をきめ細かく制御できる。どちらもネットワークやコンテナランタイムの設定に使用できる。
しかし、Kubernetesリソースが作成される前にポリシーを適用したい場合もあるだろう。これがポリシーとガバナンスが解決する問題だ。この時点で、あなたは "ロールベースのアクセス制御はこの点ではないのか?"と思うかもしれない。しかし、この章で説明するように、RBACはリソース内の特定のフィールドを設定できないように制限できるほど粒度が細かくない。
以下は、クラスタ管理者がよく設定するポリシーの例である:
-
すべてのコンテナは、特定のコンテナレジストリからのものでなければならない。
-
すべてのPodには、部署名と連絡先を明記すること。
-
すべてのPodには、CPUとメモリの両方のリソース制限が設定されていなければならない。
-
すべてのIngressホスト名はクラスタ間で一意でなければならない。
-
あるサービスをインターネット上で利用可能にしてはならない。
-
コンテナは特権ポートをリッスンしてはならない。
クラスタ管理者はまた、クラスタ上の既存のリソースを監査したり、ドライランポリシー評価を実行したり、あるいは条件付きでリソースを変異させたりしたい場合もある。
開発者がKubernetesにアプリケーションをデプロイすることを妨げることなく、クラスタ管理者がポリシーを定義し、コンプライアンス監査を実行できることは非常に重要だ。開発者がコンプライアンスに準拠しないリソースを作成している場合、彼らが自分の作業をコンプライアンスに適合させるために必要なフィードバックと修正を受けられるようにする仕組みが必要だ。
Kubernetesのコアとなる拡張性コンポーネントを活用して、ポリシーとガバナンスを実現する方法を見てみよう。
入場の流れ
Kubernetesクラスタに作成される前に、ポリシーとガバナンスがどのようにリソースのコンプライアンスを保証するかを理解するには、まずKubernetes ...