Istio API セキュリティのベスト プラクティスを使用する Cloud Service Mesh

このドキュメントでは、Google Kubernetes Engine（GKE）で実行される安全な Cloud Service Mesh の構成を確立して管理するためのベスト プラクティスについて説明します。このドキュメントでは、セキュリティ脅威からアプリケーションを保護するために、Cloud Service Mesh の構成とプロビジョニングで使用する設定と、Cloud Service Mesh と他の Google Cloud プロダクトおよび機能を使用する方法について説明します。

このドキュメントは、Cloud Service Mesh でポリシーを管理する管理者と、Cloud Service Mesh でサービスを実行するサービス オーナーを対象にしています。ここで説明するセキュリティ対策は、コンプライアンス要件を満たすためにサービス メッシュのセキュリティを強化する必要がある組織にも有効な対策です。

ドキュメントの構成は次のとおりです。

• はじめに
• 攻撃ベクトルとセキュリティ リスク
  • 攻撃ベクトル
  • セキュリティ リスク
• サービス メッシュを保護する対策
  • セキュリティ アーキテクチャ
  • クラスタ セキュリティ
    • 厳格な相互 TLS を有効にする
    • アクセス制御を有効にする
      • Cloud Service Mesh の認証ポリシーを適用する
      • JSON Web Token（JWT）
      • Cloud Service Mesh のユーザー認証
      • 認可ポリシーを適用する
      • メッシュ サービスへのアクセスにトークン交換を適用する
    • Cloud Service Mesh ポリシーの例外を安全に処理する
      • Kubernetes NetworkPolicy を適用する
    • Namespace の境界を適用する
      • Kubernetes RBAC ポリシーを適用する
  • メッシュエッジのセキュリティ
    • クラスタの上り（内向き）アクセスの制御
    • クラスタの下り（外向き）トラフィックを規制する
    • 限定公開クラスタまたは VPC Service Controls を使用して外部アクセスを遮断する
    • 外部の DDoS 攻撃から防御する
  • メッシュの管理と自動化のセキュリティ
    • メッシュ オペレーションに使用されるロールを分割する
    • ポリシー構成を自動的に検証する
      • Config Sync で GitOps アプローチを使用して構成のずれを防ぐ
    • Cloud Audit Logs とモニタリングを適用する
  • ワークロード セキュリティ
    • Pod の権限を制限する
    • コンテナ イメージを保護する
    • メッシュの脆弱性を軽減する
    • Workload Identity Federation for GKE を使用して Google サービスに安全にアクセスする
    • セキュリティ ダッシュボードとテレメトリーでセキュリティ ステータスをモニタリングする
  • 機密性の高いユーザーデータと認証情報を保護するセキュリティ

はじめに

Cloud Service Mesh は、サービスを一元的にモニタリング、管理、保護するための機能とツールを提供します。これは、ネットワーク IP を中心としたアプローチではなく、アプリケーション中心のアプローチを採用し、信頼できるアプリケーション ID を使用します。既存のアプリケーション コードを変更することなく、サービス メッシュを透過的にデプロイできます。Cloud Service Mesh では、ネットワークの動作を宣言的に制御できます。これにより、アプリケーションの機能の提供とリリースを担当するチームの作業を、セキュリティとネットワーキングを担当する管理者から分離できます。

Cloud Service Mesh はオープンソースの Istio サービス メッシュをベースとし、高度な構成とトポロジを実現します。組織の体制によっては、1 つ以上のチームまたはロールがメッシュのインストールと構成を担当する場合があります。Cloud Service Mesh のデフォルトの設定は、アプリケーションを保護するように設定されていますが、カスタム構成が必要になることもあります。または、特定のアプリ、ポート、IP アドレスのメッシュへの参加を防ぐことにより、例外の作成が必要になることもあります。メッシュの構成とセキュリティの例外を管理する体制を整えておくことが重要です。

