GKE でのネットワーク分離について


このページでは、Google Kubernetes Engine(GKE)クラスタ コントロール プレーンとクラスタノードでのネットワーク分離とアクセス制御の仕組みについて説明します。このページは、限定公開クラスタのコンセプトについて説明するページに代わるものです。

ネットワーク分離の構成方法を決定する際には、次の 2 つの点を考慮する必要があります。

  • コントロール プレーンへのアクセス。クラスタのコントロール プレーンにアクセスできるユーザーに関連します。
  • クラスタ ネットワークノードの分離に関連します。

このページでは、クラスタのコントロール プレーンとクラスタノード(Standard クラスタ内)またはワークロード(Autopilot クラスタ内)にアクセスできるユーザーを制御してカスタマイズする方法について説明します。このカスタマイズは、クラスタのネットワーク構成を決定するときに関連します。ネットワーク構成の定義に直接進むには、ネットワーク分離をカスタマイズするをご覧ください。

ベスト プラクティス:

組織のネットワーク アーキテクト、ネットワーク エンジニア、ネットワーク管理者、またはネットワーク アーキテクチャの定義、実装、メンテナンスを担当する他のチームと協力して、ネットワーク分離構成を計画し、設計します。

コントロール プレーン アクセス

このセクションでは、コントロール プレーンにアクセスできるユーザーについて説明します。

すべての GKE クラスタには、Kubernetes API リクエストを処理するコントロール プレーンがあります。コントロール プレーンは、Google が管理するプロジェクトの VPC ネットワーク内の仮想マシン(VM)上で動作します。リージョン クラスタには、コントロール プレーンの複数のレプリカがあり、それぞれが独自の VM で実行されます。

コントロール プレーンには、クラスタ アクセス用の 2 種類のエンドポイントがあります。

  • DNS ベースのエンドポイント
  • IP ベースのエンドポイント
ベスト プラクティス:

DNS ベースのエンドポイントのみを使用してコントロール プレーンにアクセスすることで、構成を簡素化し、柔軟でポリシーベースのセキュリティ レイヤを実現します。

DNS ベースのエンドポイント

DNS ベースのエンドポイントは、クラスタ コントロール プレーンごとに一意の DNS 名または完全修飾ドメイン名(FQDN)を提供します。この DNS 名を使用して、コントロール プレーンにアクセスできます。DNS 名は、Google Cloud APIs から到達可能な任意のネットワーク(オンプレミス ネットワークやその他のクラウド ネットワークなど)からアクセス可能なエンドポイントに解決されます。DNS ベースのエンドポイントを有効にすると、他の VPC ネットワークまたは外部ロケーションからコントロール プレーンにアクセスするために、踏み台インスタンスやプロキシノードが不要になります。

コントロール プレーン エンドポイントにアクセスするには、IAM ロールとポリシー、認証トークンを構成する必要があります。必要な権限について詳しくは、ネットワーク分離をカスタマイズするをご覧ください。

IAM ポリシーとトークンに加えて、VPC Service Controls を使用して IP ベースまたはネットワーク ベースの制御を構成し、コントロール プレーンへのアクセスを保護することもできます。VPC Service Controls は、ネットワーク送信元などの属性に基づくコンテキストアウェア アクセスにより、アクセス セキュリティの別のレイヤを追加します。VPC Service Controls を使用すると、DNS エンドポイントにアクセスできるネットワークを構成できます。IAM ポリシーと VPC Service Controls の両方を使用して DNS ベースのエンドポイントへのアクセスを保護すると、クラスタ コントロール プレーンに多層セキュリティ モデルが提供されます。VPC Service Controls は Google Cloud APIs 全体で使用されており、この API 群に含まれる他のすべての API でホストされているデータと、クラスタのセキュリティ構成を整合させることができます。

IP ベースのエンドポイント

必要に応じて、IP ベースのエンドポイントを使用してコントロール プレーンへのアクセスを構成することもできます。

クラスタと IP アドレスに関する用語

  • Google Cloud 外部 IP アドレス:

    • Google Cloud でホストされている顧客によって使用される VM に割り当てられた外部 IP アドレス。Google Cloud はこれらの IP アドレスを所有しています。詳細については、Compute Engine の IP 範囲はどこで確認できますか?をご覧ください。

    • Cloud Run や Cloud Run functions などの Google Cloud プロダクトで使用される外部 IP アドレス。Google Cloud でホストされているあらゆるクライアントは、これらの IP アドレスをインスタンス化できます。Google Cloud はこれらの IP アドレスを所有しています。

  • Google で予約された IP アドレス: GKE クラスタを管理するための外部 IP アドレス。これらの IP アドレスには、GKE マネージド プロセスと他の本番環境の Google サービスが含まれています。Google はこれらの IP アドレスを所有しています。

  • GKE クラスタの IP アドレス範囲: GKE がクラスタのノード、Pod、Service に使用するクラスタに割り振られた内部 IP アドレス。

  • 内部 IP アドレス: クラスタの VPC ネットワークの IP アドレス。これらの IP アドレスには、クラスタ IP アドレス、オンプレミス ネットワーク、RFC 1918 範囲、または RFC 1918 以外の範囲を含むプライベートで使用されるパブリック IP(PUPI)アドレスを配置できます。

  • 外部エンドポイント: GKE がコントロール プレーンに割り当てる外部 IP アドレス。

  • 内部エンドポイント: GKE がコントロール プレーンに割り当てる内部 IP アドレス。

  • VPC ネットワーク: クラスタのノードと Pod 専用の IP アドレス範囲を持つサブネットを作成する仮想ネットワーク。

