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

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

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

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

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

  • 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 にログレコードを生成します。これらのログは、セキュリティ監査の実施や予期しない動作のトラブルシューティングに不可欠です。これらのログを確認すると、ルールの具体的な効果を確認し、正当なトラフィックが想定どおりに流れ、不正なトラフィックがブロックされていることを確認できます。

次のステップ