GKE コントロール プレーンにアクセスするための新しい柔軟な DNS ベースのアプローチ

※この投稿は米国時間 2024 年 11 月 12 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Kubernetes Engine（GKE）を使用しているなら、Kubernetes API リクエストを処理するクラスタ コントロール プレーンへのアクセスを保護することが重要です。不正アクセスを防ぎつつ、クラスタを制御できるようにする必要があります。

これまでの GKE には、コントロール プレーンを保護するために主に 2 つの方法がありました。一つは承認済みネットワーク、もう一つはパブリック エンドポイントの無効化です。しかし、どちらの方法を使用しても、クラスタへのアクセスが難しくなることがあります。クラスタのプライベート ネットワーク経由でアクセスするには、踏み台インスタンスのような独創的なソリューションが必要であり、承認済みネットワークのリストをすべてのクラスタで最新の状態に保つ必要があります。

このたび、アクセス方法とセキュリティ制御の柔軟性を向上させる、GKE クラスタ用の新しい DNS ベースのエンドポイントを発表する運びとなりました。DNS ベースのエンドポイントは、バージョンやクラスタ構成���問わず、すべてのクラスタで利用できるようになっています。

新しい DNS ベースのエンドポイントにより、Kubernetes コントロール プレーン アクセスに関連する現在の課題のいくつかを解決できます。たとえば次のような課題です。

1. IP ベースのファイアウォール / 許可リストの複雑な構成: IP アドレスベースの承認済みネットワーク構成と ACL では、人為的な構成エラーが発生しやすくなります。  

2. IP アドレスに基づく静的な構成: ネットワーク構成と IP 範囲が変更されると、承認済みネットワークの IP ファイアウォール構成もそれに応じて変更する必要があります。

3. プロキシ / 踏み台インスタンス: リモート ネットワーク、別のクラウド ロケーション、またはクラスタが存在する VPC とは異なる VPC から GKE コントロール プレーンにアクセスする場合は、プロキシまたは踏み台インスタンスを設定する必要があります。

こうした課題によって構成が複雑になり、GKE のお客様にとってユーザー エクスペリエンスがわかりづらいものになっていました。

新しい DNS ベースのエンドポイントのご紹介

DNS 名は、VPC ネットワーク、オンプレミス ネットワーク、その他のクラウド ネットワークなど、Google Cloud APIs に到達できる任意のネットワークからアクセス可能なフロントエンドに解決されます。GKE の新しい DNS ベースのエンドポイントにより、各クラスタ コントロール プレーンに一意の DNS 名または完全修飾ドメイン名（FQDN）が提供されます。フロントエンドでは不正なトラフィックを拒否するセキュリティ ポリシーを適用し、承認されたトラフィックをクラスタに転送します。

この方法には次のような利点があります。

1. 場所を選ばない、シンプルで柔軟なアクセス

DNS ベースのエンドポイントを使用すると、踏み台インスタンスやプロキシノードが不要になります。承認されたユーザーは、異なるクラウド、オンプレミスのデプロイ、または自宅からでも、プロキシを経由することなくコントロール プレーンにアクセスできます。DNS ベースのエンドポイントを使用する場合、複数の VPC を経由することに制限はありません。要件は Google API へのアクセス権だけです。必要に応じて、VPC Service Controls を使用して特定のネットワークへのアクセスを制限することもできます。

2. 動的なセキュリティ

DNS ベースのエンドポイントを介したコントロール プレーンへのアクセスは、すべての GCP API アクセスと同様に IAM ポリシーによって保護されます。IAM ポリシーを使用することで、使用する IP やネットワークに関係なく、承認されたユーザーのみがコントロール プレーンにアクセスできるようになります。必要に応じて特定の ID のアクセス権を簡単に取り消すことができます。その際、ネットワーク IP アドレスの構成や境界を気にする必要はありません。IAM ロールは組織のニーズに合わせてカスタマイズできます。

IAM ロール、ポリシー、認証トークンを構成するために必要となる具体的な権限について詳しくは、ネットワーク分離をカスタマイズするをご覧ください。

3. 2 層のセキュリティ

IAM ポリシーに加えて、VPC Service Controls を使用してネットワーク ベースの制御を構成し、クラスタ コントロール プレーンに多層セキュリティ モデルを適用することもできます。VPC Service Controls を利用すると、ネットワーク送信元などの属性に基づくコンテキストアウェア アクセスの制御が追加されます。VPC ネットワークからのみアクセスできる限定公開クラスタと同じレベルのセキュリティが実現します。VPC Service Controls は Google Cloud APIs 全体で使用されており、この API 群に含まれる他のすべての API でホストされているサービスおよびデータと、クラスタのセキュリティ構成を整合させることができます。プロジェクト内のすべての Google Cloud リソースについて、サービスとデータへの不正アクセスを確実に防止できます。VPC Service Controls によるコントロール プレーンへのアクセスのモニタリングには、Cloud Audit Logs とのインテグレーションが使用されます。

