Save 37% off PRO during our Black Friday Sale! »

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

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

D3edd53371e9150d3ea1c77deef77abf?s=128

Yu Peichao

April 01, 2021
Tweet

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 発行時にリクエストがどのサービスに行き渡るか変わらないので、活用していない あと定義間違ったってところもあry((´;ω;`)ウッ…
  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