GKE クラスタで Cloud Service Mesh の Egress ゲートウェイを使用するためのベスト プラクティス
このドキュメントでは、Cloud Service Mesh の Egress ゲートウェイやその他の Google Cloud コントロールを使用して、Google Kubernetes Engine クラスタにデプロイされたワークロードからの送信トラフィック（下り、外向き）を保護する方法について説明します。これらのコントロールを使用すると、ソース アプリケーションの ID、チームの Namespace、宛先ドメイン、送信リクエストのその他のプロパティに基づいて、外部サービスへの接続を制限できます。
このドキュメントの対象読者は、1 つ以上のソフトウェア配信チームが使用する GKE クラスタを管理するネットワーク エンジニア、プラットフォーム エンジニア、セキュリティ エンジニアです。ここで説明する制御は、規制（GDPR や PCI など）の遵守を実証しなければならない組織に特に有効です。
はじめに
ネットワーク セキュリティに対する従来のアプローチでは、アプリケーションのグループの周囲にセキュリティ境界を定義する必要がありました。ファイアウォールはこれらの境界で使用され、送信元と宛先の IP アドレスに基づいてトラフィックを許可または拒否し、境界に含まれるアプリケーションとトラフィックを信頼します。ただし、この信頼にはリスクが伴います。悪意のある内部関係者などが境界を侵害して、ネットワーク内を自由に移動し、データへのアクセスと引き出し、サードパーティ システムへの攻撃、管理システムの妨害を行う可能性があります。
Kubernetes クラスタ上で実行されているワークロードがインターネット上のホストへの下り（外向き）接続を行う場合、従来の IP ベースのセキュリティ管理の適用は次の原因により複雑になる場合があります。
Pod IP アドレスが、接続を行うワークロードの ID を適切に表していません。Kubernetes 環境では、Pod の IP アドレスが一時的に割り当てられ、Pod が稼働したときに頻繁にリサイクルされます。
特定の宛先ホスト用に少数で固定された IP アドレスのセットを特定することは通常ありえません。IP アドレスは頻繁に変更され、リージョンごとに異なります。広い範囲から取得されるか、キャッシュ、プロキシ、または CDN を表す場合があります。
ソース IP の範囲を共有し、複数のマルチテナント クラスタを共有する複数のチームで、外部接続の要件が異なる場合があります。
Cloud Service Mesh は、オープンソースの Istio サービス メッシュをベースにした Google Cloud 上のフルマネージド サービス メッシュです。サービス メッシュを使用すると、アプリケーション間の通信を一貫した方法で接続、管理、保護できます。サービス メッシュは、ネットワーク IP 中心のアプローチではなくアプリケーション中心のアプローチを採用し、信頼できるアプリケーション ID を使用します。
既存のアプリケーション コードを変更することなく、サービス メッシュを透過的にデプロイできます。サービス メッシュを使用すると、ネットワークの動作を宣言的に管理することにより、アプリケーションの機能の提供とリリースを担当する開発チームの作業をネットワーク管理者の責任から分離できます。
Cloud Service Mesh は、メッシュのエッジに、スタンドアロンのフォワード プロキシ（Egress ゲートウェイ）をデプロイする選択肢を提供します。このガイドでは、Egress ゲートウェイ プロキシの機能と Google Cloud の機能を組み合わせて、GKE クラスタにデプロイされたワークロードからの送信トラフィックを制御、認可、監視する方法について説明します。
多層防御アーキテクチャ
次の図は、複数のチームで使用されるクラスタの下り（外向き）トラフィックをきめ細かく制御する多層防御アプローチを採用しているアーキテクチャを示しています。これらの制御は、レイヤ 4（トランスポート）とレイヤ 7（アプリケーション）の両方のネットワーク制御に基づいています。
このアーキテクチャでは、次のリソースと制御が使用されます。
限定公開 GKE クラスタ: 限定公開 GKE クラスタのノードは内部 IP アドレスのみを持ち、デフォルトではインターネットに接続されません。
Cloud NAT: Cloud NAT は、限定公開クラスタからの送信インターネット アクセスを許可します。
Virtual Private Cloud（VPC）ファイアウォール ルール: GKE クラスタ内のノード間の接続にレイヤ 4（トランスポート）制御を適用するように VPC ファイアウォール ルールを構成します。サービス アカウントまたはネットワーク タグに基づいて、VPC ファイアウォール ルールを VM に適用できます。
サービス アカウントが異なる GKE ノードプール: 異なるファイアウォール ルールを構成して、ノードが属するノードプールに応じて適用します。
Kubernetes Namespace: チームごとに Namespace を作成して、分離を確保し、管理権限を委任します。ネットワーク管理者は、専用の Namespace を使用して Egress ゲートウェイをデプロイし、外部ホストへのルーティングを構成します。
Kubernetes ネットワーク ポリシー: ネットワーク ポリシーを使用すると、レイヤ 4 の制御を Pod に適用できます。各ネットワーク ポリシーは Namespace のスコープであり、Namespace 内の特定の Pod に対するスコープをさらに絞り込むことができます。
Egress ゲートウェイ: メッシュ内の Pod から発信されるトラフィックは、専用ノードで実行されている専用の Egress ゲートウェイ プロキシを経由します。HorizontalPodAutoscaler を使用して Egress ゲートウェイをデプロイし、レプリカの数に基づいてトラフィックをスケールします。
認証ポリシー: メッシュ認証ポリシーを使用して、メッシュ内の Pod 間のトラフィックと、メッシュから出るトラフィックにレイヤ 7（アプリケーション）制御を適用します。
サイドカー リソース: サイドカー リソースを使用して、各ワークロード Pod で実行されるサイドカー プロキシの構成スコープを制御します。サイドカー リソースを使用して、ワークロードに表示される Namespace、Pod、外部サービスを構成できます。
限定公開の Google アクセス: このオプションを使用すると、限定公開クラスタのノードと Pod が Google API にアクセスし、Container Registry から Docker イメージを pull できます。
GKE Workload Identity: Workload Identity では、Identity and Access Management（IAM）を使用して、最小権限の原則に従う特定のワークロードに API の権限を付与できます（Secret を処理する必要はありません）。
下り（外向き）制御の構成
Egress ゲートウェイを使用してメッシュからの下り（外向き）トラフィックを保護する場合は、このセクションで説明する多層防御制御を構成することをおすすめします。
Cloud NAT で限定公開 GKE を使用する
セキュリティが重要な場合、多くの組織にとって最初の要件は、ワークロードにパブリック IP アドレスを割り当てないようにすることです。限定公開 GKE クラスタがこの要件を満たします。VPC ネイティブ モードは限定公開クラスタで構成できます。これにより、VPC 内のセカンダリ範囲から Pod とサービスに IP アドレスが割り振られます。VPC ネイティブ Pod の IP アドレスは VPC ネットワーク内でネイティブにルーティングできます。
一部のワークロードでは、VPC ネットワークと外部のサービスへのアクセスが必要になる場合があります。ワークロードがパブリック IP アドレスを使用することなく外部ホストに接続できるようにするには、ネットワーク アドレス変換（NAT）を提供するように Cloud NAT を構成します。
Egress ゲートウェイが外部宛先に十分な数の同時接続を行うように Cloud NAT が構成されていることを確認します。VM あたりの最小ポート数を適切に設定することで、ポートの消耗や接続再試行の遅延を回避できます。詳細については、Cloud NAT アドレスとポートの概要をご覧ください。Egress ゲートウェイのレプリカの数を増やすと、エンドポイントに依存しないマッピングの競合が発生するリスクを軽減できます。
Google API とサービスへの限定公開の Google アクセスを構成する
ワークロードで Google API とサービスへのアクセスが必要になる可能性があります。カスタム DNS ゾーンで限定公開の Google アクセスを使用し、4 つの IP アドレスのセットを使用したプライベート VPC サブネットから Google API への接続を許可します。これらの IP アドレスを使用する場合、Pod が外部 IP アドレスを持っていなくても、トラフィックは Google ネットワークを離れません。VPC Service Controls を使用しているかどうかに応じて、private.googleapis.com（199.36.153.8/30）または restricted.googleapis.com（199.36.153.4/30）を使用できます。
Workload Identity と IAM を使用して Google API とサービスのセキュリティを強化する
GKE ワークロードが Google API で認証され、管理者が IAM を使用して「最小権限」承認制御を適用できるようにするには、Workload Identity を使用することをおすすめします。
限定公開の Google アクセス、Workload Identity、IAM を使用する場合、ワークロード Pod が Egress ゲートウェイをバイパスして Google API とサービスの直接接続を安全に行うことができます。
管理制御に Kubernetes Namespace を使用する
Namespace は、多数のユーザー、チーム、テナントがある環境で役立つ組織リソースです。これらは仮想クラスタと考えることができ、Kubernetes リソースのグループの管理責任を異なる管理者に委任できます。
Namespace は管理を分離するための重要な機能です。ただし、デフォルトではノード分離、データプレーン分離、ネットワーク分離を行うことはできません。
Cloud Service Mesh は、サービス メッシュ内のテナンシー ユニットとして Kubernetes Namespace を使用して構築されています。メッシュ認証ポリシーとサイドカー リソースは、ネットワーク トラフィックの Namespace、ID、レイヤ 7（アプリケーション）属性に基づいて可視性とアクセスを制限できます。
同様に、Kubernetes ネットワーク ポリシーを使用して、レイヤ 4（トランスポート）でネットワーク接続を許可または拒否できます。
専用のゲートウェイ ノードで Egress ゲートウェイを実行する
専用のゲートウェイ ノードプール内のノードで Egress ゲートウェイを実行することには、いくつかの利点があります。外部に公開されているノードでは強化された構成を使用できます。また、ワークロードが外部ホストに直接到達しないように VPC ファイアウォール ルールを構成できます。ノードプールは、クラスタ オートスケーラーを使用して個別に自動スケーリングできます。
Egress ゲートウェイの個別の管理制御を許可するには、専用の istio-egress Namespace にデプロイします。ただし、Namespace はクラスタ全体のリソースであり、デプロイが実行されるノードを制御するために使用することはできません。デプロイを制御するには、Egress ゲートウェイのデプロイにノードセレクタを使用します。これにより、ゲートウェイ ノードプールのメンバーとしてラベル付けされたノードで実行されます。
ゲートウェイ ノードではゲートウェイ Pod のみが実行されるようにします。他の Pod はゲートウェイ ノードから排除する必要があります。そうしないと、下り（外向き）制御がバイパスされる可能性があります。taint と容認を使用すると、特定のノードでワークロードが実行されないようにすることができます。ゲートウェイ ノードプール内のノードを保持し、対応する容認を Egress ゲートウェイのデプロイに追加する必要があります。
特定のノードに VPC ファイアウォール ルールを適用する
デフォルトのノードプールで実行されているワークロードからの下り（外向き）トラフィックが、ゲートウェイ ノードプールで運用されている Egress ゲートウェイを経由するように、サービス メッシュ ルーティングを構成します。ただし、ワークロードがメッシュ プロキシをバイパスするさまざまな方法が存在するため、メッシュのルーティング構成はセキュリティ境界として信頼すべきではありません。
アプリケーション ワークロードが外部ホストに直接接続されないようにするには、デフォルトのノードプールでノードに限定的な下り（外向き）ファイアウォール ルールを適用します。ゲートウェイ ノードで実行中の Egress ゲートウェイ Pod が外部ホストに接続できるように、ゲートウェイ ノードに個別のファイアウォール ルールを適用します。
VPC ファイアウォール ルールを作成するときに、ファイアウォール ルールで許可または拒否するポートとプロトコル、適用するトラフィックの方向を指定します。下り（外向き）ルールは送信トラフィックに適用され、上り（内向き）ルールは受信トラフィックに適用されます。下り（外向き）のデフォルト値は allow、上り（内向き）のデフォルト値は deny です。
ファイアウォール ルールは、指定した優先度に基づいて順番に適用されます。ファイアウォール ルールはステートフルです。つまり、VM からの特定のトラフィックを許可すると、同じ接続を使用するトラフィックも許可されます。
次の図は、ノードに割り当てられているサービス アカウントに基づいて、2 つの異なるノードプールのノードに個別のファイアウォール ルールを適用する方法を示しています。この場合、デフォルトの deny all ファイアウォール ルールにより、VPC 全体の下り（外向き）アクセスが拒否されます。クラスタの動作に必要なデフォルトのファイアウォール ルールをオーバーライドしないように、deny all ルールには低い優先度（65535 など）を使用する必要があります。ゲートウェイ ノードに優先度の高い追加の下り（外向き）ファイアウォール ルールが適用され、ポート 80 と 443 での外部ホストとの直接接続が許可されます。デフォルトのノードプールは外部ホストにアクセスできません。
Pod と Namespace のファイアウォールとして Kubernetes ネットワーク ポリシーを使用する
多層防御戦略の一環として Kubernetes ネットワーク ポリシーを使用し、セキュリティをさらに強化します。ネットワーク ポリシーは Namespace をスコープとし、レイヤ 4（トランスポート）で動作します。ネットワーク ポリシーを使用すると、次の上り（内向き）と下り（外向き）を制限できます。
- Namespace 間のトラフィック
- Namespace 内の Pod へのトラフィック
- 特定のポートと IP ブロックへのトラフィック
ネットワーク ポリシーで Namespace 内の Pod が選択されると、明示的に許可されていない接続はすべて拒否されます。複数のネットワーク ポリシーを適用すると、結果が加算され、ポリシーの結合体となります。ポリシーの適用順序は関係ありません。
ネットワーク ポリシーの例を次に示します。
- ワークロードの Namespace から
istio-systemとistio-egressの Namespace への下り（外向き）接続を許可します。Pod はコントロール プレーンと下り（外向き）ゲートウェイに接続できなければなりません。 - ワークロードの Namespace から
kube-systemNamespace のポート 53 への DNS クエリを発行するワークロードを許可します。 - 必要に応じて、同じ Namespace のワークロードが互いに接続できるようにします。
- 必要に応じて、異なるアプリケーション チームで使用される Namespace 間の下り（外向き）接続を許可します。
- ワークロードの Namespace から Google API（限定公開の Google アクセスによって公開）の VIP への下り（外向き）接続を許可します。Cloud Service Mesh はマネージド CA を提供し、それを API として公開します。このため、サイドカー プロキシはこの CA に接続する必要があります。また、一部のワークロードでは Google API へのアクセスが必要になる場合もあります。
- ワークロードの Namespace から GKE メタデータ サーバーへの下り（外向き）接続を許可し、サイドカー プロキシとワークロードがメタデータ クエリを作成して Google API で認証できるようにします。
デフォルトでは、サイドカー プロキシをワークロード Pod に挿入すると、iptables ルールが設定され、プロキシですべての送受信 TCP トラフィックがキャプチャされます。ただし、前述のようにワークロードはプロキシのバイパスが可能です。VPC ファイアウォール ルールは、ワークロードを実行するデフォルト ノードからの直接下り（外向き）アクセスを防ぎます。Kubernetes ネットワーク ポリシーを使用して、ワークロードの Namespace からの直接的な外部への下り（外向き）を禁止し、istio-egress Namespace への下り（外向き）を許可してください。
ネットワーク ポリシーで上り（内向き）も制御する場合は、下り（外向き）ポリシーに合わせて上り（内向き）ポリシーを作成する必要があります。
Service Mesh の構成とセキュリティ
サービス メッシュで実行されるワークロードは IP アドレスで識別されません。Cloud Service Mesh では、各ワークロードに X.509 証明書と鍵の形式で検証される強力な ID が割り当てられます。ワークロード間の信頼できる通信は、暗号化された認証済みの相互 TLS（mTLS）接続によって確立されます。
各アプリケーションに明確に定義された ID と mTLS 認証を使用した場合、メッシュ認証ポリシーを使用して、ワークロードと外部サービスとの通信方法をきめ細かく制御できます。
トラフィックはサイドカー プロキシを介して直接メッシュから送信されることもできますが、さらに制御が必要な場合は、このガイドで説明するように Egress ゲートウェイ経由でトラフィックを転送することをおすすめします。
専用の Namespace 内の下り（外向き）制御の構成を管理する
ネットワーク管理者は、下り（外向き）関連のメッシュ構成に専用の istio-egress Namespace を使用して、制御を集中管理できます。以前に推奨されたように、Egress ゲートウェイを istio-egress Namespace にデプロイします。この Namespace でサービス エントリ、ゲートウェイ、認証ポリシーを作成して管理できます。
外部の宛先の明示的な構成を要求する
メッシュ プロキシが、サービス メッシュ レジストリで明示的に定義されている外部ホストへのルートのみでプログラムされていることを確認します。各 Namespace のデフォルトのサイドカー リソースで送信トラフィック ポリシーモードを REGISTRY_ONLY に設定します。メッシュに送信トラフィック ポリシーを設定しても、それだけではセキュアな境界制御とはみなされません。
サービス エントリで外部の宛先を定義する
メッシュのサービス レジストリで外部ホストを明示的に登録するようにサービス エントリを構成します。デフォルトでは、サービス エントリはすべての Namespace に表示されます。exportTo 属性を使用して、サービス エントリが表示される Namespace を制御します。サービス エントリはメッシュ プロキシで構成される外部ルートを決定しますが、それ自体は接続する外部ホストを決定するための安全な管理機能であるとはみなされません。
Gateway リソースで Egress ゲートウェイの動作を構成する
Gateway リソースを使用して、Egress ゲートウェイの負荷分散の動作を構成します。ロードバランサは、ホスト、プロトコル、ポートの特定のセットに構成でき、Egress ゲートウェイのデプロイに関連付けられます。たとえば、外部ホストのポート 80 と 443 への下り（外向き）にゲートウェイが構成されていることがあります。
Cloud Service Mesh では、自動 mTLS がデフォルトで有効になっています。自動 mTLS の場合、クライアント サイドカー プロキシがサーバーにサイドカーがあるかどうかを自動的に検出します。クライアント サイドカーは、サイドカーを含むワークロードには mTLS を送信し、サイドカーを含まないワークロードには書式なしテキストのトラフィックを送信します。自動 mTLS を使用する場合でも、サイドカー プロキシから Egress ゲートウェイに送信されたトラフィックは自動的に mTLS を使用しません。Egress ゲートウェイとの接続を保護する方法を示すには、Gateway リソースに TLS モードを設定する必要があります。可能な限り、サイドカー プロキシから Egress ゲートウェイへの接続に mTLS を使用してください。
ワークロード自体が TLS（HTTPS）接続を開始できるようにすることも可能です。ワークロードが TLS 接続を開始した場合（通常はポート 443）、そのポート上の接続に passthrough モードを使用するようにゲートウェイを構成する必要があります。ただし、passthrough モードでは、ゲートウェイの ID または暗号化されたリクエストのプロパティに基づいて認証ポリシーを適用できません。また、現時点では、mTLS と passthrough の併用はできません。
ゲートウェイ経由でトラフィックをルーティングするように仮想サービスと宛先ルールを構成する
仮想サービスと宛先ルールを使用して、Egress ゲートウェイ経由でのサイドカー プロキシから外部宛先へのトラフィック転送を構成します。仮想サービスは、特定のトラフィックを照合するルールを定義し、一致した場合にトラフィックが宛先に送信されます。宛先ルールでは、サブセット（Egress ゲートウェイや外部ホストなど）と、宛先への転送時にトラフィックがどのように処理されるかを定義できます。
複数の宛先ホストに単一の宛先ルールを使用して、サイドカー プロキシからゲートウェイへのトラフィックを保護する方法を明示的に指定します。前述のように、ワークロードが書式なしテキストのリクエストを送信し、サイドカー プロキシがゲートウェイとの mTLS 接続を開始できるようにするのが推奨の方法です。
各外部ホストに宛先ルールを使用して、宛先への転送時に TLS（HTTPS）接続を使用するようにプレーン HTTP リクエストを「アップグレード」するように Egress ゲートウェイを構成します。書式なしテキストでの接続を TLS にアップグレードすることを「TLS 開始」ともいいます。
サイドカー リソースでプロキシ構成のスコープを管理する
サイドカー プロキシの動作を制御するには、各 Namespace にデフォルトのサイドカー リソースを構成します。プロキシの送信リスナーで構成された宛先ホストを制御し、最小化するには、サイドカー リソースの下り（外向き）プロパティを使用します。一般的な最小構成では、Namespace ごとに次の宛先を含めることができます。
- 同じ Namespace 内の Pod
- Google API とサービス
- GKE メタデータ サーバー
- サービス エントリを使用して構成された特定の外部ホスト
サイドカー プロキシの送信リスナーを構成しても、それ自体がセキュリティ管理とはみなされません。
プロキシ構成のサイズを制限するために、サイドカー リソースを使用することがベスト プラクティスです。デフォルトでは、メッシュの各サイドカー プロキシは、他のすべてのプロキシにトラフィックを送信できるように構成されています。サイドカー プロキシとコントロール プレーンのメモリ消費を大幅に削減するには、プロキシの構成を通信する必要があるホストにのみ制限します。
認証ポリシーを使用して Egress ゲートウェイでトラフィックを許可または拒否する
AuthorizationPolicy は、メッシュ トラフィックの詳細なアクセス制御ポリシーを構成するためのリソースです。送信元、宛先、トラフィック自体のプロパティ（たとえば、HTTP リクエストのホストやヘッダー）に基づいてトラフィックを許可または拒否するポリシーを作成できます。
ソース ワークロードの ID または Namespace に基づいて接続を許可または拒否するには、Egress ゲートウェイへの接続を mTLS で認証する必要があります。サイドカーから Egress ゲートウェイへの接続には mTLS が自動的に使用されないため、ゲートウェイへの接続の宛先ルールは、ISTIO_MUTUAL TLS モードを明示的に指定する必要があります。
認証ポリシーを使用してゲートウェイでリクエストを許可または拒否するには、ワークロードからメッシュの外部の宛先にプレーンな HTTP リクエストを送信する必要があります。サイドカー プロキシは mTLS を使用してリクエストをゲートウェイに転送でき、ゲートウェイは外部ホストへの安全な TLS 接続を開始できます。
さまざまなチームやアプリケーションの下り（外向き）の要件に対応するには、Namespace またはワークロードごとに別々の「最小権限」認証ポリシーを構成します。たとえば、次のように、ソース ワークロードの Namespace とリクエストの属性に基づいてルールを指定することで、Egress ゲートウェイで異なるポリシーを適用できます。
ソース Namespace が team-x、宛先ホストが example.com の場合、トラフィックを許可します。
ソース Namespace が team-y、宛先ホストが httpbin.org、パスが /status/418 の場合、トラフィックを許可します。
他のリクエストはすべて拒否します。
宛先への TLS（HTTPS）接続を開始するように Egress ゲートウェイを構成する
Egress ゲートウェイが外部宛先への TLS（HTTPS）接続を開始できるように、宛先ルールを構成します。
Egress ゲートウェイで TLS 開始が機能するためには、ワークロードはプレーンな HTTP リクエストを送信する必要があります。ワークロードが TLS を開始した場合、Egress ゲートウェイは元の TLS 上に TLS をラップし、外部サービスへのリクエストは失敗します。
ワークロードはプレーンな HTTP リクエストを送信するため、ワークロードのサイドカー プロキシを構成して、ゲートウェイへの送信時に mTLS 接続を確立します。その後、Egress ゲートウェイは mTLS 接続を終了し、宛先ホストへの通常の TLS（HTTPS）接続を開始します。
このアプローチにはいくつかのメリットがあります。
認証ポリシーを使用すると、ソースのワークロードとリクエストの属性に基づいてトラフィックを許可または拒否できます。
ワークロード Pod と Egress ゲートウェイの間のトラフィックは暗号化および認証（mTLS）され、Egress ゲートウェイと宛先の間のトラフィックは暗号化されます（TLS / HTTPS）。
メッシュ内では、サイドカー プロキシが HTTP リクエストのプロパティ（ヘッダーなど）を監視して対処し、オブザーバビリティと制御に関する追加オプションを提供します。
アプリケーション コードを簡略化できます。デベロッパーが証明書や HTTPS クライアント ライブラリを処理する必要はありません。サービス メッシュにより、標準的な暗号や最新の暗号を使った安全な通信を実現できます。
Egress ゲートウェイが外部サービス向けに開始する TLS 接続は、多数の Pod からのトラフィックに再利用できます。接続の再利用はより効率的であり、接続が制限に達するリスクを軽減できます。
DNS、ホスト名、ワイルドカード
宛先ホストに基づいてトラフィックのルーティング、拒否、許可を行うには、DNS システムの整合性が完全に信頼され、DNS 名を正しい IP アドレスに解決する必要があります。Kubernetes Engine クラスタでは、Kubernetes DNS サービスが DNS クエリを処理し、外部クエリを GKE メタデータ サーバーと内部 DNS に委任します。外部ホストにルーティングする際に、サービス エントリの解決属性を DNS に設定し、サイドカー プロキシが DNS クエリを行うようにします。
Cloud Service Mesh では、ワイルドカード ホストに基づいてトラフィックを転送できます。最も単純なケースは、共通の名前を共有し、共通のサーバーセットでホストされるホスト用のワイルドカードです。たとえば、*.example.com で一致したドメインを単一セットのサーバーが処理できる場合、ワイルドカード ホストを使用できます。
Istio で使用される Envoy プロキシの制限により、標準の Egress ゲートウェイは、より一般的で任意のワイルドカード ホスト（*.com など）に基づいて転送を行うことができません。Envoy は、事前定義されたホスト、事前定義された IP アドレス、またはリクエストの元の宛先 IP アドレスにのみトラフィックを転送できます。Egress ゲートウェイを使用する場合、リクエストの元の宛先 IP は失われます。これは、ゲートウェイの IP に置き換えられ、任意の宛先ホストを事前構成できないためです。
ポリシーの管理者による適用
Kubernetes ロールベースのアクセス制御（RBAC）を使用する
認証された管理者にのみ下り（外向き）制御の構成を許可する必要があります。下り（外向き）制御の不正な回避を防ぐため、Kubernetes のロールベースのアクセス制御（RBAC）を構成します。RBAC ロールを適用することで、ネットワーク管理者だけが istio-egress、istio-system,、kube-system の Namespace と次のリソースを管理できるようにします。
- Sidecar
- ServiceEntry
- ゲートウェイ
- AuthorizationPolicy
- NetworkPolicy
容認機能の使用の制限
前述のように、taint と容認機能を使用することで、ゲートウェイ ノードへのワークロード Pod のデプロイを防ぐことができます。ただし、デフォルトでは、ゲートウェイ ノードの容認機能でワークロードのデプロイが防止されないため、下り（外向き）の制御がバイパスされる可能性があります。デプロイメント パイプラインに集中管理権限を適用できる場合は、それらを使用して特定の容認機能キーの使用を制限できます。
また、Kubernetes アドミッション コントロールを使用する方法もあります。Anthos には Policy Controller というコンポーネントがあります。これは、Kubernetes アドミッション コントローラとして機能し、指定したポリシーの制約を満たしているかどうかデプロイを検証します。
トラフィックがログに記録されていることを確認する
多くの場合、ネットワーク境界を越えたトラフィックをすべて記録する必要があります。共通のデータ保護規制の遵守を実証する必要がある場合、トラフィック ロギングは不可欠です。トラフィック ログは Cloud Logging に直接送信され、Google Cloud コンソールの Cloud Service Mesh ダッシュボードからアクセスできます。送信元 / 宛先、ID、名前空間、トラフィックの属性、レイテンシなど、さまざまな属性に基づいてログをフィルタリングできます。
kubectl を使用して簡単にデバッグできるようにするには、Cloud Service Mesh のインストール時に、accessLogFile 設定を使用して stdout へのトラフィック ロギングを有効にします。
Mesh CA がワークロードの証明書を作成するたびに、監査ログが Cloud Logging に送信されます。
複数クラスタ メッシュの Egress ゲートウェイに別のクラスタの使用を検討する
Cloud Service Mesh は複数の GKE クラスタにデプロイできます。マルチクラスタ メッシュを使用すると、下り（外向き）トラフィックを制御しながら新たな制限を実現できます。
専用のノードプールに Egress ゲートウェイをデプロイする代わりに、通常のワークロードを実行しない別のクラスタにゲートウェイをデプロイできます。個別のクラスタを使用すると、ワークロードとゲートウェイを同様に分離できます。同時に、taint と容認機能も必要ありません。Egress ゲートウェイでは、別々のクラスタを Ingress ゲートウェイやその他のセントラル サービスと共有できます。
マルチクラスタ デプロイでは Kubernetes ネットワーク ポリシーを使用できますが、レイヤ 4（トランスポート）で動作するため、宛先の Namespace または Pod に基づいてクラスタ間の接続を制限することはできません。
次のステップ
- GKE 強化ガイドを読む。
- Anthos Configuration Management ですべてのインフラストラクチャの構成とポリシーを管理する方法を学習する。
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。