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

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

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

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

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

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

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

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

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

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

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

トラフィックのタイプ

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

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

    • アプリケーション デベロッパーは、標準の Kubernetes NetworkPolicy を使用して、Namespace 内のアプリケーションの ingress ルールと egress ルールを定義します。
    • クラスタ管理者は、 CiliumClusterwideNetworkPolicy を使用して、クラスタ全体に適用されるセキュリティ ガードレールを適用します。拒否 ルールは、NetworkPolicy の許可ルールよりも優先されます。CiliumClusterwideNetworkPolicy

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

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

ポリシーの選択の概要

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

目標 推奨ポリシー
ラベルと Namespace を使用して Pod 間のトラフィックを制御する。 Kubernetes NetworkPolicy
ドメイン名で外部サービスへの下り（外向き）トラフィックを制御する。 FQDNNetworkPolicy
すべてのサービス間トラフィックを暗号化して認証する。 Istio または Anthos Cloud Service Mesh（mTLS の場合）
管理者として、クラスタ全体の必須ルールを適用する。 CiliumClusterwideNetworkPolicy
ポリシーで許可または拒否された接続を監査してログに記録する。 ネットワーク ポリシー ロギング（任意のポリシーで有効）

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

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

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

次のステップ