このドキュメントでは、Connect に組み込まれているセキュリティ対策について説明します。
効果的なハイブリッドのマルチクラウド プラットフォームは、一元管理、オブザーバビリティ、サービスへのアクセス性を環境全体にて実現します。GKE Enterprise は、使用している Kubernetes プロバイダにかかわらず、これらの機能を統一的に提供します。Connect は、規模の経済性を効かせて、以下をあらゆるプロバイダに提供する軽量エージェントです。
- マルチクラスタ管理とクラスタの可視性
- アプリケーション サービスのデプロイとライフサイクルの管理
このドキュメントでは、次のトピックについて説明します。
- セキュリティを第一とする Connect の設計
- Connect エージェントのデプロイのベスト プラクティス
- Kubernetes Deployment のセキュリティを強化する方法
Connect のアーキテクチャ
Connect を使用すると、エンドユーザーと Google Cloud サービスが、公共のインターネット上に接続されていない Kubernetes API サーバーにアクセスできるようになります。Connect エージェントは Kubernetes クラスタで実行され（1 クラスタにつき 1 エージェント）、Connect プロキシに接続されます。Kubernetes クラスタを操作する必要がある Google Cloud サービスは、プロキシに接続され、そのプロキシからエージェント宛にリクエストが転送されます。次の図に示すように、エージェントはそのリクエストを Kubernetes API サーバーに転送します。
デプロイされたエージェントによって、Google Cloud への持続的な TLS 1.2+ 接続が確立され、リクエストの受信を待機します。Google Cloud サービスが管理者によって有効にされると、Kubernetes クラスタのリクエストが生成できるようになります。こうしたリクエストは、ユーザーが Google Cloud コンソール、Connect ゲートウェイ、またはその他の Google サービスを直接操作することで発生する場合もあります。
Google Cloud サービスがリクエストをプロキシに送信します。その後、プロキシはクラスタを担当するデプロイされたエージェントにリクエストを転送し、最後にそのリクエストを Kubernetes API サーバーに転送します。Kubernetes API サーバーは、Kubernetes の認証、承認、監査ログのポリシーを適用し、レスポンスを返します。レスポンスは、エージェントとプロキシを介して Google Cloud サービスに返されます。このプロセスの各ステップで、コンポーネントによって、接続ごとおよびリクエストごとに認証と認可が実行されます。
Kubernetes API サーバーは、Connect からのリクエストを含め、すべてのリクエストに同じ認証、認可、および監査ログのポリシーを適用します。このプロセスにより、クラスタへのアクセスを常に制御できます。
Connect と多層防御
多層防御は、インフラストラクチャとセキュリティ対策において、Google Cloud が果たすすべての機能に内在しています。Google の組織やお客様のセキュリティ保護にかかわるあらゆる側面に対して階層的なアプローチを採用し、貴重なデータ、情報、ユーザーの保護に努めています。これは Connect の設計方針と同じです。
Google の徹底した戦略と設計に加えて、ここに示す内容を、お客様のセキュリティ状況と基準も合わせて確認する必要があります。このセクションでは、Kubernetes 強化のベスト プラクティスを補足する追加の手段を紹介します。
コンポーネント間のセキュリティ
Connect リクエストの各コンポーネントはピアを認証し、次の図に示すように、データに関して認証かつ認可されたピアとのみ、データを共有します。
Connect リクエストの各コンポーネントは、以下を使用して互いに認証し合います。
- Transport Layer Security（TLS）
- Application Layer Transport Security（ALTS）
- OAuth
Connect リクエストの各コンポーネントは、以下を使用して互いに認可し合います。
- Identity and Access Management（IAM）
- 許可リスト
Kubernetes クラスタと Google Cloud の間の各接続は、暗号化されます。また、各接続の少なくとも 1 つのピアで、証明書ベースの認証が使用されます。このプロセスによって、すべてのトークン認証情報が送信中に確実に暗号化され、認証かつ承認されたピアによってのみ受信されます。
Google Cloud へのユーザー認証
Cloud Console コンソールを使用する際にユーザーは、標準の Google ログインフローを使用してログインします。Google Cloud は、ユーザーのブラウザが認証する TLS 証明書を提供します。ユーザーは、Google Cloud または Google Workspace のアカウントにログインして Google Cloud への認証を行います。
Google Cloud コンソールや他の API を使用したプロジェクトへのアクセスは、IAM 権限によって制御されます。
Google Cloud サービス間認証
Google Cloud では、内部サービス間認証に ALTS が使用されます。ALTS により、プロキシなどの Google Cloud サービスは、認証済みで完全性が保護された接続を作成できます。
リモート Connect インスタンスに接続するには、Google Cloud サービスがプロキシを使用するように内部で認可されている必要があります。これは、プロキシがサービス ID の許可リストを使用してアクセスを制限しているためです。
Google Cloud の認証
エージェントは、各接続の認証と暗号化に TLS を使用します。エージェントは、エージェントのコンテナに追加された証明書を誤って信頼しないように、バイナリに組み込まれた一連のルート証明書を使用して Google Cloud の TLS 証明書を認証します。エージェントは、正しく認証されたエンドポイントに対してのみ API 呼び出しを実行します。このプロセスにより、サービス アカウント証明書と Kubernetes API リクエストが Google Cloud によって確実に送信され、すべてのレスポンスが Google Cloud にのみ送信されます。
通常のオペレーション中にエージェントが通信するドメインのリストについては、ネットワーク接続を確認するをご覧ください。
エージェントは、HTTP プロキシ経由で Google Cloud に接続するように構成できます。この構成では、エージェントは HTTP プロキシに対して HTTP/1.1
CONNECT を使用し、Google Cloud への TLS 接続を確立します。HTTP プロキシは、エージェントと Google Cloud の間の暗号化されたトラフィックのみを操作します。エージェントと Google Cloud の間の接続のエンドツーエンドの完全性とセキュリティは、影響を受けません。
エージェントの認証
エージェントは、作成した Google Cloud サービス アカウントを使用して、Google Cloud に対する認証を実行します。クラスタ管理者によってエージェントがデプロイされると、このサービス アカウントに秘密鍵が提供され、秘密鍵のプライバシーの管理が行われます。エージェントが Google Cloud に接続されると、このサービス アカウントで認証が実行され、構成されたプロジェクトへのリクエストの受信が要求されます。
Google Cloud により、サービス アカウントの認証情報が認証され、Google Cloud サービス アカウントがプロジェクト内に gkehub.endpoints.connect IAM 権限を持つことも確認されます。通常、この権限は gkehub.connect のロールを介して付与されます。この権限が付与されていない場合、エージェントのリクエストは拒否され、Google Cloud からのリクエストは受信できなくなります。
Kubernetes API サーバー
エージェントは、Kubernetes クライアント ライブラリを使用して、Kubernetes API サーバーへの TLS 接続を作成します。Kubernetes ランタイムによって、TLS 認証局（CA）証明書（エージェントが API サーバーの認証に使用する証明書）がエージェントのコンテナに提供されます。
次のセクションで説明するように、API サーバーは各リクエストを個別に認証します。
セキュリティのリクエスト
Google Cloud から Connect 経由で送信される各リクエストには、リクエストの送信者を識別する認証情報が含まれます。認証情報には、リクエストを作成した Google Cloud サービスと、リクエストの依頼元であるエンドユーザー（該当する場合）の両方が含まれます。これらの認証情報を使用すると、Kubernetes API サーバーは各リクエストに対する認証と監査を管理できます。
サービスとエージェントの間の認証
エージェントに送信される各リクエストには、リクエストを送信した Google Cloud サービスを識別する有効期間が短いトークンが含まれています。
このトークンは、Google Cloud サービス専用の Google Cloud サービス アカウントによって署名されます。エージェントは、サービス アカウントの公開鍵を取得して、トークンを検証します。トークンは、API サーバーに転送されません。
エージェントは、バイナリに埋め込まれた CA ルートを使用して Google Cloud 証明書を検証します。このプロセスにより、Google Cloud からの認証された変更のないリクエストが確実に受信されます。
エンドユーザー認証
次の図に示すように、Google Cloud サービスがユーザーに代わってクラスタにアクセスする場合、API サーバーでの認証用にユーザーの認証情報が必要になります。
このポリシーにより、Connect からアクセスする際に同じ権限セットがユーザーに適用できます。一部の Google Cloud サービスは、ユーザーに代わって API サーバーに対して認証を行います。たとえば、Google Cloud コンソールにアクセスすれば、フリートに登録されたクラスタでワークロードを表示できます。ユーザーがこれらのサービスにアクセスすると、Kubernetes API サーバーが認識する認証情報（Kubernetes API サーバーがサポートする任意のトークン）が提供されます。
Cloud Console コンソールは、ユーザー プロファイルの一部として、これらの認証情報を格納します。これらの認証情報は、保存時に暗号化されます。ユーザーの Google Cloud または Google Workspace の認証情報でのみアクセス可能で、Connect 経由の接続にのみ使用されます。これらの認証情報を再びダウンロードすることはできません。認証情報は、ユーザーがクラスタからログアウトするとき、クラスタ登録が Google Cloud で削除されたとき、プロジェクトが削除されたとき、またはユーザー アカウントが削除されたときに削除されます。詳細については、Google Cloud 上のデータの削除をご覧ください。
ユーザーが Google Cloud コンソールを操作すると、Kubernetes API サーバーに対するリクエストが生成されます。サービスは、Connect を介して、ユーザーの認証情報をリクエストとともに送信します。その後、エージェントによって、Kubernetes API サーバーにリクエストと認証情報が提示されます。
Kubernetes API サーバーは、ユーザー認証情報の認証、ユーザー ID の認可、操作の監査イベントの作成（構成されている場合）を行い、結果を返します。ユーザーが指定した認証情報は、リクエストの認証に使用されるため、Kubernetes API サーバーは、Connect リクエストとその他のリクエストの認証と監査に同じポリシーを適用します。
サービスと Kubernetes の間の認証
Kubernetes API サーバーにユーザーのコンテキスト外でアクセスする Google Cloud サービスは、Kubernetes になりすまして Kubernetes API サーバーの認証を受けます。このメソッドにより、Kubernetes API サーバーは、次の図に示すように、サービスごとに認証チェックと監査ロギングを実行できます。
Google Cloud のサービスは、ユーザーのコンテキスト外で Connect を使用できます。たとえば、マルチクラスタの上り（内向き）サービスによって、クラスタ全体の上りリソースを自動的に同期できます。これらのサービスには、Kubernetes API サーバーが認証できる認証情報がありません。ほとんどの API サーバーは、Google Cloud サービスの認証情報を認証するように構成されていません。ただし、API サーバーは、権限借用により限定的な認証権限を別のサービスに委任できます。エージェントは、Connect を使用してリクエストを送信する Google Cloud サービスを認証できます。これにより、エージェントによるリクエストが Google Cloud サービス アカウントとして認証されます。
Google Cloud サービスがユーザーのコンテキストではなく自身でリクエストを送信すると、エージェントは、Google Cloud サービスを識別する独自の Kubernetes 認証情報と Kubernetes 権限借用ヘッダーをリクエストに追加します。権限借用ヘッダーは、エージェントにより認証された Google Cloud サービス アカウントのユーザー名を申し立てます。
Kubernetes API サーバーは、エージェントの認証情報を認証し、エージェントが Google Cloud サービス アカウントの権限借用ができることを確認します。権限借用機能は通常、ロールベース アクセス制御（RBAC）ルールによって制御され、Google Cloud サービス アカウントなどの特定の ID に限定できます。
エージェントがリクエストされた ID を借用する権限を持つ場合、API サーバーは、Google Cloud サービス アカウントに対して認証チェックを実行し、リクエストを処理します。リクエストの監査ログには、エージェントの ID と権限を借用した Google Cloud サービス アカウントの両方が記録されます。
クラスタ内のセキュリティ
次の図に示すように、エージェントは最終的に Kubernetes API サーバーに Kubernetes API リクエストを送信します。
Kubernetes API サーバーは、その他のすべてのリクエストと同様に、リクエストの認証、承認、および監査ログを記録します。
エージェントは、リクエストに対するプロキシとして、認証情報、リクエスト、レスポンスなどのセンシティブ データへのアクセス権を持ちます。Kubernetes および Kubernetes のエコシステムが提供するツールには、その他のアクターによるアクセスを防止するツールとエージェントの接続先を限定するためのツールがあります。
Kubernetes 認証
Kubernetes API サーバーは、各受信リクエストの送信者を認証して、承認段階で適用する権限を決定します。前述のようにリクエストには、ユーザーの認証情報、またはエージェントの Kubernetes 認証情報となりすましヘッダーの組み合わせのいずれかが含まれます。
Kubernetes API サーバーで認識される認証メカニズムは、クラスタ管理者が引き続き制御します。管理者は、ユーザーの認証情報を取り消すことができます。また、エージェントの認証情報の権限を取り消すことや、減らすことができます。
Kubernetes の認可
Kubernetes API サーバーは、認証された ID がリクエストされたリソースに対してリクエストされた操作を実行できることを確認します。
クラスタ管理者は、Kubernetes 認証メカニズムのうちのいずれかを使用して認証ルールを構成できます。Connect がクラスタに代わって認証チェックを実行することはありません。
エージェントのセキュリティ
エージェントには、自身の認証情報（Kubernetes と Google Cloud）、と、それを通過する認証情報、リクエスト、レスポンスへのアクセス権が付与されます。したがって、エージェントは接続されたクラスタ内で信頼される位置を占めています。
エージェントは、次のようなセキュリティの基本を踏まえて設計されます。
- エージェントは、ガベージ コレクションによるメモリ管理を提供する Go で記述されます。これにより、危険なメモリ操作が防止されます。
- エージェントは、distoress コンテナ イメージ内にデプロイされます。エージェントのイメージには、シェル、libc、およびエージェントの実行パスに無関係なその他の余分なコードは含まれません。
- エージェントのイメージは、Google の共有ビルド インフラストラクチャによって、チェックインされたコードからビルドされます。このビルドシステムのみが、エージェント イメージを Container Registry にデプロイできます。Google Cloud のデベロッパーは、自分で新しいイメージをデプロイすることはできません。このプロセスにより、エージェントのソースのすべての編集箇所についてその著者と校閲者を追跡し、否認を防止できます。
エージェントは、クラスタ登録時のデプロイを実行する Kubernetes クラスタにおける標準の導入として実行されます。その結果、エージェントは、導入のモニタリングとセキュリティ保護のためのすべてのオプションとベスト プラクティス、ReplicaSets、およびポッドを利用できます。
これらのメカニズムは、エージェント コンテナが不正使用されないように設計されています。ただし、エージェントのノードへのアクセス権はエージェントの環境に影響するため、クラスタ インフラストラクチャを保護するための標準の Kubernetes セキュリティ ガイドラインを遵守する必要があります。
VPC Service Controls を使用したデータ セキュリティ
VPC Service Controls によって、Identity and Access Management（IAM）から独立している Google Cloud サービスに対するセキュリティが強化されます。IAM では詳細な ID ベースのアクセス制御が可能ですが、VPC Service Controls では、境界全体での下り（外向き）データの制御など、より広範なコンテキスト ベースの境界セキュリティが可能になります。たとえば特定のプロジェクトのみが BigQuery データにアクセスできるように指定できます。VPC Service Controls によるデータ保護の仕組みについて詳しくは、VPC Service Controls の概要をご覧ください。
VPC Service Controls と Connect を併用すると、Connect を使用するために必要サービスが、指定したサービス境界内からアクセスできるので、データ セキュリティを強化できます。詳しくは、Connect の前提条件をご覧ください。