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

by Yu Peichao

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

2 自己紹介 ● 2018年6月にメルペイに入社 ● ID Platform Team ● 趣味はマラソンと認証認可関連のRFCを読むこと ○ 最近は GNAP と ACE WG ● 犬派 🐶 于沛超ウハイチョウ | @nerocrux

Slide 3

Slide 3 text

3 Introduction Agenda Architecture Challenges Closing 02 03 04 01

Slide 4

Slide 4 text

4 01 Introduction

Slide 5

Slide 5 text

5 メルカリ  ●サービス開始日：2013年7月  ●対応OS：Android、iOS ※Webブラウザからも利用可能   ●利用料：無料  ※売れたときの手数料：販売価格の 10% ●対応地域・言語：日本・日本語基本仕様  ●累計出品数：15億品を突破    それを必要とする人の手に渡り、使用されることに喜びを感じ、また購入者は、多彩かつユニークな商品の中から「宝探し」感覚で掘り出し物を見つける買い物体験を楽しんでいます。さらに「メルカリ」では、物の売買だけではなく、出品者・購入者間のチャットや「いいね！」機能を通じて、お客さま間のコミュニケーションも活発に行われています。   フリマアプリ「メルカリ」は、個人が簡単に中古品の売買を行える CtoCマーケットプレイスです。出品者・購入者双方が、安全・安心な取引を楽しんでいただけるサービスを目指し、「メルカリ」が一時的に購入代金を預かるエスクロー決済を活用した取引環境の整備や、簡単かつ手頃な価格の配送オプション、差別化されたユニークなお客さま体験を提供しています。多くの出品者は、自分にとって必要でなくなったモノが、   5

Slide 6

Slide 6 text

6 メルペイ  日本最大のフリマアプリを提供する株式会社メルカリのグループ会社である、株式会社メルペイが運営するスマホ決済サービス。   使わなくなったものをメルカリで売って得た売上金や、銀行口座からチャージしたお金、また「メルペイスマート払い」を利用して、「メルカリ」や全国174万か所のメルペイ加盟店でのお支払いに利用可能。今後は新しい「信用」を軸にしたサービス展開予定。        

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

9 Introduction 2013年 ● メルカリサービス開始 ○ モノリシックなPHP ○ クライアント/用途に合わせて、認証認可の仕組みを自前で実装 2017年 ● メルペイ設立 ○ サービス計画段階からマイクロサービス採用 (Golang, GCP/GKE) ■ メルカリもその後、マイクロサービスへシフト（継続中） ○ サービスはメルカリ本体と密結合

Slide 10

Slide 10 text

10 Introduction 2018年 ● ID Platform Team 設立 @メルペイ ○ マイクロサービス基盤のための認可の仕組みを実装 & 運用 ○ OpenID Connect のサーバを実装 & 運用 ○ 既存の認証認可基盤（モノリシック）のオーナーになり、運用改善

Slide 11

Slide 11 text

11 02 Architecture

Slide 12

Slide 12 text

12 Architecture マイクロサービスアーキテクチャ

Slide 13

Slide 13 text

13 Architecture マイクロサービスアーキテクチャ (1) 外部からのリクエストに含まれるトークンが色々 i.e. 独自仕様のもの、OIDC Token、Google ID Token, etc... - Issuer が異なる - モノリシックPHP、OIDC、Google... - Spec も異なる - JWT / Opaque - 異なる Claims

Slide 14

Slide 14 text

14 Architecture マイクロサービスアーキテクチャ (2) API Gateway の後ろにあるサービス - gRPC で通信する - 大量に存在する（増え続ける） - 依存関係

Slide 15

Slide 15 text

15 03 Challenges

Slide 16

Slide 16 text

16 Challenges マイクロサービスアーキテクチャにおける認可ちゃれんじマイクロサービス基盤内の各サービスが正しく認可を行えること ● Gateway ● 各 Service

Slide 17

Slide 17 text

17 Challenges 1. Gateway での認可クライアントからのリクエスト（に含まれるクレデンシャル）が、リクエスト先のドメイン・エンドポイントにアクセスする権限あるか。

Slide 18

Slide 18 text

18 Challenges 1. Gateway での認可 Authority というサービスが司る。

Slide 19

Slide 19 text

19 Challenges 1. Gateway での認可認可ルール例 - Mercari App 向けに発行されたトークンがドメイン〇〇の Endpoint にアクセスできる - Scope 〇〇が含まれたトークンが Endpoint X にアクセスできる

Slide 20

Slide 20 text

20 Challenges 1. Gateway での認可認可ルール定義場所 - Authority / Gateway 構成要素 - トークンの種類 - トークンのクレーム（audience, scope）制限粒度 - 現状はドメイン単位 - 将来的にエンドポイント単位で設定したいケースも

Slide 21

Slide 21 text

21 Challenges 1. Gateway での認可 (1) トークンイントロスペクション Authority による複数のIssuerと通信する - 外部トークンの有効性検証 - 外部トークンのクレームを取得

Slide 22

Slide 22 text

22 Challenges 1. Gateway での認可 (2) 認可 - 認可ルールに基づく不許可 - Error

Slide 23

Slide 23 text

23 Challenges 1. Gateway での認可 (2) 認可 - 認可ルールに基づく許可 - Authority: 内部向けのトークンを発行 - Gateway: リクエストの継続

Slide 24

Slide 24 text

24 Challenges 2. 各サービスでの認可各サービスは自分へのリクエストに対し、各自で認可ルールを定義し、アクセス制御を行う。

Slide 25

Slide 25 text

