Anthos Service Mesh セキュリティのベスト プラクティス

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

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

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

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

はじめに

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

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

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

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

攻撃ベクトル

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

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

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

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

セキュリティ リスク

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

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

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

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

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

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

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

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

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

クラスタ セキュリティ

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

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

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

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

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

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

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

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

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

JSON Web Token（JWT）

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

Anthos Service Mesh のユーザー認証

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

認可ポリシーを適用する

Anthos Service Mesh 認可ポリシーは次のものを制御します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

サービス メッシュで強固なセキュリティ体制を形成するために、基盤となるサービスのセキュリティ メカニズムを、Anthos Service Mesh のセキュリティ ポリシーと一緒に適用する必要があります。

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

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

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

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

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

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

Namespace の境界を適用する

1 つの Namespace のユーザーが未承認の Namespace のリソースに対してアクセスまたは更新を実行できないようにするには:

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

Kubernetes RBAC ポリシーを適用する

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

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

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

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

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

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

• クラスタの上り（内向き）のセキュリティ ポリシーを適用します。クラスタが外部トラフィックを受信する必要がある場合、メッシュ管理者は、Anthos 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 ポリシーを使用すると、メッシュ管理者は承認済みのユーザーにのみリソースへのアクセスを許可できます。

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

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

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

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

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

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

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

Policy Controller の制約テンプレート ライブラリにある制約テンプレートのセットとすぐに使える Anthos Service Mesh のセキュリティ制約バンドルを使用して、認証、認可、トラフィック ポリシーなどの、Anthos Service Mesh のセキュリティに関するベスト プラクティスを実施できます。バンドルに含まれる制約の例を次に示します。

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

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

• Policy Controller のアドミッション Webhook の適用対象から Namespace を除外する。ただし、違反がある場合は、引き続き監査で報告されます。
• 制約 spec.enforcementAction を dryrun に設定する。アドミッション Webhook は変更を防止しませんが、違反は監査で報告されます。Security Command Center を使用して、セキュリティ チームに監査違反を通知できるようにする。
• 制約ロジックに除外ロジックを追加する（例）。

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

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

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

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

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

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

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

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

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

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

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

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

ワークロード セキュリティは、ワークロードの Pod を侵害した後、その Pod を利用してクラスタに仕掛けられる攻撃（ボットネット攻撃など）を防ぎます。

Pod の権限を制限する

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

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

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

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

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

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

• Container Analysis。Container Analysis は、GKE ワークロードの脆弱性をスキャンして発見できます。
• CVE（Common Vulnerability and Exposures）の処理。コンテナ イメージの脆弱性が発見されたら、メッシュ管理者はできるだけ早く脆弱性を修正する必要があります。マネージド データプレーンを使用するマネージド Anthos Service Mesh の場合、Google がメッシュ イメージに影響する CVE のパッチを自動的に適用します。

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

メッシュのワークロードが Google サービスに安全にアクセスする方法として推奨されるのは、Workload Identity です。認証情報の漏えい、権限昇格、情報の開示、否認防止のリスクがあるため、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 クラスタで Anthos Service Mesh の Egress ゲートウェイを使用するためのベスト プラクティスを確認する
• トランスポート セキュリティを構成する
• 認可ポリシーを更新する