このドキュメントは、Istio のセキュリティのベスト プラクティス ドキュメントを補完するものです。相互 TLS（mTLS）、認証ポリシー、ゲートウェイ、その他のセキュリティ構成に関する詳細な構成の推奨事項が含まれます。これらの推奨事項は、このドキュメントで説明するベスト プラクティスと併せて使用するために、基礎として扱います。このドキュメントでは、その他の Cloud Service Mesh のベスト プラクティスと、Google Cloud のテクノロジーがメッシュ内のすべてのレイヤ、コンポーネント、情報フローを保護する方法を説明します。

攻撃ベクトルとセキュリティ リスク

攻撃ベクトル

Cloud Service Mesh セキュリティはゼロトラスト セキュリティ モデルを採用しています。このモデルは、セキュリティ脅威が組織のセキュリティ境界の内側と外側の両方で発生することを前提としています。サービス メッシュ内のアプリケーションを脅かすセキュリティ攻撃の種類としては、次のようなものがあります。

• データの引き出し攻撃。サービス間のトラフィックから機密データや認証情報などを盗み出します。
• 中間者攻撃。たとえば、サービス間の通信や変更を行うために正当なサービスを偽装する悪意のあるサービス。
• 権限昇格攻撃。昇格された権限に不正にアクセスして、ネットワーク内で操作を行います。
• サービス拒否（DoS）攻撃。
• サービスに侵入し、ボットネットを利用して他のサービスへの攻撃を仕掛けます。

攻撃は、攻撃対象に基づいて分類することもできます。

• メッシュ内部ネットワーク攻撃。メッシュ内部サービス間またはサービスとコントロール プレーン間の通信の改ざん、盗聴、なりすましを目的とした攻撃。
• コントロール プレーンに対する攻撃。コントロール プレーンを誤動作させたり（DoS 攻撃など）、コントロール プレーンから機密データを盗み出そうとします。
• メッシュエッジに対する攻撃。メッシュの上り（内向き）または下り（外向き）で通信の改ざん、傍受、なりすましを試みます。
• メッシュ オペレーションに対する攻撃。メッシュ オペレーションを狙った攻撃。攻撃者は、メッシュ内で悪意のある操作（セキュリティ ポリシーとワークロード イメージの変更など）を実行するために、上位の権限を取得しようとします。

セキュリティ リスク

メッシュには、セキュリティ攻撃以外にもセキュリティ リスクがあります。セキュリティ リスクとしては、次のようなものがあります。

• 不完全なセキュリティ。サービス メッシュを保護するために、サービス メッシュに認証ポリシーと認可ポリシーが構成されていません。たとえば、メッシュ内のサービスに認証ポリシーや認可ポリシーが定義されていません。
• セキュリティ ポリシーの例外。特定のユースケースに対応するため、特定のトラフィック（内部または外部）に対するセキュリティ ポリシーの例外を作成して、Cloud Service Mesh のセキュリティ ポリシーから除外できます。このようなケースを安全に処理するには、このドキュメントのポリシーの例外を安全に処理するをご覧ください。
• イメージのアップグレードを実施しない。メッシュで使用されているイメージの脆弱性が発見される可能性があります。脆弱性に対する最新の修正を適用し、メッシュ コンポーネントとワークロード イメージを最新の状態に保つ必要があります。
• メンテナンスの欠如（専門知識やリソースがない）。最新のセキュリティ保護メカニズムを利用するには、メッシュ ソフトウェアとポリシー構成を定期的にメンテナンスする必要があります。
• 可視化の欠如。メッシュ ポリシーの誤った構成や安全でない構成、メッシュ トラフィックやオペレーションの異常が検出された場合に、メッシュ管理者に通知されていません。
• 構成のずれ。メッシュ内のポリシーの構成が、信頼できる情報源から逸脱しています、

サービス メッシュを保護する対策

このセクションでは、サービス メッシュを保護するための運用マニュアルについて説明します。

セキュリティ アーキテクチャ