25 Challenges 2. 各サービスでの認可認可ルール例： - Payment Service の精算メソッドをアクセスできるのは Merchant Service のみ - Payment Service の残高照会メソッドをアクセスできるのは、Mercari User からのリクエストのみ

Slide 26

Slide 26 text

26 Challenges 2. 各サービスでの認可認可ルール定義場所 - 各サービス内 - protobuf, terraform, etc... 制限粒度 - サービス単位 - メソッド単位

Slide 27

Slide 27 text

27 Challenges 2. 各サービスでの認可認可ルール構成要素 - 外部トークンのクレーム（ sub, aud, scope, etc..) - アクセス元のサービスのアイデンティティ

Slide 28

Slide 28 text

28 Challenges 2. 各サービスでの認可（1）外部トークンのクレームによる認可 Gateway で認可後、Authority が内部トークンを発行 ⇒ Private Access Token (PAT) 外部トークンのクレームが含まれる。

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

30 Challenges Private Access Token (PAT) jti - PAT ごとの Unique ID - リクエスト追跡にも利用される sub - : - mercari user, employee, partner scp - トークンに含まれる scope

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

32 Challenges Private Access Token (PAT) amr - Authentication Methods References - https://tools.ietf.org/html/rfc8176 - どの手段で認証されたか - i.e. passcode

Slide 33

Slide 33 text

33 Challenges Private Access Token (PAT) 検証と受け渡し: SDK を提供 ● Authority の JWKs Endpoint から Pub Key を定期取得 & Cache ● Client / Server Interceptor ● 各 Claim を取得するメソッド ● etc

Slide 34

Slide 34 text

34 Challenges 2. 各サービスでの認可（1）外部トークンのクレームによる認可内部トークンの導入メリット ● 楽に外部トークンの属性情報を内部サービスに伝搬 ● 各外部トークンのクレームの違いを吸収

Slide 35

Slide 35 text

35 Challenges 2. 各サービスでの認可（1）外部トークンのクレームによる認可各サービスが、PAT に含まれる情報をみて、認可を行う。 ● Sub 許可されているユーザ (種別)かどうか ● Scp 必要な scope が含まれているかどうか ● AMR 必要な認証方法が実施されているか ※ Aud について、PAT 発行時にリクエストがどのサービスに行き渡るか変わらないので、活用していないあと定義間違ったってところもあｒｙ（(´；ω；｀)ｳｯ…

Slide 36

Slide 36 text

36 Challenges 2. 各サービスでの認可（1）外部トークンのクレームによる認可 ● 認可条件とレスポンスも各サービス自分で決める ○ Scope = user:proﬁle:read がなかったら、OK 返すが該当リソースを返さない ○ AMR = PASSCODE がなかったら UNAUTHENTICATED を返す ● 汎用的なルールを SDK の機能として提供したりする

Slide 37

Slide 37 text

37 Challenges 2. 各サービスでの認可（1）外部トークンのクレームによる認可例: ExampleFunc にアクセスするには、 Passcode 認証済みが必要 ● ルール定義は proto に書く ○ rpc の定義に、option を追加する形 ● サービス起動時に、 proto (ﬁle descriptor) が読み込まれる ● リクエスト受信時に gRPC interceptor (SDK) が PAT とルールみて、通すか通さないかを決める

Slide 38

Slide 38 text

38 Challenges 2. 各サービスでの認可 (2) リクエスト元サービスのアイデンティティによる認可 ⇒ サービス間認証認可に近いイメージ。例： Payment Service の精算メソッドは、Merchant Service にしかアクセスできない。

Slide 39

Slide 39 text

39 Challenges 2. 各サービスでの認可 (2) リクエスト元サービスのアイデンティティによる認可なぜ必要か - 外部トークンのクレームだけでは判断しきれない - 外部トークンが存在しないケース（ batch とか） - サービスは自分をアクセスするサービスを把握・制限すべき（理想）

Slide 40

Slide 40 text

40 Challenges 2. 各サービスでの認可 (2) リクエスト元サービスのアイデンティティによる認可 A. サービス（Namespace）粒度 ⇒ k8s NetworkPolicy (namespaceSelector) を利用（L3/L4）

Slide 41

Slide 41 text

41 Challenges 2. 各サービスでの認可 (2) リクエスト元サービスのアイデンティティによる認可 B. メソッド粒度 ⇒ L7 で実装する

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

44 Challenges 2. 各サービスでの認可 (2) リクエスト元サービスのアイデンティティによる認可 B. メソッド粒度 Recipient ● Google IdP から Presenter の公開鍵を取得 ● MSID Token の署名などを検証 ● 自分が定義したルールによって認可を行う

Slide 45

Slide 45 text

45 Challenges 2. 各サービスでの認可まとめ認可ルール ● 外部トークンのクレーム x リクエスト元サービスのアイデンティティ x etc… 総合的に考慮 ● 記載方法・場所は各サービスに委ねる将来的に ● Istio AuthorizationPolicy や opa-envoy-plugin などを検討したい ● Protobuf ?? ● Centralized Rule Engine ??

Slide 46

Slide 46 text

46 04 Closing

Slide 47

Slide 47 text

47 Closing Authorization Platform for Microservices - Fine-grained までほど遠い - 知見が足りなくて悩んでるところいっぱいある MS Platform 外の世界も面白い（また今度） - OpenID Connect and its friends

Slide 48

Slide 48 text

48 Backend Engineer, ID Platform [Merpay] (EN) https://merc.li/DnSTmraka We Are Hiring!

Slide 49

Slide 49 text

49 Let’s talk. https://twitter.com/nerocrux