はじめに
2020年11月の KubeCon + CloudNativeCon North America 2020 Virtual の Co-Located Events として Production Identity Day: SPIFFE + SPIRE というイベントが開催（スポンサーはメンテナーが多く在籍する HPE と VMWare）されました。セッションは SPIFFE と SPIRE を中心としたものになっていて、アイデンティティ・認証・ゼロトラストセキュリティに関心を持つ人向けの内容になっています。
業務で触れることが多いこともあり SPIFFE と SPIRE に関心があったので、このイベントにオンラインで参加できず非常に残念だったのですが、CNCF の YouTube チャンネルで Production Identity Day のセッション録画が公開されていたことを知ったので、今回はその録画で観た各セッションの概要と感想をまとめていきます。
Keynote: Introduction to SPIFFE
Kubernetes コミュニティで著名な Kelsey Hightower さんによるキーノートです。初心者の視点から SPIFFE と SPIRE の説明をしながら、ライブデモを通して独自のアプリケーションで SPIFFE を活用する方法を紹介する内容になっていました。せっかくなので、ライブデモの内容を具体的に紹介していきます。
まず前提として SPIFFE を利用してワークロード間で認証を行うには、要件に応じて X.509 証明書ベースの ID ドキュメントである X.509 SVID か、JWT ベースの ID ドキュメントである JWT SVID を使い分ける必要があります。基本的には X.509 SVID の利用が推奨されていますが、L7プロキシやロードバランサーなどによりワークロードの前段で TLS 終端がされてしまうようなケースでは JWT SVID を利用することになります。
このライブデモは Google Cloud の Cloud Run で SPIFFE を活用するという内容だったこともあり、認証方式としては JWT SVID を採用していました。JWT SVID の発行は独自のアプリケーションが担当しており、実装としては Google Cloud の IAM から発行されたアクセストークンを受け取り公開鍵で信頼性を検証した後に、内部で保持しているマッピング情報（サービスアカウントと JWT SVID にセットする aud と sub の対応を定義）を参照して JWT SVID を発行するというものになっていました。
サービスアカウントに対応した SPIFFE ID が含まれる JWT SVID が発行されたことを確認した後に、その JWT SVID を元に OPA で認可処理を実装する方法も紹介されていました。実装も興味深く面白いキーノートだと思いました。
SPIFFE Project Updates
SPIFFE プロジェクトの最新情報を紹介するセッションです。
はじめに、SPIFFE TSC の在り方についての話がありました。TSC は Technical Steering Committee の略で直訳すると技術運営委員会になります。TSC はプロジェクトの開始当初から存在している組織で、所属するメンバーはメンテナーと同じようにプロジェクトに関する最終的な権限を持っています。TSC は定期的にミーティングを開催しており、その中でプロジェクトの進捗状況の確認、メンテナーのニーズへの対応、プロジェクトにおける戦略的な方向性や業界の動向へのフィードバックなどを行っているようです。話の内容としては、TSC の現状を踏まえた上で、組織としてどう在るべきで、どう改善していくかというものでした。SPIFFE プロジェクトで TSC が存在していることを知らなかったのでとても勉強になりました。なお、このセッション時点では TSC という名称でしたが、現在は SPIFFE Steering Committee（SSC）という組織体に変更されました。変更の詳細は spiffe/spiffe#157 を参照してください。
次に新しい SIG の紹介がありました。1つ目が SPIFFE コミュニティの育成と成長に関心を持つグループとなる SIG-Community で、この SIG でイベントやウェビナーの開催、ブログ投稿、Twitter アカウント運営などを受け持つとのことでした。2つ目が SPIRE の開発にフォーカスするグループとなる SIG-SPIRE で、SPIRE に関する様々なことを話し合える SIG とのことでした。
次に SIG-Spec での進捗について情報共有があり、現在策定中の Federation 仕様が近い内に完成するとのことでした。Production Identity Day での報告通り、2021年3月上旬に SPIFFE に Federation 仕様を追加する PR（ spiffe/spiffe#155 ）が作成されていたので、マージされたタイミングで目を通してみようと思います。
最後に SIG-Spec で検討していることについての話がありました。JWT がリプレイアタックを受ける危険性を持っている（有効期限を短くすることでリスクは減らせる）ことや、JWT 発行において中央集権的な署名機関ではパフォーマンスに懸念があるという話をした上で、これらの課題を解決できる新たなセキュリティトークン（Token 2.0 と呼んでいた）に強い関心があるとのことでした。この話を聞いて Identity 界隈で話されている JWT の課題や代替案などを深く理解できていないことに気付いたので、空いた時間を見つけて勉強していこうと思いました。
SPIRE Project Updates
SPIRE プロジェクトの最新情報を紹介するセッションです。
はじめに、直近で実施された注目すべき成果の紹介がありました。長らく課題となっていた JWT SVID 問題の解決や、API のリファクタリングなど大きな改善が実施された印象でした。JWT SVID 問題については "SPIRE UpstreamAuthority plugin の登場と JWT SVID 問題の解決" で詳しく紹介されていますので、気になる方はそちらを参照するのが良いでしょう。
- SPIRE Server の API のリファクタリング
- ドキュメントとインテグレーションテストの拡充
- Nested SPIRE 構成での JWT SVID サポート
- Go ライブラリ v2 の開発
- Java ライブラリの改善
次に直近のリリースで実装された機能の紹介がありました。少し前のバージョンにはなりますが、Z Lab が開発した UpstreamAuthority "vault" プラグイン（ zlabjp/spire-vault-plugin ）が SPIRE のビルドインプラグインとしてマージされたのは非常に喜ばしいことでした。
- v0.11.1
- UpstreamAuthority "aws_pca" プラグインで Trust Bundle に任意の CA 証明書追加をサポート
- Node Attestation リクエストのレート制限の無効化をサポート
- v0.11.0
- SPIRE Server の API のリファクタリング
- WorkloadAttestor "unix" プラグインで Linux の補助グループのセレクターをサポート
- Kubernetes Workload Registrar で CRD モードと Reconcile モードをサポート
- v0.10.1
- UpstreamAuthority "vault" プラグインのサポート
- v0.10.0
- Nested SPIRE 構成での JWT SVID サポートと UpstreamAuthority プラグインの開発
- SPIRE Server の実装が改善されてデータベースの読み取り負荷が約 1/5 に軽減
- Registration Entry の変更に応じた SPIRE Agent の SVID キャッシュ機能の改善
次に SPIRE 開発において現在注力していることの紹介がありました。それぞれ RFC や Proposal な Issue が起票されているので、気になる機能があれば注視しておくと良いでしょう。
- SPIRE v1.0.0 に向けた作業
- リファクタリングの実施
- メンテナンスのガイドライン作成
- バージョニングとリリースサイクルの整理
- TPM を利用した Node Attestation（ spiffe/spire#1003 ）
- AWS KMS での SVID 署名鍵の管理（ spiffe/spire#1921 ）
- KeyManager "aws_kms" プラグインの開発が検討されている
- 署名が外部サービスに依存するのでタイムアウトやリトライなど障害時の動作を議論中とのこと
- KV ストアと SQL ストアの両方をデータストアとしてサポートするシンプルなプラグインの開発（ spiffe/spire#1945 ）
- サーバーレス環境のような SPIRE Agent がインストールできない環境での SPIRE 利用（ spiffe/spire#1843 ）
- サーバーレス環境のワークロードが SPIRE から発行された SVID を利用できる仕組みを検討中とのこと
- Key の強制失効と強制ローテーションを実行する機能（ spiffe/spire#1934 ）
- Key が漏洩した際に対策できる仕組みを検討中とのこと
- Certificate Transparency のサポート（ spiffe/spire#1858 ）
- CT（Certificate Transparency）は証明書発行の証跡を監査するための仕組み
- CT を利用することで X.509 SVID の誤発行や悪意がある発行のリスクを軽減できる
- 新しいプラグインを追加する方針で議論中とのこと
最後に SPIRE に実装が予定されている機能の紹介がありました。現在注力している作業と合わせると今後もたくさんの機能が追加されていくので、活用できそうな機能には注目しつつ、引き続き動向を追いかけていきたいと思いました。
- Break-glass モード（ spiffe/spire#1542 ）
- SPIRE Server の障害時にもワークロードに SVID の提供を続けるための仕組みを検討中とのこと
- ヘルスチェック機能の改善（ spiffe/spire#2047 ）
- 自分が spiffe/spire#1980 で聞いた話にはなりますが、SPIRE Server はプラグイン機構を通じて外部システムと統合しているので、現在の実装のように単純に自身の API にリクエストを投げてヘルスチェックを実施するのではなく、各プラグインを介して外部システムの状態を取得してヘルスチェックを実施する仕組みが実装されるのが理想とのこと
- エラーメッセージの改善
- セキュリティのベストプラクティスに準拠して Kubernetes 環境に SPIRE をデプロイする取り組み
- SPIRE core exposing service facilities to plugins and vice versa
- これは何のことを言っているか自分の知識では理解できませんでした...
- OIDC Federation を利用して SPIRE を GCP と Azure と統合できる仕組み
- AWS との統合は既にサポートされている
Community Integrations and other Works in Progress
SPIFFE/SPIRE コミュニティでの取り組みを紹介するセッションです。
ゲストスピーカーとして IBM、HPE、ByteDance、Arm の方々が招待されていました。
はじめに、IBM の方から Istio の Workload Identity 発行の仕組みを SPIRE に置き換える PoC の紹介がありました。PoC のモチベーションとして、Istio でサポートされている Namespace と Service Account に基づいた ID 発行ではなく、SPIRE を利用して様々な条件に基づいた ID 発行を実現することと、Istio 以外のプラットフォームで稼働するワークロードとの ID フェデレーションの実現が挙げられていました。発行する証明書に含まれる SPIFFE ID のフォーマットは Istio と同じ spiffe://<trust-domain>/ns/<namespace>/sa/<service-account> を採用して、SPIRE での ID 発行の際には Namespace と Service Account に加えてコンテナイメージの検証（将来的には Node の位置情報やハードウェア属性などの検証も想定しているとのこと）を取り入れており、ID 配布は istio-proxy 内で起動している istio-agent の UDS を SPIRE Agent の UDS に置き換えることで実現しているとのことでした。この話を聞いて Node と Workload の検証方法がプラグイン形式で拡張可能で、Selector で柔軟に検証項目を指定できるのは SPIRE の良さだなと改めて実感しました。こちらの事例は "Attesting Istio workload identities with SPIFFE and SPIRE" でも紹介されていますので、詳細が気になる方はそちらを参照するのが良いでしょう。
次に HPE の方から Transitive Identity を利用したユーザープライバシーの保護についての紹介がありました。ユーザ => フロントエンド => バックエンド というリクエストの流れがあり、バックエンドでアクセス制御（認証・認可）をしようとした場合に、直近の呼び出し元のフロントエンドの ID を元に認可判定をするのではなく、フロントエンドと間接的にやりとりしたユーザーの ID も利用して認可判定できるのか？という例を挙げていて、SPIFFE を利用して Transitive Identity ベースのアクセス制御を実現するべく "Delegated Principal Authentication with SPIFFE" という Design Doc を現在作成中とのことでした。完成したら PoC と SIG-Spec での議論が開始されるようで、既に SPIFFE Transitive Identity Working Group も立ち上がっているので興味ある方は是非参加してくださいとのことでした。Transitive Identity（Transitive = 推移的, 過渡的）という用語を耳にしたのが初めてで非常に興味深い話でした。後述のセッション "Fortifying Microservice Security with SPIRE and OPA" では Transitive Identity の PoC も紹介されているので、理解を深めたい人はそちらも併せて参照すると良いでしょう。
次に ByteDance の方から Certificate Transparency（CT）を利用した監査性の強化についての紹介がありました。スピーカーの方は SPIRE での CT のサポート（ spiffe/spire#1858 ） の Proposal を作成されていた方で、内容としては Proposal に記載した内容を図で説明するというものだったので、Proposal と併せて視聴すると全体像の理解が深まりそうだなと感じました。
最後に Arm の方から PARSEC での SPIFFE サポートについての紹介がありました。CNCF の Sandbox プロジェクトである PARSEC で SPIRE から発行された JWT SVID での認証をサポートしたという内容でした。PARSEC はセキュリティ関連の OSS のようなので、今後興味が出てきたら概要だけでも知っておきたいなと思いました。
SPIFFE and SPIRE Architecture Deep Dive
主要メンテナによる SPIFFE と SPIRE のアーキテクチャを掘り下げて紹介するセッションです。
SPIFFE で標準化されている仕様の説明から始まり、SPIRE の内部実装についての詳細な説明が続く内容になっていました。この内部実装の説明というのが非常にわかりやすく、SPIRE Agent が SPIRE Server と通信してどんな処理を実行しているのかであったり、Node Attestation や Workload Attestation 実行時の処理フロー、SPIRE Server での署名鍵の管理方法と上位の署名機関との連携方法などを図で丁寧に説明してくれているので、これから SPIRE を触っていきたいという人にとっては最高のセッションだなと思いました。
Securing Kafka with SPIFFE at TransferWise
TransferWise の方による SPIFFE で Kafka ブローカーとクライアントの通信をセキュアにしたという事例紹介のセッションです。
スピーカーが所属するチームが抱えていた課題として、Kafka ブローカーとマイクロサービスなクライアントを mTLS で通信させるための証明書の管理コストが高いことや、クライアントによっては TLS の機能が完全にサポートされていないことなどが紹介されていました。それらの課題を解決するために SPIRE を導入して、各マイクロサービスにサイドカーとして SPIRE Agent と連携した Envoy を配置して、Kafka ブローカーを Java SPIFFE Library で SPIRE Agent と統合させて、Kafka ブローカーとクライアント間の通信を SPIRE で発行された証明書ベースの mTLS にしたとのことでした。
SPIRE の導入により証明書の管理からは開放されますし、発行される証明書は短命でローテーションも自動実行なのでセキュアな状態を保てますし、なにより SPIFFE を利用した認証への移行で得られるメリットも多いので、非常に良い取り組みだと思いました。参考資料として transferwise/spiffe-kafka-talk と traiana/kafka-spiffe-principal が紹介されていたので興味があれば参照してみると良いでしょう。
“Solving the Bottom Turtle”: Writing a book on SPIFFE in 10 days using Book Sprints
Book Sprints を利用して10日間で作成した書籍 "Solving the Bottom Turtle" を紹介するセッションです。この書籍はメンテナーとコミュニティメンバーによって書かれたもので、内容を少しチェックしたところ SPIFFE/SPIRE の基礎的な部分から実践的な部分まで網羅的に書かれていて結構なボリュームがあり面白そうなので、時間ができたときにでも読んでみようと思いました。
Using SPIRE in Production at Uber
Uber での SPIRE の運用事例を紹介するセッションです。
規模感としては、約10個の独立したデータセンターそれぞれで10台未満の SPIRE Server が稼働しており、各データセンターで 20,000 から 40,000 台の SPIRE Agent ホストが稼働していて、SPIRE を利用しているサービス数は500程度（Uber が持つ内部サービスの10%未満）とのことでした。Stats 的なところだと1日で1データセンターあたり数千万の X.509 SVID への署名が実行されているそうです。
SPIRE Server に統合しているシステムの説明もありました。Registration Entry の管理はワークロードのオーケストレーターに任せていたり、SPIRE Agent の状況を確認してホスト停止や通常のライフサイクルでホストが不要になった際に対象 SPIRE Agent を Evict する仕組みを導入したりなど、様々な取り組みをしているようです。
また、ワークロード用の SVID 取得、リクエストへの SVID 付与、SVID を受け取った際の検証と認可ポリシーチェックなどの実装コストを下げる目的で、サービス開発者向けに SVID を利用してワークロード間で認証と認可を実施するためのライブラリを提供しているとのことでした。サイドカーパターンでの提供は検討中でまだ開発されてはいないようです。
SPIFFE at GitHub
GitHub での SPIFFE に関する取り組みを紹介するセッションです。
はじめに SPIFFE 導入に至ったモチベーションの紹介がありました。保有するデータセンターが増加していること、新製品のリリースなどでサービスが成長していること、近年の企業買収によってインフラ統合が行われていくことなど様々な要因により、インフラが複雑化していく中で認証の標準仕様を求めていたとのことでした。そういったモチベーションから SPIRE を導入してサービスに ID を自動配布して、Envoy などのサイドカーを介して SPIFFE をベースとしたサービス間の認証と認可を実施するアプローチを取っているとのことでした。
次に SPIRE Agent のセットアップに関する話がありました。Kubernetes で SPIRE Agent を稼働させていた際に DaemonSet の利用でいくつか課題が出てきたとのことでした。具体的には Workload API を利用する Pod と SPIRE Agent の Pod が上手いことスケジューリングされないことで、Pod 内のサービスが Workload API にアクセスできない状況が発生することが課題として挙げられていました。この課題を解決するために SPIRE Agent の管理を Systemd に委ねて Kubernetes のスケジューラーによる管理から分離したとのことでした。
次に Node Selector に関する話がありました。Node Selector の生成は NodeAttestor プラグインと NodeResolver プラグインの実装に依存しているため、標準プラグインを利用している場合、プラットフォーム毎に利用できる Node Selector に制限があります。話を聞いた感じだと、様々なプラットフォームを抱える GitHub では、どのようなプラットフォームでも共通の Node Selector を設けて SPIRE Agent をグルーピングしたいニーズがあったのではないかと思います。
次に Node Selector の具体的な実装の話に移りました。GitHub ではマシン毎に独自の証明書が配布されているようで、Kubernetes 環境でも Node Attestation ではその証明書を利用するように NodeAttestor "x509pop" プラグインを採用していて、更に独自の Node Selector を生成するために新規開発した NodeResolver "x509pop" プラグインも採用しているとのことでした。
ちなみに NodeResolver "x509pop" プラグインは証明書を SPIRE Server とは別の独自システムに投げて Node Selector を生成する仕様のようでした。なお、説明の際に例として Kubernetes 環境を挙げていましたが、他環境でも同様の構成（NodeAttestor "x509pop" プラグイン と NodeResolver "x509pop" プラグインの利用）を採用しているかは不明でした。
Passport App: The role of SPIFFE and SPIRE in a return to work solution
Doc.ai 社が提供している Passport という製品で SPIRE がどのように利用されているかを紹介するセッションです。ちなみに Passport は暗号セキュリティを利用して個人の健康状態を証明するアプリのようで、世界的なパンデミックを受けて生まれた製品なんだろうなあと思いました。
Doc.ai 社は、個人向けの健康管理アプリの提供と医療研究者向けにヘルスケアデータを提供する AI プラットフォームの開発を行っているシリコンバレーの企業のようで、セッション前半は個人のヘルスケアデータをどう守るかという観点でセキュリティの話がされていました。後半で Passport の話に移ったのですが、利用者のスマホからリクエストを受ける API と内部の DB で SPIRE を利用しているという簡潔な説明で具体的な運用方法などの説明はありませんでした。
Making Your First Contribution to SPIRE
SPIRE への初コントリビュートの流れを紹介するセッションです。「community/good first issue ラベルの Issue を拾うか、新たに Issue を作成した後に CONTRIBUTING.md に従って PR を作成してね。」という優しい内容でした。これからコントリビュートしていきたい方には良いセッションかと思います。
10 Lessons From Migrating to SPIFFE After 10 Years Of Service Identity at Square
Square が長年持っていた独自の ID システムを SPIFFE に移行して得られた10の教訓を紹介するセッションです。
はじめに Square での ID 管理の歴史の紹介がありました。サービス間の認証で mTLS を使用するために証明書が必要となり、当初は手動での運用だったそうですが、サービスの成長ですぐに限界を迎えて Keywhiz という秘密情報を管理するシステムが誕生したそうです。ちなみに現在は square/keywhiz で OSS として開発が進められています。
それからは社内 CA と連携させた Keywhiz の利用が続いてましたが、サービス成長に伴って社内で新たなクラウドサービスが採用された際に、その都度 Keywhiz の改修が必要となり拡張性に課題を抱えていたことや、ID システムとしての Keywhiz の再評価などがあり、SPIFFE/SPIRE の導入に至ったとのことでした。
次にどのように SPIRE への移行を実施したかの話があり、以下の対応を完了させた上で徐々に Keywhiz から SPIRE への移行を実施したとのことでした。
- SPIRE 環境の構築（当時は 0.6.x を稼働させていて多くの問題点や機能不足があったみたい）
- Registration Entry を自動登録する仕組みの開発
- サービスのサイドカーとして配置されている Envoy を SPIRE Agent と連携（この時点で Service Mesh は導入済）
- Keywhiz 仕様となっていた既存ライブラリでの SPIFFE サポート
ここまでの話を終えて SPIFFE に移行して得られた10の教訓の紹介がありました。情報量が多かったのでここでは割愛しますが、直面した課題をコミュニティに相談して解決していくことなど、学びがある内容ばかりだったので興味がある方は参照してみると良いでしょう。
Using a CRD to better integrate SPIRE and Kubernetes
F5 Networks の方による CRD を利用した Registration Entry（以下、エントリー）の管理方法を紹介するセッションです。
はじめに、同社が提供する NGINX Service Mesh（以下、NSW）で SPIRE がどのように利用されているかの紹介がありました。NSW ではサイドカーとして NGINX Plus（商用版 NGINX）が採用されていて、SPIRE はそれらのサイドカーに対して ID を発行する Control Plane として利用されているそうです。サイドカーへの ID 発行が主な利用用途ですが、他の Control Plane への ID 発行でも利用されているとのことでした。
次に Kubernetes Workload Registrar を導入して CRD でエントリーを管理することの利点についての話がありました。利点としては、kubectl でエントリーを制御できること（SPIRE Server の Pod へのアクセスが不要になる）、エントリーを YAML ファイルとして宣言的に定義できること、Reconciliation Loop によってエントリーを自動作成できること、Kubernetes を拡張するための標準的なアプローチであることなどを挙げていました。ちなみに Kubernetes Workload Registrar の CRD モードはスピーカーの方が spiffe/spire#1581 で実装した機能で SPIRE 0.11.0 から利用できるようになっています。
最後に今後の展望として Kubernetes Workload Registrar に実装予定の機能が話されていました。個人的な感想としては NGINX Service Mesh で SPIRE が利用されている間は Kubernetes Workload Registrar がどんどん改善されそうな雰囲気で、Kubernetes 環境で SPIRE を稼働させる際にエントリーの管理で困ることは無くなりそうな印象を受けました。
Fortifying Microservice Security with SPIRE and OPA
SPIRE と OPA を利用してマイクロサービス環境のセキュリティを強化する方法をデモで紹介するセッションです。
こちらのデモは、先述のセッション "Community Integrations and other Works in Progress" で話されていた Transitive Identity の PoC のようなものになっています。このデモがとても興味深く、SPIRE で JWT SVID を発行する際にユーザー認証で受け取ったトークン（Okta や Ping Identity などの IdP から発行された JWT トークン）を aud クレームに格納して ID を入れ子にするような方法が取られており、JWT SVID を受け取った OPA では SPIRE OIDC Discovery Provider を利用した JWT SVID 検証が完了した後に、aud クレームに含まれる IdP 発行のトークンを元にアクセス制御が実行されるといったものになっています。このようなアーキテクチャにすることで、通信元サービスと間接的にやりとりしたユーザーの ID もアクセス制御に活用できることが知れてとても学びになりました。
Using DevIDs and TPMs for Node Attestation
DevID と TPM を利用した Node Attestor プラグインを紹介するセッションです。
はじめに、2つの重要な業界標準についての説明がありました。1つ目が IEEE 802.1 WG が公開している “Standard for Local and Metropolitan Area Networks - Secure Device Identity” で、こちらの規格ではデバイスを識別するための DevID という概念が定義されています。DevID は、デバイスが特定のメーカーで製造されたものであることを証明する IDevID（"I" は Initial の意）と、デバイスが特定の企業または個人が所有していることを証明する LDevID（"L" は Local の意）の2種類から構成されています。2つ目が Trusted Computing Group（TCG）が公開している "TPM 2.0 Keys for Device Identity and Attestation" で、こちらの規格では TPM で DevID を扱う際の推奨事項などが定義されています。
次に、これらの業界標準に準拠して設計された NodeAttestor "tpm2" プラグインの紹介がありました。TPM 2.0 を利用して DevID（実体は証明書と秘密鍵）を生成する部分以外は、証明書と秘密鍵の所有を検証する NodeAttestor "sshpop" と NodeAttestor "x509pop" と似たようなものになっています。
最後に NodeAttestor "tpm2" プラグインのデモが実施されてセッションは終了となりました。このセッションで紹介されていたプラグインを SPIRE でサポートするために spiffe/spire#1003 で議論が進められているので、興味がある方はそちらを参照するのが良いでしょう。
Attestation and identity provisioning to Intel SGX workloads
Intel SGX と SPIRE を統合する方法を紹介するセッションです。
はじめに、Intel SGX についての説明がありました。Intel SGX はメモリー暗号化機能を備えた CPU の拡張機能（Azure や IBM Cloud などのクラウドプロバイダーでも利用可能）で、Intel SGX を利用するとユーザーレベルのコードを Enclave（エンクレーブ）と呼ばれる Hypervisor や OS から隔離されたメモリー内のプライベート領域で実行できるそうです。ちなみに Intel SGX 初心者の自分は TEE と Intel SGX 入門 を参考に理解を深めました。
次に、Intel SGX と SPIRE を統合するモチベーションなどの説明があり、最後に統合方法についての紹介がありました。アーキテクチャとしては、独自のヘルパープログラムを利用して SPIRE Server で発行した SVID を Intel SGX によって安全な領域に構築された SVID ストアに送信して、SGX ワークロードがそのストアから SVID を取得して利用するといったものでした。
このセッションで話されていた内容と関連して、SPIRE で機密性が高いワークロードへの SVID 発行をサポートする議論が spiffe/spire#1989 で進められているので、興味がある方はそちらを参照するのが良いでしょう。
さいごに
今回は、Production Identity Day: SPIFFE + SPIRE 2020 の各セッションの内容と感想をまとめました。SPIFFE/SPIRE の知見を深めていくためにも、コミュニティでの事例紹介は今後も継続してキャッチアップしていこうと思います。タイムリーなまとめではなくて恐縮ですが、日本語の SPIFFE/SPIRE 情報としてどなたかの参考になれば幸いです。