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 ネットワーク ポリシーを適用する
    • コントロール プレーンへのアクセスを保護する
    • Namespace の境界を適用する
      • Kubernetes RBAC ポリシーを適用する
  • メッシュエッジのセキュリティ
    • クラスタの上り（内向き）アクセスの制御
    • クラスタの下り（外向き）トラフィックを統制する
    • 限定公開クラスタまたは VPC Service Controls を使用して外部アクセスを遮断する
    • 外部 DDoS 攻撃から防御する
  • メッシュの管理と自動化のセキュリティ
    • メッシュ オペレーションに使用されるロールを分割する
    • ポリシー構成を自動的に検証する
      • Config Sync で GitOps アプローチを使用して構成のブレを防ぐ
    • 監査ロギングとモニタリングを適用する
    • クラスタ内証明書で認証局を保護する
  • ワークロード セキュリティ
    • 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 User Auth は Google インフラストラクチャと統合されており、ウェブブラウザからウェブ アプリケーションを実行するサービスへの外部呼び出しを認証します。
  • Cloud Service Mesh のゲートウェイ証明書管理は、Certificate Authority Service を使用して、Anthos Service Mesh の上り（内向き）ゲートウェイと下り（外向き）ゲートウェイで使用される秘密鍵と X.509 証明書を保護し、ローテーションします。
  • Cloud Armor は、外部の分散型サービス拒否攻撃（DDoS）やレイヤ 7 の攻撃から保護できます。これは、ウェブ アプリケーション ファイアウォール（WAF）として機能し、ネットワーク攻撃からメッシュを保護します。たとえば、インジェクションやリモートコード実行などの攻撃を阻止します。
  • VPC と VPC Service Controls は、プライベート ネットワーク アクセス制御によってメッシュエッジを保護します。
• クラスタ セキュリティ
  • Cloud Service Mesh 相互 TLS（mTLS）は、ワークロード間のトラフィックに暗号化と認証を適用します。
  • Cloud Service Mesh 認証局や Certificate Authority Service などのマネージド CA は、ワークロードで使用される証明書を安全にプロビジョニングして管理します。
  • Cloud Service Mesh の認証機能では、ID とその他の属性に基づいてメッシュ サービスのアクセスを制御します。
  • GKE Enterprise セキュリティ ダッシュボードでは、ワークロードのセキュリティ ポリシーと Kubernetes ネットワーク ポリシーの構成をモニタリングできます。
  • Kubernetes ネットワーク ポリシーでは、IP アドレス、Pod のラベル、名前空間などに基づいて Pod のアクセス制御が適用されます。
  • コントロール プレーンのセキュリティにより、コントロール プレーンへの攻撃を阻止します。これにより、サービスとメッシュ構成データの不正な変更、悪用、流出を防ぐことができます。
• ワークロード セキュリティ
  • Cloud Service Mesh のセキュリティ リリースを最新の状態にして、メッシュで実行されている Cloud Service Mesh バイナリに既知の脆弱性がないようにします。
  • GKE 用 Workload Identity 連携を使用すると、ワークロードは Google サービスを安全に呼び出すための認証情報を取得できます。
  • Cloud Key Management Service（Cloud KMS）は、ハードウェア セキュリティ モジュール（HSM）を介して機密データまたは認証情報を保護します。たとえば、ワークロードは Cloud KMS を使用して認証情報などの機密データを保存できます。CA Service（メッシュ ワークロードへの証明書の発行に使用）は、Cloud KMS によって管理される顧客ごとの署名鍵と HSM がサポートする署名鍵をサポートします。
  • Kubernetes CNI（Container Network Interface）は、特権付きの Cloud Service Mesh init コンテナの必要性を排除することにより、権限昇格攻撃を防ぎます。
• オペレーターのセキュリティ
  • Kubernetes ロールベースのアクセス制御（RBAC）は、Kubernetes リソースへのアクセスを制限し、オペレーターの権限を制限して、悪意のあるオペレーターやなりすましによる攻撃を回避します。
  • GKE Enterprise Policy Controller は、メッシュ内のポリシー構成を検証して監査し、構成ミスを防ぎます。
  • Google Cloud Binary Authorization は、メッシュ内のワークロード イメージが管理者によって承認されたイメージであることを確認します。
  • Google Cloud Audit Logging はメッシュ オペレーションを監査します。

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

