実践：マイクロサービス認可基盤

Transcript

1. 1 実践：マイクロサービス認可基盤 @nerocrux
2. 2 自己紹介 • 2018年6月にメルペイに入社 • ID Platform Team • 趣味はマラソンと認証認可関連のRFCを読むこと ◦ 最近は GNAP と ACE WG • 犬派 🐶 于 沛超 ウ ハイチョウ | @nerocrux
3. 3 Introduction Agenda Architecture Challenges Closing 02 03 04 01
4. 4 01 Introduction
5. 5 メルカリ
 •サービス開始日：2013年7月
 •対応OS：Android、iOS ※Webブラウザからも利用可能 
 •利用料：無料
 ※売れたときの手数料：販売価格の 10% •対応地域・言語：日本・日本語基本仕様
 •累計出品数：15億品を突破
 
 それを必要とする人の手に渡り、使用されることに喜びを感じ、ま た購入者は、多彩かつユニークな商品の中から「宝探し」感覚で 掘り出し物を見つける買い物体験を楽しんでいます。さらに「メル カリ」では、物の売買だけではなく、出品者・購入者間のチャットや 「いいね！」機能を通じて、お客さま間のコミュニケーションも活発 に行われています。 
 フリマアプリ「メルカリ」は、個人が簡単に中古品の売買を行える CtoCマーケットプレイスです。出品者・購入者双方が、安全・安心 な取引を楽しんでいただけるサービスを目指し、「メルカリ」が一時 的に購入代金を預かるエスクロー決済を活用した取引環境の整 備や、簡単かつ手頃な価格の配送オプション、差別化されたユ ニークなお客さま体験を提供しています。多くの出品者は、自分に とって必要でなくなったモノが、 
 5
6. 6 メルペイ
 日本最大のフリマアプリを提供する株式会社メルカリのグループ会社で ある、株式会社メルペイが運営するスマホ決済サービス。 
 使わなくなったものをメルカリで売って得た売 上 金や、銀 行 口 座から チャージしたお金、また「メルペイスマート払い」を利用して、「メルカリ」や 全国174万か所のメルペイ加盟店でのお支払いに利用可能。今後は新し い「信用」を軸にしたサービス展開予定。 
 
 
 

7. 7 メルカリ・メルペイ
 メルカリJP MAU¹
 1802万人
 メルペイ 利用者数1 
 850万人
 出典：会社資料。JP版メルカリ事業の通期決算概況（FY2021.6 2Q）より。
 1. メルペイ「電子マネー」の登録を行ったユーザと、「メルペイコード決済」、「ネット決済」、
 「メルペイスマート払い」等の利用者の合計（重複を除く）2020年10月5日時点。

8. 8 ID Platform Team @kung
 @nerocrux
 @kokukuma
 @eric
 @g-varona
 @utkarsh
 @gia.nguyen
 @robert
 @nikku

