Kubernetes クラスターを保護するための 3 つの重要な要素

コンテナベースのテクノロジーが急速に採用されるにつれて、組織は Kubernetes クラスターのセキュリティについてますます懸念するようになっています。クラウドおよびエンタープライズ ディストリビューションは強力なセキュリティ機能を提供しますが、組織のセキュリティ要件に合わせて調整する必要があります。

この記事では、Kubernetes クラスターを保護する際に考慮すべき 3 つの重要な側面について説明します。

• ロールベースのアクセス制御 (RBA)
• オープン ポリシー エージェント (OPA)
• ネットワークポリシー

ロールベースのアクセス制御

3 つのアプリケーション チーム (ブルー チーム、グリーン チーム、レッド チーム) を持つ組織を考えてみましょう。これらのチームは異なる製品を開発しているため、Kubernetes クラスターにアクセスするための異なる権限を付与する必要があります。たとえば、グリーン チームとレッド チームは、ブルー チームによってデプロイされたクラスターを表示、アクセス、または削除できないようにする必要があります。

RBAC は、ユーザーがアクセスできる Kubernetes リソースを制御する方法です。 RBAC はデフォルトで有効になっていますが、使用するには設定する必要があります。

RBAC には 5 つの重要な要素があります。

• トピック - ユーザーとプロセス
• リソース - アクセスを制限する必要があるオブジェクト
• アクション - 実行できる操作の集合（アクションと呼ばれることが多い）
• ロール - APIリソースをアクションに接続するオブジェクト
• アクターバインディング - アクターをテーマに接続するオブジェクト

前の組織に戻り、ブルーチームだけがポッド、デプロイメント、サービスを作成、削除、一覧表示できるポリシーを定義しましょう。

まず、「role-blue」というロール オブジェクトを作成し、特定の Kubernetes リソースに対して実行できるアクションを定義します。この特定のケースでは、ロールにより、リソース（ポッド、デプロイメント、サービス）に対する作成、削除、一覧表示などのアクションが許可されます。

次に、「blue-rb」というキャラクターリグを作成します。このロール バインディングは「blue-ns」に属し、上記で作成したロール「role-blue」を「blue」という名前のブルー チームに関連付けます。

これらのリソースがクラスターで利用可能になると、「blue」チームのユーザーは「role-blue」で定義された操作を実行できるようになります。

オープンポリシーエージェント

Open Policy Agent (OPA) は、スタック全体にわたってポリシーの適用を統合するユニバーサル ポリシー エンジンです。高レベルの宣言型言語により、ポリシーをコードとして指定する柔軟性が提供されます。 OPA を使用して、Kubernetes、CI/CD パイプライン、または API ゲートウェイでポリシーを適用できます。 Kubernetes でこれをどのように使用し、実装するかを詳しく見てみましょう。

Kubernetes が OPA を実装するメカニズムは Gatekeeper と呼ばれます。これは、リクエストをインターセプトし、処理し、許可または拒否の応答を返すアドミッション コントローラとして設計および展開されます。

許可された場合、オブジェクトはクラスターにデプロイされます。それ以外の場合、リクエストは拒否され、ユーザーにフィードバックが提供されます。管理者は、コンテナまたは名前空間が消費できるメモリや CPU などのリソースを制限したり、特定のレジストリのイメージに基づいてコンテナのみを承認したり、NodePort サービスの作成を制限したり、標準の命名を強制したりするように Kubernetes に指示するポリシーを定義できます。

たとえば、名前空間で ResourceQuota が設定されている場合にのみ Pod の作成を許可するサンプル テンプレートと制約ポリシーを次に示します。

ネットワークポリシー

ネットワーク ポリシーは、アプリケーション中心であるという点を除いて、通常のファイアウォールと非常によく似ています。アプリケーションのネットワーク ポリシーを定義すると、コンテナは非常に動的な環境で継続的に作成および終了されるため、Kubernetes は関連するコンテナにそれらのルールを自動的に適用します。ネットワーク ポリシーは、これらのコンテナーに出入りするトラフィックを制御します。

デフォルトでは、Pod との間のネットワーク トラフィックは制限されません。まず、すべてのトラフィックを拒否し、必要なトラフィックのみを許可するルールを設定するのが良いでしょう。

デフォルトでは、Kubernetes はフラットなネットワーク構造を使用し、任意の Pod がクラスター内の他の Pod またはサービスと通信できるようにします。複数のアプリケーションまたは多層アプリケーションを含むクラスターでは、多層防御が通信層の保護に重要な役割を果たします。ネットワーク戦略によりこれが可能になります。

これは、「blue」名前空間のラベル「role=db」を持つポッドに次のルールを適用する「app1-network-policy」です。

• [Ingress] ポート 6379 経由で ipBlock 172.17.0.0/24 からの接続を許可します。
• [Ingress] 「role=frontend」のタグが付けられており、ポート 6379 でラベル「project=myproject」を持つ名前空間に属している場合、他のポッドからの接続を許可します。
• [出力] ポッドはポート 5978 を介して IP 範囲 10.0.0.0/24 内の他のポッドと通信できます。

原題: Kubernetes クラスターを保護するための 3 つの重要な要素、著者: Avinash Desireddy