サービス メッシュのセキュリティは、メッシュ システムとそのアプリケーションのさまざまなレイヤに存在するコンポーネントのセキュリティに依存します。Cloud Service Mesh のセキュリティ ポスチャーでは、異なるレイヤにある複数のセキュリティ メカニズムを統合してサービス メッシュを保護することを推奨しています。これにより、ゼロトラスト セキュリティ モデルでシステム全体のセキュリティを実現できます。次の図は、Cloud Service Mesh のセキュリティ ポスチャーの案を示しています。

Cloud Service Mesh は、次のような複数のレイヤでセキュリティを提供します。

• メッシュエッジのセキュリティ
  • Cloud Service Mesh の上り（内向き）セキュリティは、外部トラフィックのアクセス制御を行い、メッシュ内のサービスで公開される API への外部アクセスを保護します。
  • Cloud Service Mesh の下り（外向き）セキュリティは、内部ワークロードからの送信トラフィックを規制します。
  • Cloud Service Mesh のユーザー認証 は、Google インフラストラクチャと統合されており、ウェブブラウザからウェブ アプリケーションを実行するサービスへの外部呼び出しを認証します。
  • Cloud Service Mesh のゲートウェイ証明書管理は、Certificate Authority Service を使用して、Anthos Service Mesh の上り（内向き）ゲートウェイと下り（外向き）ゲートウェイで使用される秘密鍵と X.509 証明書を保護し、ローテーションします。
  • VPC と VPC Service Controls は、プライベート ネットワーク アクセス制御によってメッシュエッジを保護します。
• クラスタ セキュリティ
  • Cloud Service Mesh 相互 TLS（mTLS）は、ワークロード間のトラフィックに暗号化と認証を適用します。
  • Cloud Service Mesh 認証局は、ワークロードで使用される証明書を安全にプロビジョニングして管理します。
  • Cloud Service Mesh の認証機能では、ID とその他の属性に基づいてメッシュ サービスのアクセスを制御します。
  • GKE Enterprise セキュリティ ダッシュボードでは、ワークロードのセキュリティ ポリシーと Kubernetes NetworkPolicies の構成をモニタリングできます。
  • Kubernetes ネットワーク ポリシーでは、IP アドレス、Pod のラベル、名前空間などに基づいて Pod のアクセス制御が適用されます。
• ワークロード セキュリティ
  • Cloud Service Mesh のセキュリティ リリースを最新の状態にして、メッシュで実行されている Cloud Service Mesh バイナリに既知の脆弱性がないようにします。
  • Workload Identity Federation for GKE を使用すると、ワークロードで Google サービスを安全に呼び出すための認証情報を送信されます。
  • Cloud Key Management Service（Cloud KMS）は、ハードウェア セキュリティ モジュール（HSM）を介して機密データまたは認証情報を保護します。たとえば、ワークロードは Cloud KMS を使用して認証情報などの機密データを保存できます。CA Service（メッシュ ワークロードへの証明書の発行に使用）は、Cloud KMS によって管理される顧客ごとの署名鍵と HSM がサポートする署名鍵をサポートします。
  • Kubernetes Container Network Interface（CNI）は、特権付きの Cloud Service Mesh init コンテナの必要性を排除することにより、権限昇格攻撃を防ぎます。
• オペレーターのセキュリティ
  • Kubernetes ロールベースのアクセス制御（RBAC）は、Kubernetes リソースへのアクセスを制限し、オペレーターの権限を制限して、悪意のあるオペレーターやなりすましによる攻撃を回避します。
  • GKE Enterprise Policy Controller は、メッシュ内のポリシー構成を検証して監査し、構成ミスを防ぎます。
  • Google Cloud Binary Authorization は、メッシュ内のワークロード イメージが管理者によって承認されたイメージであることを確認します。
  • Cloud Audit Logs はメッシュ オペレーションを監査します。

次の図は、Cloud Service Mesh の統合セキュリティ ソリューションとの通信と構成のフローを示しています。

