Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

Yu Peichao

April 01, 2021
Tweet

Other Decks in Programming

Transcript

  1. 5 メルカリ
 •サービス開始日:2013年7月
 •対応OS:Android、iOS ※Webブラウザからも利用可能 
 •利用料:無料
 ※売れたときの手数料:販売価格の 10% •対応地域・言語:日本・日本語基本仕様


    •累計出品数:15億品を突破
 
 それを必要とする人の手に渡り、使用されることに喜びを感じ、ま た購入者は、多彩かつユニークな商品の中から「宝探し」感覚で 掘り出し物を見つける買い物体験を楽しんでいます。さらに「メル カリ」では、物の売買だけではなく、出品者・購入者間のチャットや 「いいね!」機能を通じて、お客さま間のコミュニケーションも活発 に行われています。 
 フリマアプリ「メルカリ」は、個人が簡単に中古品の売買を行える CtoCマーケットプレイスです。出品者・購入者双方が、安全・安心 な取引を楽しんでいただけるサービスを目指し、「メルカリ」が一時 的に購入代金を預かるエスクロー決済を活用した取引環境の整 備や、簡単かつ手頃な価格の配送オプション、差別化されたユ ニークなお客さま体験を提供しています。多くの出品者は、自分に とって必要でなくなったモノが、 
 5
  2. 6 メルペイ
 日本最大のフリマアプリを提供する株式会社メルカリのグループ会社で ある、株式会社メルペイが運営するスマホ決済サービス。 
 使わなくなったものをメルカリで売って得た売 上 金や、銀 行 口

    座から チャージしたお金、また「メルペイスマート払い」を利用して、「メルカリ」や 全国174万か所のメルペイ加盟店でのお支払いに利用可能。今後は新し い「信用」を軸にしたサービス展開予定。 
 
 
 

  3. 7 メルカリ・メルペイ
 メルカリJP MAU¹
 1802万人
 メルペイ 利用者数1 
 850万人
 出典:会社資料。JP版メルカリ事業の通期決算概況(FY2021.6

    2Q)より。
 1. メルペイ「電子マネー」の登録を行ったユーザと、「メルペイコード決済」、「ネット決済」、
 「メルペイスマート払い」等の利用者の合計(重複を除く)2020年10月5日時点。

  4. 9 Introduction 2013年 • メルカリサービス開始 ◦ モノリシックなPHP ◦ クライアント/用途に合わせて、認証認可の仕組みを自前で実装 2017年

    • メルペイ設立 ◦ サービス計画段階からマイクロサービス採用 (Golang, GCP/GKE) ▪ メルカリもその後、マイクロサービスへシフト(継続中) ◦ サービスはメルカリ本体と密結合
  5. 10 Introduction 2018年 • ID Platform Team 設立 @メルペイ ◦

    マイクロサービス基盤のための認可の仕組み を実装 & 運用 ◦ OpenID Connect のサーバを実装 & 運用 ◦ 既存の認証認可基盤(モノリシック)のオーナーになり、運用改善
  6. 13 Architecture マイクロサービスアーキテクチャ (1) 外部からのリクエストに含まれるトークンが色々 i.e. 独自仕様のもの、OIDC Token、Google ID Token,

    etc... - Issuer が異なる - モノリシックPHP、OIDC、Google... - Spec も異なる - JWT / Opaque - 異なる Claims
  7. 19 Challenges 1. Gateway での認可 認可ルール 例 - Mercari App

    向けに発行されたトークンが ドメイン 〇〇 の Endpoint にアクセスできる - Scope 〇〇 が含まれたトークンが Endpoint X にアクセスできる
  8. 20 Challenges 1. Gateway での認可 認可ルール 定義場所 - Authority /

    Gateway 構成要素 - トークンの種類 - トークンのクレーム(audience, scope) 制限粒度 - 現状は ドメイン 単位 - 将来的に エンドポイント 単位で設定したいケースも
  9. 23 Challenges 1. Gateway での認可 (2) 認可 - 認可ルールに基づく 許可

    - Authority: 内部向けのトークンを発行 - Gateway: リクエストの継続
  10. 25 Challenges 2. 各サービスでの認可 認可ルール 例: - Payment Service の精算メソッドをアクセスできるのは

    Merchant Service のみ - Payment Service の残高照会メソッドをアクセスできる のは、Mercari User からのリクエストのみ
  11. 26 Challenges 2. 各サービスでの認可 認可ルール 定義場所 - 各サービス内 - protobuf,

    terraform, etc... 制限粒度 - サービス単位 - メソッド単位
  12. 29 Challenges Private Access Token (PAT) - JWT (Json Web

    Token) https://tools.ietf.org/html/rfc7519 - 1 リクエスト 1 トークン - TTL = 1 分 - Authority が発行、署名 - 非対称鍵暗号方式、鍵は定期的にローテート - 各マイクロサービスが PAT を検証 & 信用 - 検証・パース・Propagation などの機能は SDK で提供
  13. 30 Challenges Private Access Token (PAT) jti - PAT ごとの

    Unique ID - リクエスト追跡にも利用される sub - <type>:<id> - mercari user, employee, partner scp - トークンに含まれる scope
  14. 31 Challenges Private Access Token (PAT) v - バージョン -

    Claim の定義の breaking change など入るときには version up aud - 【間違い】誰向けに発行されたかを示す i.e. OIDC Client ID ⇒ 受信者(recipient)を識別するためのもの i.e. リクエスト経路上にある各サービスの namespace
  15. 32 Challenges Private Access Token (PAT) amr - Authentication Methods

    References - https://tools.ietf.org/html/rfc8176 - どの手段で認証されたか - i.e. passcode
  16. 33 Challenges Private Access Token (PAT) 検証と受け渡し: SDK を提供 •

    Authority の JWKs Endpoint から Pub Key を定期取得 & Cache • Client / Server Interceptor • 各 Claim を取得するメソッド • etc
  17. 35 Challenges 2. 各サービスでの認可 (1)外部トークンのクレームによる認可 各サービスが、PAT に含まれる情報をみて、認可を行う。 • Sub 許可されているユーザ

    (種別)かどうか • Scp 必要な scope が含まれているかどうか • AMR 必要な認証方法が実施されているか ※ Aud について、PAT 発行時にリクエストがどのサービスに行き渡るか変わらないので、活用していない あと定義間違ったってところもあry((´;ω;`)ウッ…
  18. 36 Challenges 2. 各サービスでの認可 (1)外部トークンのクレームによる認可 • 認可条件とレスポンスも各サービス自分で決める ◦ Scope =

    user:profile:read がなかったら、OK 返すが該当リソースを返さない ◦ AMR = PASSCODE がなかったら UNAUTHENTICATED を返す • 汎用的なルールを SDK の機能として提供したりする
  19. 37 Challenges 2. 各サービスでの認可 (1)外部トークンのクレームによる認可 例: ExampleFunc にアクセスするには、 Passcode 認証済みが必要

    • ルール定義は proto に書く ◦ rpc の定義に、option を追加する形 • サービス起動時に、 proto (file descriptor) が読み込まれる • リクエスト受信時に gRPC interceptor (SDK) が PAT とルールみて、通すか通さないかを決める
  20. 39 Challenges 2. 各サービスでの認可 (2) リクエスト元サービスのアイデンティティによる認可 なぜ必要か - 外部トークンのクレームだけでは判断しきれない -

    外部トークンが存在しないケース( batch とか) - サービスは自分をアクセスするサービスを把握・制限すべき(理想)
  21. 42 Challenges 2. 各サービスでの認可 (2) リクエスト元サービスのアイデンティティによる認可 B. メソッド粒度 MSID Token

    (microservice ID Token) を導入 • JWT 形式のアサーション • リクエスト元サービスのアイデンティティと、 リクエスト先サービスを示すもの ※ PAT の用途は変わらない ・「リクエスト元のクレーム」を持つもの presenter presenter recipient
  22. 43 Challenges 2. 各サービスでの認可 (2) リクエスト元サービスのアイデンティティによる認可 B. メソッド粒度 Presenter •

    MSID Token 作成 • Google Service Account の秘密鍵で 署名 • Recipient へ MSID Token 付きでリクエスト
  23. 44 Challenges 2. 各サービスでの認可 (2) リクエスト元サービスのアイデンティティによる認可 B. メソッド粒度 Recipient •

    Google IdP から Presenter の公開鍵を取得 • MSID Token の署名などを検証 • 自分が定義したルールによって認可を行う
  24. 45 Challenges 2. 各サービスでの認可 まとめ 認可ルール • 外部トークンのクレーム x リクエスト元サービスのアイデンティティ

    x etc… 総合的に考慮 • 記載方法・場所は各サービスに委ねる 将来的に • Istio AuthorizationPolicy や opa-envoy-plugin などを検討したい • Protobuf ?? • Centralized Rule Engine ??
  25. 47 Closing Authorization Platform for Microservices - Fine-grained までほど遠い -

    知見が足りなくて悩んでるところいっぱいある MS Platform 外の世界も面白い(また今度) - OpenID Connect and its friends