9. 9 Introduction 2013年 • メルカリサービス開始 ◦ モノリシックなPHP ◦ クライアント/用途に合わせて、認証認可の仕組みを自前で実装 2017年 • メルペイ設立 ◦ サービス計画段階からマイクロサービス採用 (Golang, GCP/GKE) ▪ メルカリもその後、マイクロサービスへシフト（継続中） ◦ サービスはメルカリ本体と密結合
10. 10 Introduction 2018年 • ID Platform Team 設立 @メルペイ ◦ マイクロサービス基盤のための認可の仕組み を実装 & 運用 ◦ OpenID Connect のサーバを実装 & 運用 ◦ 既存の認証認可基盤（モノリシック）のオーナーになり、運用改善
11. 11 02 Architecture
12. 12 Architecture マイクロサービスアーキテクチャ
13. 13 Architecture マイクロサービスアーキテクチャ (1) 外部からのリクエストに含まれるトークンが色々 i.e. 独自仕様のもの、OIDC Token、Google ID Token, etc... - Issuer が異なる - モノリシックPHP、OIDC、Google... - Spec も異なる - JWT / Opaque - 異なる Claims
14. 14 Architecture マイクロサービスアーキテクチャ (2) API Gateway の後ろにあるサービス - gRPC で通信する - 大量に存在する（増え続ける） - 依存関係
15. 15 03 Challenges
16. 16 Challenges マイクロサービスアーキテクチャにおける認可 ちゃれんじ マイクロサービス基盤内の各サービスが正しく認可を行えること • Gateway • 各 Service
17. 17 Challenges 1. Gateway での認可 クライアントからのリクエスト（に含まれるクレデンシャル）が、 リクエスト先のドメイン・エンドポイントにアクセスする権限あるか。
18. 18 Challenges 1. Gateway での認可 Authority というサービスが司る。
19. 19 Challenges 1. Gateway での認可 認可ルール 例 - Mercari App 向けに発行されたトークンが ドメイン 〇〇 の Endpoint にアクセスできる - Scope 〇〇 が含まれたトークンが Endpoint X にアクセスできる
20. 20 Challenges 1. Gateway での認可 認可ルール 定義場所 - Authority / Gateway 構成要素 - トークンの種類 - トークンのクレーム（audience, scope） 制限粒度 - 現状は ドメイン 単位 - 将来的に エンドポイント 単位で設定したいケースも
21. 21 Challenges 1. Gateway での認可 (1) トークンイントロスペクション Authority による複数のIssuerと通信する - 外部トークンの有効性検証 - 外部トークンのクレームを取得
22. 22 Challenges 1. Gateway での認可 (2) 認可 - 認可ルールに基づく 不許可 - Error
23. 23 Challenges 1. Gateway での認可 (2) 認可 - 認可ルールに基づく 許可 - Authority: 内部向けのトークンを発行 - Gateway: リクエストの継続
24. 24 Challenges 2. 各サービスでの認可 各サービスは自分へのリクエストに対し、 各自で認可ルールを定義し、アクセス制御を行う。
25. 25 Challenges 2. 各サービスでの認可 認可ルール 例： - Payment Service の精算メソッドをアクセスできるのは Merchant Service のみ - Payment Service の残高照会メソッドをアクセスできる のは、Mercari User からのリクエストのみ
26. 26 Challenges 2. 各サービスでの認可 認可ルール 定義場所 - 各サービス内 - protobuf, terraform, etc... 制限粒度 - サービス単位 - メソッド単位
27. 27 Challenges 2. 各サービスでの認可 認可ルール 構成要素 - 外部トークンのクレーム（ sub, aud, scope, etc..) - アクセス元のサービスのアイデンティティ
28. 28 Challenges 2. 各サービスでの認可 （1）外部トークンのクレームによる認可 Gateway で認可後、Authority が内部トークン を発行 ⇒ Private Access Token (PAT) 外部トークンのクレームが含まれる。
29. 29 Challenges Private Access Token (PAT) - JWT (Json Web Token) https://tools.ietf.org/html/rfc7519 - 1 リクエスト 1 トークン - TTL = 1 分 - Authority が発行、署名 - 非対称鍵暗号方式、鍵は定期的にローテート - 各マイクロサービスが PAT を検証 & 信用 - 検証・パース・Propagation などの機能は SDK で提供
30. 30 Challenges Private Access Token (PAT) jti - PAT ごとの Unique ID - リクエスト追跡にも利用される sub - <type>:<id> - mercari user, employee, partner scp - トークンに含まれる scope
31. 31 Challenges Private Access Token (PAT) v - バージョン - Claim の定義の breaking change など入るときには version up aud - 【間違い】誰向けに発行されたかを示す i.e. OIDC Client ID ⇒ 受信者（recipient）を識別するためのもの i.e. リクエスト経路上にある各サービスの namespace
32. 32 Challenges Private Access Token (PAT) amr - Authentication Methods References - https://tools.ietf.org/html/rfc8176 - どの手段で認証されたか - i.e. passcode
33. 33 Challenges Private Access Token (PAT) 検証と受け渡し: SDK を提供 • Authority の JWKs Endpoint から Pub Key を定期取得 & Cache • Client / Server Interceptor • 各 Claim を取得するメソッド • etc
34. 34 Challenges 2. 各サービスでの認可 （1）外部トークンのクレームによる認可 内部トークンの導入メリット • 楽に外部トークンの属性情報を内部サービスに 伝搬 • 各外部トークンのクレームの違いを吸収
35. 35 Challenges 2. 各サービスでの認可 （1）外部トークンのクレームによる認可 各サービスが、PAT に含まれる情報をみて、認可を行う。 • Sub 許可されているユーザ (種別)かどうか • Scp 必要な scope が含まれているかどうか • AMR 必要な認証方法が実施されているか ※ Aud について、PAT 発行時にリクエストがどのサービスに行き渡るか変わらないので、活用していない あと定義間違ったってところもあｒｙ（(´；ω；｀)ｳｯ…
36. 36 Challenges 2. 各サービスでの認可 （1）外部トークンのクレームによる認可 • 認可条件とレスポンスも各サービス自分で決める ◦ Scope = user:profile:read がなかったら、OK 返すが該当リソースを返さない ◦ AMR = PASSCODE がなかったら UNAUTHENTICATED を返す • 汎用的なルールを SDK の機能として提供したりする
37. 37 Challenges 2. 各サービスでの認可 （1）外部トークンのクレームによる認可 例: ExampleFunc にアクセスするには、 Passcode 認証済みが必要 • ルール定義は proto に書く ◦ rpc の定義に、option を追加する形 • サービス起動時に、 proto (file descriptor) が読み込まれる • リクエスト受信時に gRPC interceptor (SDK) が PAT とルールみて、通すか通さないかを決める
38. 38 Challenges 2. 各サービスでの認可 (2) リクエスト元サービスのアイデンティティによる認可 ⇒ サービス間認証認可 に近いイメージ。 例： Payment Service の精算メソッドは、Merchant Service にしかアクセスできない。
39. 39 Challenges 2. 各サービスでの認可 (2) リクエスト元サービスのアイデンティティによる認可 なぜ必要か - 外部トークンのクレームだけでは判断しきれない - 外部トークンが存在しないケース（ batch とか） - サービスは自分をアクセスするサービスを把握・制限すべき（理想）
40. 40 Challenges 2. 各サービスでの認可 (2) リクエスト元サービスのアイデンティティによる認可 A. サービス（Namespace）粒度 ⇒ k8s NetworkPolicy (namespaceSelector) を利用（L3/L4）
41. 41 Challenges 2. 各サービスでの認可 (2) リクエスト元サービスのアイデンティティによる認可 B. メソッド粒度 ⇒ L7 で実装する
42. 42 Challenges 2. 各サービスでの認可 (2) リクエスト元サービスのアイデンティティによる認可 B. メソッド粒度 MSID Token (microservice ID Token) を導入 • JWT 形式のアサーション • リクエスト元サービスのアイデンティティと、 リクエスト先サービスを示すもの ※ PAT の用途は変わらない ・「リクエスト元のクレーム」を持つもの presenter presenter recipient
43. 43 Challenges 2. 各サービスでの認可 (2) リクエスト元サービスのアイデンティティによる認可 B. メソッド粒度 Presenter • MSID Token 作成 • Google Service Account の秘密鍵で 署名 • Recipient へ MSID Token 付きでリクエスト
44. 44 Challenges 2. 各サービスでの認可 (2) リクエスト元サービスのアイデンティティによる認可 B. メソッド粒度 Recipient • Google IdP から Presenter の公開鍵を取得 • MSID Token の署名などを検証 • 自分が定義したルールによって認可を行う
45. 45 Challenges 2. 各サービスでの認可 まとめ 認可ルール • 外部トークンのクレーム x リクエスト元サービスのアイデンティティ x etc… 総合的に考慮 • 記載方法・場所は各サービスに委ねる 将来的に • Istio AuthorizationPolicy や opa-envoy-plugin などを検討したい • Protobuf ?? • Centralized Rule Engine ??
46. 46 04 Closing
47. 47 Closing Authorization Platform for Microservices - Fine-grained までほど遠い - 知見が足りなくて悩んでるところいっぱいある MS Platform 外の世界も面白い（また今度） - OpenID Connect and its friends
48. 48 Backend Engineer, ID Platform [Merpay] (EN) https://merc.li/DnSTmraka We Are Hiring!
49. 49 Let’s talk. https://twitter.com/nerocrux