クラスタ セキュリティ

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

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

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

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

Cloud Service Mesh セキュリティ ポリシー（認証ポリシーや認可ポリシーなど）は、Anthos Service Mesh セキュリティ ポリシーからサービスまたは Pod を除外する正当な理由がない限り、メッシュを出入りするすべてのトラフィックに適用する必要があります。一部のポートと 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 の認証ポリシーを適用する

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 範囲やポートなど）に基づいてアクセス制御を構成する汎用的な方法です。

Cloud Service Mesh 認可ポリシーは、サービスまたはデータへの不正アクセスを防ぐために、認証結果から得られた認証済み ID に基づいて適用する必要があります。

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

認可ポリシーでは、信頼を可能な限り制限する必要があります。たとえば、サービスへのアクセスは、サービスによって公開された個々の 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 セキュリティ ポリシーをバイパスする場合があります。アノテーション（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 セキュリティ ポリシーが適用されたポートを経由するトラフィックのみを許可します。
• GKE Enterprise Policy Controller を適用して Cloud Service Mesh ポリシーを自動的に検証します。たとえば、ワークロードに Cloud Service Mesh サイドカーを常に挿入します。

Kubernetes ネットワーク ポリシーを適用する

Cloud Service Mesh は、基盤となるプラットフォーム（Kubernetes など）に基づいて構築されます。したがって、Cloud Service Mesh のセキュリティは、基盤となるプラットフォームのセキュリティに依存します。たとえば、Kubernetes リソースを更新できるユーザーを制御できない場合、サービスの Kubernetes Deployment が変更され、サービスのサイドカーがバイパスされる可能性があります。

サービス メッシュで強固なセキュリティ ポスチャーを形成するために、基盤となるプラットフォームのセキュリティ メカニズムを、Cloud Service Mesh のセキュリティ ポリシーと連動するように適用する必要があります。

Kubernetes ネットワーク ポリシーは、ネットワーク レイヤ（L3 と L4）で、Kubernetes Pod と Namespace の IP アドレスとポートに対して機能します。Kubernetes ネットワーク ポリシーを Cloud Service Mesh ポリシーと組み合わせて使用すると、メッシュのセキュリティを強化できます。

たとえば、メッシュ管理者は、Cloud Service Mesh セキュリティ ポリシーが適用されたポートを使用するトラフィックのみを許可するように Kubernetes ネットワーク ポリシーを構成できます。すべてのトラフィックを Cloud Service Mesh mTLS で適用する必要がある場合は、管理者が Cloud Service Mesh mTLS ポリシーで構成されたポート上のトラフィックのみを許可するよう Kubernetes ネットワーク ポリシーを構成できます。メッシュ管理者は、ポリシーの例外でポートの接続を制限するように Kubernetes ネットワーク ポリシーを構成することもできます。たとえば、名前空間内でこのようなポートの接続を制限します。

注: Kubernetes ネットワーク ポリシーの制限。Kubernetes ネットワーク ポリシーを使用すると、不要な接続を防ぎ、セキュリティ ポリシーがバイパスされるポートからの抜け穴を制限できますが、Cloud Service Mesh セキュリティ ポリシーに代わるものではありません。アプリケーション ID やその他のレイヤ 7 プロパティに基づくアクセス制御を提供していないためです。また、Pod と Namespace のセレクタは、単一のクラスタ内の Kubernetes ネットワーク ポリシーにのみ使用できます。Pod IP 範囲はマルチクラスタ メッシュで使用できますが、ポリシーの制御はきめ細かくないため、メンテナンスでエラーが発生しやすくなります。

コントロール プレーンへのアクセスを保護する

Cloud Service Mesh コントロール プレーンは、接続するすべてのクライアントを認証します。したがって、有効な認証情報（許可された CA によって発行された Kubernetes JWT または X.509 証明書）を持つ呼び出し元のみが Cloud Service Mesh コントロール プレーンへのアクセスを許可されます。TLS は、ワークロードと Cloud Service Mesh コントロール プレーン間の接続を暗号化します。

