GKE のネットワーク セキュリティについて

このドキュメントでは、最小権限の原則など、GKE ネットワーク セキュリティの基本的なコンセプトについて説明し、クラスタを保護するための適切なツールを選択するのに役立ちます。GKE ネットワーク セキュリティを実装する主な目的は、ワークロードの分離と安全なマルチテナンシーです。これらの目標を達成するには、最小権限の原則と多層防御の原則を適用し、実用的なデータを使用してセキュリティに関する意思決定を行う必要があります。

Google Kubernetes Engine（GKE）でネットワーク トラフィックに最小権限の原則を適用するということは、アプリケーションの機能に必要な通信のみに制限することを意味します。デフォルトでは、GKE クラスタ内のネットワークはオープンです。つまり、すべての Pod が他のすべての Pod と通信できます。

GKE は、すべての Namespace で管理レベルの適用に ClusterNetworkPolicy を使用することで、ネットワーク セキュリティに対する階層型アプローチをサポートするようになりました。

このドキュメントでは、オペレーター、ネットワーク スペシャリスト、セキュリティ スペシャリストが GKE クラスタ内でネットワーク セキュリティを理解して実装するために必要な情報を提供します。の一般的なロールとタスクの例の詳細については、Common GKE ユーザーの一般的なロールと タスクをご覧ください。 Google Cloud

このドキュメントを読む前に、次のことを理解していることを確認してください。

  • GKE ネットワーキングのコンセプト: 概要については、GKE ネットワーキングについてをご覧ください。
  • Kubernetes Pod、Service、Namespace: これらの基本的な Kubernetes リソースは、ネットワーク セキュリティ ポリシーの定義の中心となります。Kubernetes のドキュメントをご覧ください。
  • 最小権限の原則: このセキュリティ原則は、このドキュメント全体に適用されるコア コンセプトです。

GKE ネットワーク セキュリティの目標

GKE ネットワーク セキュリティ ポリシーは、クラスタ内で Kubernetes を認識したきめ細かいトラフィック制御を提供します。これらのポリシーは、全体的なセキュリティ戦略の重要な要素です。堅牢なネットワーク セキュリティを実装するには、次の基本原則を考慮してください。

  • 最小権限: システムとサービスに、その機能を実行するために必要な最小限の権限 のみを付与します。この原則により、侵害の影響を軽減できます。Kubernetes ネットワーク ポリシーを使用すると、 デフォルトでオープンなネットワークから、必要な接続のみが許可されるネットワークに移行できます。
  • 多層防御: 複数の独立したセキュリティ コントロールを階層化します。1 つのコントロールで障害が発生しても、システム全体が侵害されることはありません。たとえば、データベース自体に認証が必要な場合でも、ネットワーク ポリシーを使用して データベースを分離します。
  • 実用的なデータ: データに基づいてセキュリティに関する意思決定を行います。脅威モデリングとリスク評価により、セキュリティ体制を把握できます。ネットワーク ポリシー ロギングなどの機能は、ポリシーを検証し、潜在的な侵害を検出するための データを提供します。

ネットワーク セキュリティ ポリシーを選択する

適切なポリシーを選択するには、制御する必要があるトラフィックのタイプと範囲を特定します。

トラフィックのタイプ

