CLOUD SECURITY LAB

マイクロサービスに「身分証明書」が必要？IstioがSPIFFEを選んだ本当の理由 🕵️‍♂️

—

by

cslab
in

こんにちは！皆さんのMSAの旅をサポートするブログです。今日は、Kubernetes環境でマイクロサービスを運用する際に一度は直面したであろう「信頼」の問題について深く掘り下げていきたいと思います。

数多くのサービスが目まぐるしく行き交うクラスターの中で、サービスAはサービスBをどのように信頼して通信できるのでしょうか？まるで映画のスパイのように、お互いの正体を確認する必要がある状況ですね。🕵️‍♀️

この複雑な身元確認問題をIstioはどのように解決しているのでしょうか？その秘密の鍵は、まさにSPIFFEにあります。

🤔 既存方式の問題点：「IPアドレス、信用できない！」

以前は、サーバーのIPアドレスに基づいてファイアウォールルールを設定し、お互いを識別していました。「10.0.1.10からのリクエストは『決済サービス』だろう。許可しよう！」といった方式でしたね。

しかし、コンテナとKubernetesの時代では、このような方式はもはや通用しません。

  • 動的なIPアドレス 🌊： ポッド(Pod)はいつでも死んで再起動できます。そのたびにIPアドレスが変わります。IPアドレスはもはや固定された身元にはなり得ません。
  • セキュリティの脆弱性 🔓： 同じノード(Node)にデプロイされたポッド同士は、お互いをどのように信頼できるでしょうか？IPアドレスだけでは、本物の「決済サービス」なのか、それとも「決済サービス」を詐称する悪意のあるポッドなのかを区別するのは困難です。

結局、私たちは「どこから来たのか(where)」ではなく、「誰なのか(who)」に集中する必要があります。まさにワークロードアイデンティティ(Workload Identity)の概念が登場する瞬間です。

✨ 救世主登場：すべてのためのセキュアなプロダクションアイデンティティフレームワーク、SPIFFE

SPIFFE(Secure Production Identity Framework for Everyone)は、その名の通り、すべてのワークロードに安全で標準化された身元を付与するための「フレームワーク」であり「標準規格」です。特定のソフトウェアではなく、「ワークロードの身分証明書はこのような形式であるべきで、このように発行し、検証すべきである」という約束ですね。📜

IstioはこのSPIFFE標準を採用し、サービスメッシュ内のすべてのワークロードに固有の身元を付与します。

SPIFFEの主要構成要素 ✌️

  1. SPIFFE ID: ワークロードの固有の身分証明書番号です。URI形式で表現され、次のような構造を持ちます。
  • trust-domain: 信頼できるドメイン、つまりセキュリティ境界を意味します。通常、Kubernetesクラスター一つを意味します。(例: cluster.local)
  • workload-identifier: そのドメイン内でワークロードを一意に識別するパスです。(例: /ns/default/sa/my-app-sa)これらを合わせるとこのようになります。このIDは、世界中のどこからでもcluster.localというクラスターのdefaultネームスペースにあるmy-app-saサービスアカウントを使用するワークロードを指すことになります。
  • spiffe://cluster.local/ns/default/sa/my-app-sa
  • spiffe:////
  1. SVID (SPIFFE Verifiable Identity Document): SPIFFE IDを証明する「実物の身分証明書」です。この文書には、ワークロードのSPIFFE IDと有効期限などの情報が暗号化され、署名されています。誰かが「あなたのSPIFFE IDはspiffe://…で合っていますか？」と尋ねたら、SVIDを見せて証明するわけです。📄
  • SVIDは2つの形式で発行できます。
  • X.509-SVID: 私たちがよく知るSSL/TLS証明書の形式です。サービス間のmTLS(相互TLS)通信に主に使用されます。
  • JWT-SVID: JWT(JSON Web Token)トークンの形式です。アプリケーションレベルでのユーザー認証などに活用できます。

⚙️ IstioはSPIFFEをどのように実装するのか？(全体プロセスを覗き見)

では、IstioはこのSPIFFE標準をどのように実際に実装し、ワークロードに身分証明書(SVID)を発行するのでしょうか？

  1. ポッド生成 & サイドカー注入 🚀： 新しいポッドが生成されると、Istioのサイドカープロキシ(Envoy)が一緒に注入されます。
  2. 身元証明リクエスト 🙋： サイドカープロキシはIstioのコントロールプレーンであるistiodに「私に身分証明書を発行してください！」とリクエストします。このとき、自身の身元を証明するためにKubernetesサービスアカウント(Service Account)トークンなどの情報を一緒に送ります。
  3. 身元確認およびSVID発行 🧐： istiodはCA(Certificate Authority)の役割を果たします。リクエストを送ったプロキシのサービスアカウントトークンを検証し、それに基づいてSPIFFE IDを生成します。(spiffe://cluster.local/ns/prod/sa/payment-service)
  4. SVID伝達およびmTLS通信 🤝： istiodは生成されたSPIFFE IDが格納されたX.509-SVID(証明書)をサイドカープロキシに伝達します。これでこのプロキシは自身の「身分証明書」を持つことになります。他のサービスと通信する際、お互いにこのSVIDを交換して身元を確認し、安全なmTLS通信チャネルを確立します。

このすべてのプロセスは開発者の介入なしに自動的に行われます。これこそがサービスメッシュの強力さです！💪

❌ 他の方法はなぜ正解ではないのか？

SPIFFE以外の方法も考えられます。しかし、なぜIstioはそれらを選ばなかったのでしょうか？

  • 単純なJWTトークンの使用 🔑：
  • なぜ違うのか？ JWTは優れた認証方式ですが、それ自体は標準化された身元体系ではありません。どのような情報を格納するか、誰が発行し、どのように検証するかについての統一された規約がなければ、システムごとにバラバラに実装され、互換性と拡張性が低下します。SPIFFEはこれらすべてを標準として定義します。
  • クラウドプロバイダーのIAM (Identity and Access Management) ☁️：
  • なぜ違うのか？ AWS IAM、Google Cloud IAMなどは特定のクラウドプラットフォームに依存しています。マルチクラウドやハイブリッドクラウド環境では、ワークロードの身元を一貫して管理するのが困難です。SPIFFEはプラットフォームに中立的な標準を提供し、どのような環境でも同じ方法で身元を管理できるようにします。
  • OAuth 2.0 🛡️：
  • なぜ違うのか？ OAuth 2.0は主にユーザーの「権限」を委任(delegation)することに焦点が当てられたフレームワークです。「ユーザーに代わってこのアプリがGoogleフォトにアクセスすることを許可しますか？」といったシナリオに適しています。ワークロード自体が誰であるかを証明する「身元(Identity)」の問題とは焦点が異なります。

結論として、SPIFFEはプラットフォームに中立的でありながら、ワークロードの「身元」に焦点を当てた強力で標準化されたフレームワークであるため、Istioの哲学と完全に合致するのです。

これで、皆さんのマイクロサービスは、IPアドレスという不安定な住所ではなく、SPIFFEという偽造不可能な身分証明書を通じて、お互いを信頼し、安全にコミュニケーションできるようになりました。😊

Comments

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です