IP ベースのエンドポイントを使用する場合は、次の 2 つの方法があります。

  • 外部エンドポイントと内部エンドポイントの両方でコントロール プレーンを公開する。つまり、コントロール プレーンの外部エンドポイントには外部 IP アドレスからアクセスでき、内部エンドポイントにはクラスタの VPC ネットワークからアクセスできます。ノードは、内部エンドポイントでのみコントロール プレーンと通信します。

  • 内部エンドポイントでのみコントロール プレーンを公開する。つまり、インターネット上のクライアントはクラスタに接続できず、コントロール プレーンにはクラスタの VPC ネットワークの任意の IP アドレスからアクセスできます。ノードは、内部エンドポイントでのみコントロール プレーンと通信します。

    これは、コントロール プレーンへのすべてのインターネット アクセスをブロックするため、IP ベースのエンドポイントを使用する場合の最も安全なオプションです。これは、データのプライバシーやセキュリティに関する規制により、アクセスを制御する必要があるワークロードがある場合に適しています。

上記のどちらのオプションでも、許可されたネットワークを構成することで、エンドポイントに到達する IP アドレスを制限できます。IP ベースのエンドポイントを使用する場合は、承認済みネットワークを 1 つ以上追加することを強くおすすめします。承認済みネットワークは、信頼できる IPv4 アドレスの特定のセットにコントロール プレーンへのアクセス権を付与し、GKE クラスタの保護とセキュリティ上の利点を向上させます。

ベスト プラクティス:

IP ベースのエンドポイントを使用して GKE クラスタを保護する場合は、承認済みネットワークを有効にします。

承認済みネットワークの仕組み

承認済みネットワークは、GKE コントロール プレーンへのアクセスを制御する IP ベースのファイアウォールを備えています。コントロール プレーンへのアクセスは、送信元 IP アドレスによって異なります。承認済みネットワークを有効にすると、GKE クラスタ コントロール プレーン エンドポイントへのアクセスを許可する IP アドレスを CIDR ブロックリストとして構成します。

次の表に、

  • 承認済みネットワークを有効にするかどうかにかかわらず、GKE コントロール プレーンに常にアクセスできるプリセット IP アドレス。
  • 構成可能な IP アドレスは、承認済みネットワークを有効にして許可リストに登録すると、コントロール プレーンにアクセスできます。
コントロール プレーン エンドポイント エンドポイントに常にアクセスできるプリセット IP アドレス 承認済みネットワークを有効にした後にエンドポイントにアクセスできる構成可能な IP アドレス
外部エンドポイントと内部エンドポイントが有効
  • Google が予約した IP アドレス
  • GKE クラスタの IP アドレス範囲
  • 許可リストに登録された外部 IP アドレス
  • 許可リストに登録された内部 IP アドレス
  • Google Cloud 外部 IP アドレス
内部エンドポイントのみが有効
  • Google が予約した IP アドレス
  • GKE クラスタの IP アドレス範囲
  • 許可リストに登録された内部 IP アドレス。

承認済みネットワークを使用すると、内部 IP アドレスがコントロール プレーンの内部エンドポイントに到達できるリージョンを構成することもできます。クラスタの VPC ネットワークからのアクセスのみを許可するか、VPC またはオンプレミス環境の任意の Google Cloud リージョンからのアクセスを許可するかを選択できます。

IP ベースのエンドポイントの使用に関する制限事項

  • 承認済みネットワークを持つクラスタが使用しているサブネットを拡張する場合は、拡張された IP アドレス範囲を含むように承認済みネットワーク構成を更新する必要があります。
  • ホーム ネットワークの社員など、動的 IP アドレスを持つネットワークからクライアントが接続している場合は、クラスタへのアクセスを維持するために、承認済みネットワークのリストを頻繁に更新する必要があります。
  • コントロール プレーンの外部エンドポイントへのアクセスを無効にすると、クラスタをリモートで操作できなくなります。クラスタにリモートからアクセスする必要がある場合は、クライアント トラフィックをクラスタに転送する踏み台インスタンスを使用する必要があります。一方、DNS ベースのエンドポイントを使用する場合は、IAM 権限の設定のみが必要です。
  • IP ベースのエンドポイントは、VPC Service Controls と直接統合されません。VPC Service Controls はサービス境界レベルで動作し、Google Cloud 内のデータアクセスと移動を制御します。堅牢なセキュリティ防御のために、DNS ベースのエンドポイントと VPC Service Controls の両方を使用することをおすすめします。
  • 承認済み IP アドレス範囲(外部 IP アドレスと内部 IP アドレスを含む)は最大 100 個指定できます。

