このページでは、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 全体で使用されており、クラスタのセキュリティ構成を他のすべての Google Cloud APIs でホストされているデータと整合させることができます。
IP ベースのエンドポイント
必要に応じて、IP ベースのエンドポイントを使用してコントロール プレーンへのアクセスを構成することもできます。
クラスタと IP アドレスに関する用語
Google Cloud の外部 IP アドレス:
Google Cloud でホストされている顧客によって使用される VM に割り当てられた外部 IP アドレス。これらの IP アドレスは Google Cloud が所有しています。詳細については、Compute Engine の IP 範囲はどこで確認できますか？をご覧ください。
Cloud Run や Cloud Run functions などの Google Cloud プロダクトで使用される外部 IP アドレス。Google Cloud でホストされているあらゆるクライアントは、これらの IP アドレスをインスタンス化できます。これらの IP アドレスは Google Cloud が所有しています。
Google が予約した IP アドレス: GKE クラスタを管理するための外部 IP アドレス。これらの IP アドレスには、GKE マネージド プロセスと他の本番環境の Google サービスが含まれています。これらの IP アドレスは Google が所有しています。
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 アドレス |
|---|---|---|
| 外部エンドポイントと内部エンドポイントが有効 |
|
|
| 内部エンドポイントのみが有効 |
|
|
承認済みネットワークでは、内部 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 の場合）で有効にします。ノードプールまたはワークロード レベルでプライベート ノードを有効にすると、クラスタレベルのノード構成がオーバーライドされます。
パブリック ノードプールをプライベート モードに更新すると、クラスタ ネットワーク外のアクセスを必要とするワークロードが次のシナリオで失敗する可能性があります。
共有 VPC ネットワーク内のクラスタで限定公開の Google アクセスが有効になっていない場合。限定公開の 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 アドレスを必要としないノードの費用を削減できます。
次のステップ
- ネットワーク分離をカスタマイズする方法を確認する。
- Private Service Connect について学習する。