お客様の声:

「プライベート IP ベースのコントロール プレーン アクセスを使用する際は、さまざまな VPC やデータセンター サイトから GKE コントロール プレーンにアクセスできるよう、複雑なネットワーキング ソリューションを構成、管理する必要がありました。しかし、DNS ベースの GKE コントロール プレーン アクセスと VPC Service Controls を組み合わせることで、GKE コントロール プレーンへのアクセスが大幅に簡素化され、ID と認証に基づく動的セキュリティ ベースのアクセス ポリシーの実装が可能になります。」  ANZ Bank、ANZx クラウド＆エンジニアリング プラットフォーム テクノロジー リード、Keith Ferguson 氏

DNS ベースのアクセスを構成する方法

GKE クラスタ コントロール プレーンの DNS ベースのアクセスを構成するプロセスは非常にシンプルです。以下の手順をご確認ください。

1. DNS ベースのエンドポイントを有効にする

次のコマンドを使用して、新しいクラスタに対して DNS ベースのアクセスを有効にします。

または、次のコマンドを使用して、既存のクラスタに対して DNS ベースのアクセスを有効にします。

2. IAM を構成する

コントロール プレーンへのアクセスには、新しい IAM 権限 container.clusters.connect を持つロールでリクエストが認証される必要があります。ユーザーに次のいずれかの IAM ロールを割り当てます。

• roles/container.developer

• roles/container.viewer

事前構成済みロールを使用してユーザーがクラスタにアクセスできるように構成する例を以下に示します。

または、container.clusters.connect 権限を持つカスタム IAM ロールを構成することもできます。

container.clusters.connect を使用するようにロールを構成する例を以下に示します。

3. クライアントが Google API にアクセスできることを確認する

クライアントが Google VPC から接続している場合は、Google VPC から Google API への接続を確保する必要があります。そのための方法の一つとして、限定公開の Google アクセスの有効化があります。これにより、クライアントは公共のインターネットを経由せずに Google API に接続できるようになります。限定公開の Google アクセスは個別のサブネットで構成します。

ヒント: 限定公開の Google アクセスは、ノードのサブネットワークではあらかじめ有効になっています。

サブネットで限定公開の Google アクセスを有効にするには、下の画像のようにします。

4. [省略可] Google API 用の Private Service Connect を介したアクセスを構成する

クラスタの DNS エンドポイントには、残りの Google API へのアクセスに使用される Google API エンドポイント用の Private Service Connect を介してアクセスできます。「エンドポイントから Google API にアクセスする」というページに、Google API エンドポイント用の Private Service Connect を構成するために必要な手順がひと通り記載されています。カスタム エンドポイントを介したクラスタの DNS へのアクセスはサポートされていないため、「エンドポイントを使用する」のセクションで説明されているように、これを機能させるには、「* gke.goog」と Google API 用の Private Service Connect に割り当てられたプライベート IP の間に A レコードを作成し、CNAME を「*.gke.goog」に追加する必要があります。

DNS ベースのアクセスを試す

では、いよいよ DNS ベースのアクセスを試してみましょう。次のコマンドを使用して、クラスタの DNS アドレスを使った kubeconfig ファイルを生成します。

次に、kubectl を使用してクラスタにアクセスします。これを Cloud Shell から直接使用することで、パブリック IP エンドポイントを使用せずにクラスタにアクセスできます。以前は、これを行うにはプロキシを設定する必要がありました。

VPC Service Controls を使ったセキュリティ強化

必要に応じて、VPC Service Controls をコントロール プレーン アクセスのセキュリティを強化するために使用することもできます。

特定の GCP プロジェクト内にある VM からのリクエストのみを許可する上り（内向き）ポリシーの例を以下に示します。

IP ベースのエンドポイントではどうか

もちろん、コントロール プレーンへのアクセスに既存の IP ベースのエンドポイントを使用し続けながら、既存のクライアントに影響を与えずに DNS ベースのアクセスを試すことも可能です。その後、DNS ベースのアクセスに満足したら、IP ベースのアクセスを無効化できます。これにより、セキュリティが強化され、クラスタ管理が簡素化されます。

次のステップ

DNS ベースのエンドポイントを使用すると、クラスタ コントロール プレーンのセキュリティを管理するうえでの柔軟性が向上すると同時に、プライベート ネットワークからクラスタにアクセスする際の複雑さが軽減されます。

DNS ベースのエンドポイントの使用方法についての詳細は、以下の参考資料をご覧ください。

• クラスタ分離のコンセプトに関するページ

• クラスタ分離の入門ページ

ー Google シニア プロダクト マネージャー、Ninad Desai

ー Google ソフトウェア エンジニア、Chris Gonterman