クラスタ内 Cloud Service Mesh の場合は、認証メカニズムに加えて Kubernetes ネットワーク ポリシーをデプロイすることで、データプレーンからコントロール プレーンへのアクセスを許可しながら、Cloud Service Mesh システムの Namespace（デフォルトでは istio-system）をメッシュ外部の非マネージド Namespace とクライアントから分離できます。VPC ファイアウォール ルールにより、クラスタ外のトラフィックが Istiod に到達しないようにできます。このようなネットワーク分離対策を使用すると、メッシュ外部の攻撃者は、有効な認証情報を持っていてもコントロール プレーンにアクセスできなくなります。Google 管理のコントロール プレーンの場合、Google がコントロール プレーンのセキュリティを処理するため、コントロール プレーンに対するネットワーク分離ポリシーは必要ありません。

Namespace の境界を適用する

1 つの名前空間のユーザーの未承認の名前空間のリソースへのアクセスや更新を防止するには:

• アクセス制御を適用する。
• Kubernetes ネットワーク ポリシーを適用する。 名前空間内のサービスに名前空間外のトラフィックがない場合、メッシュ管理者は、その名前空間内のトラフィックのみを許可する Kubernetes ネットワーク ポリシー（名前空間からの上り（内向き）トラフィックまたは下り（外向き）トラフィックなし）をデプロイする必要があります。
• Kubernetes RBAC ポリシーを適用する。
  • アプリケーション管理者のロールは Namespace にバインドする必要があります。
  • メッシュ管理者にのみ ClusterRole を付与します。

Kubernetes RBAC ポリシーを適用する

メッシュ管理者は Kubernetes RBAC ポリシーを適用して、Kubernetes リソースにアクセスして更新できるユーザーを制御できます。Kubernetes のアクセス制御により、メッシュ内のセキュリティ リスクを軽減できます。たとえば、未承認のユーザーに Kubernetes Deployment の変更を許可せず、Cloud Service Mesh ポリシーの適用のバイパスを防ぐ必要があります。ユーザーのロールは Namespace にバインドして、必要以上に多くの Namespace にアクセスできないようにします。RBAC の構成に関する詳細なガイドと例については、ロールベースのアクセス制御の構成をご覧ください。Workload Identity Federation for GKE を有効にしたら、Kubernetes サービス アカウントを IAM サービス アカウントとして機能させることもできます。

メッシュエッジのセキュリティ

ほとんどの攻撃はクラスタ外部から発生する可能性があるため、メッシュエッジでのセキュリティは非常に重要です。

クラスタの上り（内向き）アクセスの制御

Cloud Service Mesh は、Ingress ゲートウェイを介して外部トラフィックを受信します。Ingress ゲートウェイによって公開されるサービスは、外部ソースから攻撃を受ける可能性があります。セキュリティ管理者は、Ingress ゲートウェイ経由の外部トラフィックに公開されているサービスが攻撃から保護されるように、セキュリティを維持する必要があります。

Ingress では、外部の呼び出し元に公開されているサービスの認証と認可を行う必要があります。

• クラスタの上り（内向き）のセキュリティ ポリシーを適用します。クラスタが外部トラフィックを受信する必要がある場合、メッシュ管理者は、Cloud Service Mesh のゲートウェイ TLS、認証、認可ポリシーなどの上り（内向き）セキュリティ ポリシーを適用して外部リクエストを認証し、外部リクエストが Ingress ゲートウェイによって公開されたサービスにアクセスする権限を持っていることを確認する必要があります。上り（内向き）セキュリティ ポリシーを適用することで、メッシュの外部から有効な認証情報や権限なしでサービスにアクセスしようとする攻撃を阻止できます。
• Cloud Armor をウェブ アプリケーション ファイアウォール（WAF）として使用して、ウェブベースの攻撃（インジェクション攻撃やリモート実行攻撃など）を防ぎます。詳細については、エッジからメッシュへ: GKE Ingress を介したサービス メッシュ アプリケーションの公開をご覧ください。

クラスタの下り（外向き）トラフィックを統制する

クラスタの下り（外向き）セキュリティは非常に重要です。下り（外向き）セキュリティ ポリシーは、データの引き出し攻撃を防ぎ、下り（外向き）トラフィックのフィルタリングと下り（外向き）トラフィックの TLS 発信を行います。セキュリティ管理者は、クラスタの下り（外向き）トラフィックを規制し、監査する必要があります。

メッシュ管理者は、VPC ファイアウォールを使用して下り（外向き）トラフィックを制限するだけでなく、クラスタに対して下り（外向き）セキュリティ ポリシーを適用し、下り（外向き）ゲートウェイを通過するように送信トラフィックを構成する必要があります。