クラスタ ネットワーキングへのアクセス

このセクションでは、Kubernetes クラスタ内のノードの分離について説明します。

プライベート ノードを有効にする

内部 IP アドレスのみを使用してノードをプロビジョニングし、ノードを限定公開にして、外部クライアントがノードにアクセスできないようにします。外部 IP アドレスのないノードで実行されているワークロードは、クラスタのネットワークで NAT が有効になっていない場合、インターネットに到達できません。この設定はいつでも変更できます。

プライベート ノードを有効にするには、個々のクラスタレベル、ノードプール レベル(Standard の場合)、またはワークロード レベル(Autopilot の場合)で有効にします。ノードプールまたはワークロード レベルでプライベート ノードを有効にすると、クラスタレベルのノード構成がオーバーライドされます。

パブリック ノードプールをプライベート モードに更新すると、クラスタ ネットワーク外のアクセスを必要とするワークロードが次のシナリオで失敗する可能性があります。

  • 限定公開の Google アクセスが有効になっていない共有 VPC ネットワーク内のクラスタ。限定公開の Google アクセスを手動で有効にして、割り当てられたノードイメージが GKE によってダウンロードされるようにします。共有 VPC ネットワークにないクラスタの場合、GKE は限定公開の Google アクセスを自動的に有効にします。

  • Cloud NAT が有効になっていないか、カスタム NAT ソリューションが定義されていないワークロードがインターネットにアクセスする必要がある場合。インターネットへの下り(外向き)トラフィックを許可するには、Cloud NAT またはカスタム NAT ソリューションを有効にします。

プライベート ノードが有効か無効かに関係なく、コントロール プレーンは引き続き、内部 IP アドレスのみを使用してすべてのノードと通信します。

ネットワーク分離のメリット

ネットワークの分離には次のようなメリットがあります。

  • 柔軟性:

    • クラスタは統合され、柔軟に構成できます。外部エンドポイントの有無にかかわらず、クラスタはすべて同じアーキテクチャを共有し、同じ機能をサポートします。ニーズに合ったコントロールとベスト プラクティスに基づいてアクセスを保護できます。クラスタ内のノードとコントロール プレーン間のすべての通信で内部 IP アドレスが使用されます。
    • コントロール プレーンのアクセスとクラスタノード構成の設定は、クラスタを再作成しなくてもいつでも変更できます。
    • インターネットにアクセスできる任意のロケーションからクラスタを管理する必要がある場合や、VPC に直接接続されていないネットワークまたはデバイスからクラスタを管理する必要がある場合は、コントロール プレーンの外部エンドポイントを有効にできます。機密性の高いワークロードのネットワーク分離を維持する必要がある場合は、セキュリティを強化するために外部エンドポイントを無効にすることもできます。どちらの場合も、承認済みネットワークを使用して、信頼できる IP 範囲へのアクセスを制限できます。
  • セキュリティ:

    • VPC Service Controls を使用する DNS ベースのエンドポイントは、不正なネットワークや、コントロール プレーンにアクセスする不正な ID からクラスタを保護する多層セキュリティ モデルを提供します。VPC Service Controls は Cloud Audit Logs と統合され、コントロール プレーンへのアクセスをモニタリングします。
    • 限定公開ノードとこれらのノードで実行されているワークロードには、パブリック インターネットから直接アクセスできないため、クラスタに対する外部攻撃の可能性が大幅に軽減されます。
    • Google Cloud の外部 IP アドレスまたは外部 IP アドレスからのコントロール プレーンへのアクセスをブロックして、クラスタ コントロール プレーンを完全に分離し、潜在的なセキュリティ脅威への露出を減らすことができます。
  • コンプライアンス: データアクセスとストレージに厳格な規制が適用される業界で働いている場合、プライベート ノードは、機密データがプライベート ネットワーク内に確実に保持されるようにすることで、コンプライアンスを遵守できます。

  • 制御: 限定公開ノードを使用すると、クラスタに出入りするトラフィックの流れをきめ細かく制御できます。承認された通信のみを許可するように、ファイアウォール ルールとネットワーク ポリシーを構成できます。マルチクラウド環境で運用する場合、プライベート ノードを使用すると、さまざまな環境間で安全で制御された通信を確立できます。

  • 費用: プライベート ノードを有効にすると、インターネット上の公開サービスにアクセスするために外部 IP アドレスを必要としないノードの費用を削減できます。

次のステップ