クラスタ セキュリティ

このセクションでは、クラスタ セキュリティに関連するベスト プラクティスについて説明します。

厳格な相互 TLS を有効にする

中間者攻撃（MitM）は、通信を盗聴または操作するために、互いに通信している 2 者間に悪意のあるエンティティを挿入します。Cloud Service Mesh では、すべての通信者に mTLS 認証と暗号化を適用することで、MitM 攻撃とデータの引き出し攻撃を防ぎます。両側が mTLS をサポートしている場合、Permissive モードで mTLS が使用されますが、mTLS を使用しない接続も許可されます。一方、厳密な mTLS の場合、トラフィックは mTLS で暗号化および認証される必要があり、暗号化されていないテキストのトラフィックは許可されません。

Cloud Service Mesh では、セキュリティとコンプライアンスの要件を満たすために、ワークロード間の TLS 接続の最小 TLS バージョンを構成できます。

詳細については、Cloud Service Mesh の例: mTLS | メッシュ全体の mTLS を適用するをご覧ください。

アクセス制御を有効にする

サービスや Pod を Cloud Service Mesh から除外する正当な理由がない限り、メッシュの内外にあるすべてのトラフィックに Cloud Service Mesh セキュリティ ポリシー（認証ポリシーや認可ポリシーなど）を適用することをおすすめします。一部のポートと IP アドレス範囲では、正当な理由で Cloud Service Mesh セキュリティ ポリシーをバイパスする場合があります。たとえば、Cloud Service Mesh で管理されていないサービスとネイティブ接続を確立する場合などです。このようなユースケースで Cloud Service Mesh を保護するには、Cloud Service Mesh ポリシーの例外を安全に処理するをご覧ください。

サービスへのアクセス制御は、サービスへの不正アクセスを防ぐために重要です。mTLS の適用でリクエストは暗号化されて認証されますが、サービスのアクセス制御を適用するために、メッシュでは引き続きCloud Service Mesh 認可ポリシーが必要になります。たとえば、認証済みのクライアントからの未承認のリクエストを拒否するなどです。

Cloud Service Mesh 認可ポリシーでは、アクセス制御を柔軟に構成し、サービスを不正アクセスから保護します。Cloud Service Mesh 認可ポリシーは、認証結果から得られた認証済み ID に基づいて適用されます。mTLS または JSON Web Token（JWT）ベースの認証は、Cloud Service Mesh 認可ポリシーの一部として使用できます。

Cloud Service Mesh の認証ポリシーを適用する

Cloud Service Mesh 認証ポリシーを検討する際は、次の点を考慮してください。

JSON Web Token（JWT）

mTLS 認証に加えて、メッシュ管理者は、JWT に基づいてリクエストを認証し、認可するようサービスに要求できます。Cloud Service Mesh は JWT プロバイダとして機能しませんが、構成済みの JSON Web Key Set（JWKS）エンドポイントに基づいて JWT を認証します。JWT 認証は、Ingress ゲートウェイ（外部トラフィック）や内部サービス（メッシュ内トラフィック）に適用できます。呼び出し側を表す認証情報として JWT を使用し、リクエストされたサービスが呼び出し側に代わって呼び出されていることを証明する必要がある場合は、JWT 認証と mTLS 認証を組み合わせることができます。JWT 認証を適用すると、有効な認証情報なしで、実際のエンドユーザーに代わりサービスへのアクセスを試みる攻撃を阻止します。

Cloud Service Mesh のユーザー認証

Cloud Service Mesh のユーザー認証は、ワークロードに対するブラウザベースのエンドユーザー認証とアクセス制御を統合したソリューションです。サービス メッシュを既存の ID プロバイダ（IdP）と統合し、標準のウェブベースの OpenID Connect（OIDC）ログインと同意フローを実装して、アクセス制御に Cloud Service Mesh 認可ポリシーを使用します。

認可ポリシーを適用する

Cloud Service Mesh 認可ポリシーは、以下のものを制御します。