下り（外向き）ポリシーは、次の攻撃を軽減できます。

• データの引き出し攻撃。
• CVE のパッチが適用されていない場合、攻撃者が Service Pod を悪用する可能性があります。Pod が侵害されると、ボットネットに組み込まれ、スパムの送信や DoS 攻撃に利用される可能性があります。

Egress ゲートウェイに適用される認可ポリシーにより、承認済みサービスにのみ、メッシュ外の特定のホストへのトラフィック送信を許可します。一方、メッシュから送信されるトラフィックに対しては、個々のサイドカーで TLS 発信を処理するのではなく、Egress ゲートウェイで TLS 発信を行います。これにより、アプリケーションが実行される Namespace から mTLS のクライアント証明書を分離できるため、統一されたより安全な方法で TLS トラフィックを発信できます。

限定公開クラスタまたは VPC Service Controls を使用して外部アクセスを遮断する

上り（内向き）と下り（外向き）のセキュリティ ポリシーを適用するだけでなく、可能な限り限定公開クラスタまたは VPC Service Controls を使用して外部アクセスを遮断します。セキュリティ ポリシーはメッシュ セキュリティ管理者が管理しますが、限定公開クラスタのセキュリティ構成または VPC Service Controls は組織のセキュリティ管理者によって適用されます。

VPC Service Controls を適用すると、以下の目的のためにサービスにセキュリティ境界を定義できます。

• サービスでの外部リソースへのアクセスを制限する。
• セキュリティ境界内のサービスへの外部からのアクセスを制限する。

VPC Service Controls は、データの引き出し攻撃を防ぎ、外部の攻撃者がメッシュ内のサービスにアクセスするのを防ぎます。

外部 DDoS 攻撃から防御する

外部から DDoS 攻撃を受けると、上り（内向き）ゲートウェイとバックエンド サービスが過負荷状態になり、正当なリクエストを処理できなくなります。Cloud Armor を使用すると、DDoS 攻撃を防ぐことができます。Cloud Armor は、ネットワーク レイヤ（L3 と L4）だけでなく、アプリケーション レイヤ（L7）でも DDoS 攻撃を阻止します。

メッシュの管理と自動化のセキュリティ

管理作業や、メッシュを中心に構築する自動化（CI / CD など）でもセキュリティは重要です。以下のプラクティスは、サービスをさらなる攻撃にさらすことなく、メッシュを安全に運用することを目的としています。

メッシュ オペレーションに使用されるロールを分割する

ロールベースのアクセス制御と同じ原則に従って、メッシュユーザーをロールに従って分類する必要があります。各ロールには、そのロールで必要な最小限の権限セットのみを付与します。

たとえば、サービスのデプロイを行うユーザーには、認証ポリシーと認可ポリシーを更新する権限を付与しません。

オペレーターにはさまざまなカテゴリがあります。たとえば、クラスタ オペレーターや Namespace オペレーターなどです。オペレーターの権限昇格が行われるとリソースへの不正アクセスが発生する可能性があるため、この権限昇格を防ぐことは重要です。

Kubernetes RBAC ポリシーを使用すると、メッシュ管理者は承認済みのユーザーにのみリソースへのアクセスを許可できます。

ポリシー構成を自動的に検証する

オペレーターが Cloud Service Mesh ポリシーの構成を間違うこともあります。この構成ミスで重大なセキュリティ インシデントが発生する可能性があります。構成ミスを防ぎ、Cloud Service Mesh ポリシーを自動的に検証するため、メッシュ管理者は Policy Controller を使用してポリシー構成に制約を適用できます。

Cloud Service Mesh セキュリティ ポリシーの更新権限を過剰に付与せず、Cloud Service Mesh ポリシーの検証を自動化するため、メッシュ管理者は Policy Controller を使用して Cloud Service Mesh ポリシーの制約を実装する必要があります。

Policy Controller は、オープンソースの Gatekeeper プロジェクトに基づいており、無効なリソースの適用を拒否するために Kubernetes アドミッション コントローラとして実行するか、管理者が監査モードで実行して、管理者に違反が警告されるようにすることができます。Policy Controller は、メッシュ内のリソースのデプロイを自動的に検証します。たとえば、デプロイのアノテーションが Cloud Service Mesh ポリシーをバイパスしないことや、Cloud Service Mesh ポリシーが期待どおり機能することを検証します。また、Deployment に root 権限（NET_ADMIN や NET_RAW など）が含まれていないことも検証します。