適切なポリシーを選択するには、管理するトラフィックの送信元と宛先を考慮してください。

  • クラスタ内の Pod 間の通信: マイクロサービス間の通信方法を制御するには、Pod ラベルと Namespace で動作するポリシーを使用します。

    • アプリケーション デベロッパーは、標準の Kubernetes NetworkPolicy を使用して、Namespace 内のアプリケーションの Ingress ルールと Egress ルールを定義します。
    • クラスタ管理者は、標準の Kubernetes ClusterNetworkPolicy を使用して、すべての Namespace にわたって必須のセキュリティ ガードレール（Admin ティア）を適用するか、 ゼロトラストのデフォルト（Baseline ティア）を確立します。このリソースは、GKE バージョン 1.36.1-gke.1067000 以降を実行しているクラスタでサポートされています。
    • クラスタ管理者は、独自の CiliumClusterwideNetworkPolicy を使用して、クラスタ全体のトラフィック制御を専門的に行います。新しいデプロイの場合は、この独自のポリシーではなく、Kubernetes ネイティブの ClusterNetworkPolicy を使用します。

  • Pod から外部サービスへの下り（外向き）トラフィック: ドメイン名に基づいて Pod から外部サービスへの下り（外向き）トラフィックを制御するには、FQDNNetworkPolicy を使用します。このポリシーは、外部サービスの IP アドレスが静的でない場合に便利です。DNS に基づいて許可された IP アドレスを自動的に解決して更新するためです。

  • すべてのサービス間トラフィックの暗号化: サービス間のすべての 通信が暗号化され、認証されるようにするには、サービス メッシュを使用します。Istio または Anthos Cloud Service Mesh を使用して 相互 TLS（mTLS）を実装します。これにより、暗号化が自動的に処理されます。

ポリシー評価階層

GKE は、ネットワーク セキュリティ ポリシーを 3 つの階層で評価します。

  1. 管理ティア（ClusterNetworkPolicy）: 最も優先度が高いレベル。このティアを使用して、必須のセキュリティ要件を適用します。このティアの拒否 ルールは、他のすべてのポリシーをオーバーライドします。許可 ルールはトラフィックを許可し、そのパケットの評価を停止します。
  2. NetworkPolicy ティア: デベロッパーがアプリケーション固有の セキュリティを定義するティア。ポリシーには、標準の NetworkPolicy、FQDNNetworkPolicy、 および CiliumClusterwideNetworkPolicy リソースが含まれます。
  3. ベースライン ティア（ClusterNetworkPolicy）: 最も優先度が低いレベル。このティアを使用して、デベロッパーが NetworkPolicy ティアで選択的にオーバーライドできるデフォルトの「デフォルトで拒否」ガードレールを設定します。

どのティアでもポリシーが一致しない場合、GKE はデフォルトで暗黙的な「すべて許可」の動作になります。

ポリシーの選択の概要

次の表に、セキュリティの目標に基づいて使用するポリシーをまとめます。

目標 推奨ポリシー
ラベルと Namespace を使用して Pod 間のトラフィックを制御する。 Kubernetes NetworkPolicy
ドメイン名で外部サービスへの下り（外向き）トラフィックを制御する。 FQDNNetworkPolicy
すべてのサービス間トラフィックを暗号化して認証する。 Istio または Anthos Cloud Service Mesh（mTLS の場合）
オーバーライドできない必須のセキュリティ ガードレールを適用する。 ClusterNetworkPolicy （管理ティア）
デベロッパーがオーバーライドできるデフォルトの「ゼロトラスト」ガードレールを確立する。 ClusterNetworkPolicy （ベースライン ティア）
独自のクラスタ全体のポリシーを構成する（新しいデプロイには推奨されません）。 CiliumClusterwideNetworkPolicy
ポリシーで許可または拒否された接続を監査してログに記録する。 ネットワーク ポリシー ロギング（任意のポリシーで有効）

ネットワーク ポリシーを監査してトラブルシューティングする

ネットワーク ポリシーを実装したら、ポリシーが期待どおりに機能していることを確認し、接続の問題を診断します。これには、ネットワーク ポリシー ロギングを主な ツールとして使用できます。

ネットワーク ポリシー ロギングを有効にすると、ネットワーク ポリシーで許可または拒否された接続ごとに、GKE が Cloud Logging にログレコードを生成します。これらのログは、セキュリティ監査の実施や予期しない動作のトラブルシューティングに不可欠です。これらのログを確認すると、ルールの具体的な効果を確認し、正当なトラフィックが想定どおりに流れ、不正なトラフィックがブロックされていることを確認できます。

「許可のみ」の標準ポリシーとは異なり、ClusterNetworkPolicy リソースは明示的な拒否 アクションをサポートしています。管理ポリシーがトラフィックをドロップした場合、ログレコードはブロックの原因となった特定のポリシーに拒否を関連付けます。

次のステップ