• サービスへのアクセスを許可するユーザーまたは対象。
• アクセスできるリソース。
• 許可されたリソースに対して実行できるオペレーション。

認可ポリシーは、サービスが実行する実際の ID、トラフィックのアプリケーション レイヤ（レイヤ 7）のプロパティ（リクエスト ヘッダーなど）、ネットワーク層（レイヤ 3 およびレイヤ 4）のプロパティ（IP 範囲やポートなど）に基づいてアクセス制御を構成する汎用的な方法です。

サービスやデータへの不正アクセスから保護するため、認証結果から生成された認証済み ID に基づいて、Cloud Service Mesh 認可ポリシーを適用することをおすすめします。

デフォルトでは、サービスへのアクセスを許可することを認可ポリシーが明示的に定義されていない限り、サービスへのアクセスは拒否されます。アクセス リクエストを拒否する認可ポリシーの例については、認可ポリシーのベスト プラクティスをご覧ください。

認可ポリシーは、可能な限り信頼を制限することを目的としています。たとえば、サービスへのアクセスは、サービスによって公開された個々の URL パスに基づいて定義し、サービス A のみがサービス B のパス /admin にアクセスできるようにします。

認可ポリシーは Kubernetes ネットワーク ポリシーと組み合わせて使用できます。これは、ネットワーク層（レイヤ 3 とレイヤ 4）でのみ動作し、Kubernetes Pod と Kubernetes Namespace の IP アドレスとポートへのネットワーク アクセスを制御します。

注: Cloud Service Mesh は TCP 以外のトラフィック（UDP トラフィックなど）を処理しないため、これらのトラフィックは認可ポリシーで制御できません。メッシュ管理者は、Kubernetes ネットワーク ポリシーを使用して UDP トラフィックのポリシーを定義できます。たとえば、メッシュ サービスが UDP を使用しない場合、メッシュ管理者は Kubernetes ネットワーク ポリシーを定義して UDP トラフィックをブロックできます。

メッシュ サービスへのアクセスにトークン交換を適用する

トークンを盗み出し、そのトークンを悪用してメッシュ サービスにアクセスするトークン リプレイ攻撃から保護するには、メッシュエッジで、メッシュの外部から送信されたリクエストのトークンを有効期間の短いメッシュ内部のトークンと交換する必要があります。

メッシュ サービスによって認証と認可を行うため、メッシュの外部からメッシュ サービスにアクセスするために送信されたリクエストには JWT や Cookie などのトークンを含める必要があります。メッシュ外部からのトークンは長期間存続する可能性があります。トークン リプレイ攻撃から保護するには、メッシュ外部からのトークンを、メッシュの上り（内向き）で、スコープが限定され、有効期間の短いメッシュ内部のトークンと交換します。メッシュ サービスはメッシュ内部トークンを認証し、メッシュ内部トークンに基づいてアクセス リクエストを認可します。

Cloud Service Mesh では、Identity-Aware Proxy（IAP）との統合がサポートされています。これにより、Cloud Service Mesh で認証に使用される RequestContextToken（外部トークンから交換される有効期間の短いメッシュ内部トークン）が生成されます。トークン交換では、攻撃者はメッシュ内の盗まれたトークンを使用してサービスにアクセスできません。交換されたトークンのスコープと存続期間は限られているため、トークン リプレイ攻撃の可能性は大幅に低減されます。

注: IAP トークンの交換は、Cloud Service Mesh ユーザー認証とは異なり、トークン リプレイ攻撃から保護するために、有効期間が短い内部トークンと外部トークンを交換します。一方、Cloud Service Mesh ユーザー認証では、ウェブ アプリケーション サービスに対してウェブブラウザ ベースの外部呼び出しを使用します。

Cloud Service Mesh ポリシーの例外を安全に処理する