Policy Controller は、既存の Cloud Service Mesh リソースを制約と照合して、ポリシーの構成ミスを検出することもできます。

セキュリティ ポリシーを適用する GKE Enterprise Policy Controller の例を以下に示します。

• Pod による特権付きコンテナの実行を防ぎます。
• 特定のリポジトリのイメージのみを許可する。これにより、不正なコンテナ イメージの実行を防ぐことができます。
• Istio DestinationRules 内のすべてのホストとホスト サブセットに対する TLS の無効化を禁止する。
• Istio AuthorizationPolicy ルールのプリンシパルと名前空間が、指定されたリストの接頭辞を持つことを禁止する。
• ワークロードを外部 IP に公開する既知のリソースの作成を禁止する。
• Ingress リソースは HTTPS のみにすることを要求する。
• コンテナに読み取り専用のルート ファイル システムを要求する。

Policy Controller で提供される制約テンプレート ライブラリには、すぐに使える Cloud Service Mesh のセキュリティ制約バンドルで使用できる制約テンプレートのセットが含まれており、認証、認可、トラフィック ポリシーなどの、Cloud Service Mesh の特定のセキュリティに関するベスト プラクティスを実現できます。バンドルに含まれる制約の例を次に示します。

• メッシュレベルの厳格な mTLS PeerAuthentication を適用する。
• すべての PeerAuthentication が厳格な mTLS を上書きできないようにする。
• メッシュレベルのデフォルトの拒否 AuthorizationPolicy を適用する。
• AuthorizationPolicy 安全なパターンを適用する。
• Cloud Service Mesh サイドカーが常にワークロードに挿入されるようにする。

例外とブレークグラス状態を処理するため、メッシュ管理者は次のことを行えます。

• Policy Controller のアドミッション Webhook の適用対象から Namespace を除外する。ただし、違反がある場合は、引き続き監査で報告されます。
• 制約 spec.enforcementAction を dryrun に設定する。アドミッション Webhook は変更を防止しませんが、違反は監査で報告されます。
• 制約ロジックに除外ロジックを追加する（例）。

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

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

監査ロギングとモニタリングを適用する

メッシュ管理者は次のモニタリングを行う必要があります。

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

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

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

クラスタ内証明書で認証局を保護する

デフォルトでは、Cloud Service Mesh は Cloud Service Mesh 認証局という Google マネージド認証局（CA）を使用します。

Istiod の一部としてホストされる非マネージド Istio 認証局（CA）を使用している場合、CA 署名鍵は Kubernetes Secret に保存され、istio-system Namespace の Secret リソースにアクセスできるオペレーターはこの署名鍵にアクセスできます。オペレーターが Istiod の CA とは別の CA キーを使用し、ワークロード証明書に署名できるため、これは危険な状態です。また、運用上のエラーにより、セルフマネージド CA 署名鍵が誤って漏えいするリスクもあります。

CA 署名鍵を保護するため、メッシュ管理者は Mesh CA または Certificate Authority Service（CA サービス）を使用するようにメッシュをアップグレードできます。これらは、Google によって保護されて管理されています（CA 鍵のローテーションなど）。Mesh CA と比較すると、CA Service は Cloud HSM を基盤とする Cloud KMS を通じて、顧客ごとの HSM 基盤署名鍵をサポートしています。

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

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

Pod の権限を制限する

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

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

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

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

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

メッシュの脆弱性を軽減する

• Container Analysis。Container Analysis は、GKE ワークロードの脆弱性をスキャンして発見できます。
• CVE（Common Vulnerability and Exposures）の処理。コンテナ イメージの脆弱性が発見されたら、メッシュ管理者はできるだけ早く脆弱性を修正する必要があります。Google 管理のデータプレーンを使用する Google 管理の Cloud Service Mesh の場合、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 の境界を適用します。
• トークンの交換を適用して、有効期間が長い高い権限を持つトークンの漏えいを防止します。

次のステップ

• GKE クラスタで Cloud Service Mesh の Egress ゲートウェイを使用するためのベスト プラクティスを確認する
• トランスポート セキュリティを構成する
• 認可ポリシーを更新する