サービス メッシュに特別なユースケースがある場合があります。たとえば、書式なしテキストのトラフィックに特定のネットワーク ポートを公開する必要がある場合があります。特定の用途に対応するために、例外を作成して Cloud Service Mesh セキュリティ ポリシーから特定の内部トラフィックまたは外部トラフィックを除外すると、セキュリティ上の問題が生じる場合があります。

一部のポートと IP 範囲で、Cloud Service Mesh セキュリティ ポリシーをバイパスする正当な理由がある場合があります。annotations（excludeInboundPorts、excludeOutboundPorts、excludeOutboundIPRanges）を Pod に追加して、Envoy サイドカーによる処理からトラフィックを除外できます。トラフィックを除外するアノテーションだけでなく、サイドカー インジェクションを無効にしてアプリケーションをデプロイすることで、メッシュを完全にバイパスすることもできます。たとえば、ラベル sidecar.istio.io/inject="false" をアプリケーション Pod に追加することなどです。

Cloud Service Mesh のセキュリティ ポリシーをバイパスすると、システム全体のセキュリティに悪影響を及ぼします。たとえば、ネットワーク ポートのアノテーションによって Cloud Service Mesh mTLS と認証ポリシーがバイパスされると、ポート上のトラフィックに対するアクセス制御は行われず、傍受やトラフィックの改ざんが行われる可能性があります。さらに、Cloud Service Mesh ポリシーをバイパスすると、ネットワーク ポリシーなどのセキュリティ以外のポリシーにも影響します。

意図的かどうかにかかわらず、ポートまたは IP アドレスで Cloud Service Mesh セキュリティ ポリシーをバイパスする場合は、メッシュを保護し、セキュリティ例外、潜在的なセキュリティの抜け穴、全体的なセキュリティのステータスを監視するために、別のセキュリティ対策を実装することを強くおすすめします。このようなシナリオでメッシュを保護するには、次の方法があります。

• サイドカーをバイパスするトラフィックが、MitM 攻撃を防ぐためにネイティブに暗号化および認証されるようにします。
• Kubernetes ネットワーク ポリシーを適用して、ポリシーの例外でポートの接続を制限する（たとえば、ポリシーの例外で同じ Namespace にある別のサービスからのトラフィックのみを許可するようにポートを制限するなど）か、Cloud Service Mesh セキュリティ ポリシーが適用されたポートを経由するトラフィックのみを許可します。

Config Sync で GitOps アプローチを使用して構成のずれを防ぐ

構成のずれは、メッシュ内のポリシーの構成が信頼できる情報源から逸脱した場合に発生します。Config Sync を使用すると、構成のブレを防止できます。

Cloud Audit Logs とモニタリングを適用する

メッシュ管理者には、次の項目をモニタリングすることをおすすめします。

• Cloud Audit Logs
• Cloud Service Mesh の監査ロギング
• ポリシー制約の監査ロギング
• Anthos Config Sync
• アクセスログ
• サービスレベル指標
• Cloud Trace の使用

管理者は、これらのオブザーバビリティ リソースを使用して、セキュリティ構成が期待どおりに機能していることを確認し、セキュリティ ポリシーの適用の例外をモニタリングできます。たとえば、サイドカーを経由しないアクセスや、有効な認証情報のないサービスへのアクセスなどです。

Cloud Service Mesh では、オープンソースのオブザーバビリティ ソフトウェア（Prometheus など）を使用できますが、Google Cloud Observability を使用することを強くおすすめします。 Google Cloud の組み込みオブザーバビリティ ソリューションは、ロギング、指標の収集、モニタリング、アラートを提供します。これらはフルマネージドです。

ワークロード セキュリティ

ワークロード セキュリティは、ワークロードの Pod を侵害し、侵害された Pod を使用してクラスタに対する攻撃（ボットネット攻撃など）を開始する攻撃から保護します。

Pod の権限を制限する

Kubernetes Pod にノードまたはクラスタの他の Pod に影響する権限が付与されている場合があります。ワークロード Pod にセキュリティ制限を適用し、不正に使用された Pod がクラスタに対する攻撃を実行しないようにすることが重要です。

Pod のワークロードに最小権限の原則を適用するには:

• メッシュにデプロイされたサービスは、可能な限り少ない権限で実行する必要があります。
• init コンテナを使用して、サイドカーへの iptables トラフィックのリダイレクトを構成するように、Cloud Service Mesh を構成できます。これには、NET_ADMIN 機能と NET_RAW 機能を使用してコンテナをデプロイする権限があるワークロード デプロイを作成するユーザーが必要です。昇格した権限を持つコンテナが実行されないようにするため、メッシュ管理者は、Istio CNI プラグインを有効にして、サイドカーへのトラフィックのリダイレクトを構成できます。

コンテナ イメージを保護する

攻撃者は、脆弱なコンテナ イメージを利用して攻撃を仕掛けてきます。管理者は、Binary Authorization を適用してコンテナ イメージの整合性を検証し、信頼できるコンテナ イメージのみがメッシュにデプロイされるようにする必要があります。

メッシュの脆弱性を回避する

• Artifact Analysis は、GKE ワークロードの脆弱性をスキャンして発見できます。
• 共通脆弱性識別子（CVE）の処理。コンテナ イメージの脆弱性が発見されたら、メッシュ管理者はできるだけ早く脆弱性を修正する必要があります。Google がメッシュ イメージに影響する CVE のパッチを自動的に適用します。

Workload Identity Federation for GKE を使用して Google サービスに安全にアクセスする

Workload Identity Federation for GKE は、メッシュ ワークロードが Google サービスに安全にアクセスするためのおすすめの方法です。認証情報の漏えい、権限昇格、情報の開示、否認防止のリスクがあるため、Kubernetes Secret にサービス アカウント キーを保存し、サービス アカウント キーを使用して Google サービスにアクセスする方法以外は安全ではありません。

セキュリティ ダッシュボードとテレメトリーでセキュリティ ステータスをモニタリングする

サービス メッシュには、セキュリティ例外や潜在的な抜け穴がある可能性があります。適用されているセキュリティ ポリシー、セキュリティ例外、メッシュ内の潜在的なセキュリティの抜け穴などを検出するため、メッシュのセキュリティ ステータスを表示してモニタリングすることが重要です。GKE Enterprise セキュリティ ダッシュボードとテレメトリーを使用すると、メッシュのセキュリティ ステータスを表示し、モニタリングできます。

テレメトリーはメッシュ内のサービスの状態とパフォーマンスをモニタリングします。これにより、メッシュ管理者はサービスの動作（SLO、異常なトラフィック、サービス停止、トポロジなど）を監視できます。

GKE Enterprise セキュリティ ダッシュボードには、サービス メッシュのワークロードに適用されるセキュリティ ポリシーが表示されます。たとえば、アクセス制御ポリシー（Kubernetes ネットワーク ポリシー、Binary Authorization ポリシー、サービスへのアクセス制御ポリシー）や認証ポリシー（mTLS）などです。

機密性の高いユーザーデータと認証情報を保護するセキュリティ

機密性の高いユーザーデータや認証情報を Kubernetes Secret などのクラスタの永続ストレージに保存するか、Pod に直接保存すると、Pod からの攻撃や悪意のあるオペレーションに対してデータや認証情報が脆弱になる可能性があります。また、サービスへの認証のためにネットワーク経由でデータを転送する場合、ネットワーク攻撃に対しても脆弱になります。

• 可能であれば、機密性の高いユーザーデータと認証情報を Secret Manager や Cloud KMS などの保護されたストレージに保存します。
• 機密データにアクセスする Kubernetes Pod 用に別の Namespace を指定し、他の Namespace からアクセスできないように Kubernetes ポリシーを定義します。オペレーションに使用されるロールを分割化し、Namespace の境界を適用します。
• トークンの交換を適用して、有効期間が長く高い権限を持つトークンの漏えいを防ぎます。