Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
実践:マイクロサービス認可基盤
Yu Peichao
April 01, 2021
Programming
4
4.7k
実践:マイクロサービス認可基盤
Yu Peichao
April 01, 2021
Tweet
Share
Other Decks in Programming
See All in Programming
Lancersをコンテナへ本番移行する取り組み
rvirus0817
1
410
短納期でローンチした新サービスをJavaで開発した話/launched new service using Java
eichisanden
6
2k
Amazon ECSのネットワーク関連コストの話
msato
0
660
Meet Swift Regex
usamik26
0
370
ES2022の新機能
smt7174
0
270
heyにおけるCI/CDの現状と課題
fufuhu
3
560
[DevTrends - Jun/2022] Arquitetura baseada em eventos
camilacampos
0
160
The strategies behind ddd – AdeoDevSummit 2022
lilobase
PRO
5
260
リアルタイムボイスチェンジャーMMVCとVITSの紹介
stealthinu
0
160
即、New Relic / New Relic NOW!
uzulla
0
340
Scrum Fest Osaka 2022/5年で200人になったスタートアップの アジャイル開発の歴史とリアル
atamaplus
1
960
【Scrum Fest Osaka 2022】スクラムチームに放り込まれた若手エンジニアの皆さん、どのように技術のキャッチアップをしていくかイメージはついていますか?
miiiki
0
120
Featured
See All Featured
How to name files
jennybc
40
61k
The Cult of Friendly URLs
andyhume
68
4.8k
Optimizing for Happiness
mojombo
365
63k
Imperfection Machines: The Place of Print at Facebook
scottboms
253
12k
Docker and Python
trallard
27
1.6k
Bootstrapping a Software Product
garrettdimon
296
110k
The Power of CSS Pseudo Elements
geoffreycrofte
47
3.9k
VelocityConf: Rendering Performance Case Studies
addyosmani
316
22k
Product Roadmaps are Hard
iamctodd
34
6.6k
Making the Leap to Tech Lead
cromwellryan
113
7.4k
Fantastic passwords and where to find them - at NoRuKo
philnash
27
1.5k
Gamification - CAS2011
davidbonilla
75
3.9k
Transcript
1 実践:マイクロサービス認可基盤 @nerocrux
2 自己紹介 • 2018年6月にメルペイに入社 • ID Platform Team • 趣味はマラソンと認証認可関連のRFCを読むこと
◦ 最近は GNAP と ACE WG • 犬派 🐶 于 沛超 ウ ハイチョウ | @nerocrux
3 Introduction Agenda Architecture Challenges Closing 02 03 04 01
4 01 Introduction
5 メルカリ •サービス開始日:2013年7月 •対応OS:Android、iOS ※Webブラウザからも利用可能 •利用料:無料 ※売れたときの手数料:販売価格の 10% •対応地域・言語:日本・日本語基本仕様
•累計出品数:15億品を突破 それを必要とする人の手に渡り、使用されることに喜びを感じ、ま た購入者は、多彩かつユニークな商品の中から「宝探し」感覚で 掘り出し物を見つける買い物体験を楽しんでいます。さらに「メル カリ」では、物の売買だけではなく、出品者・購入者間のチャットや 「いいね!」機能を通じて、お客さま間のコミュニケーションも活発 に行われています。 フリマアプリ「メルカリ」は、個人が簡単に中古品の売買を行える CtoCマーケットプレイスです。出品者・購入者双方が、安全・安心 な取引を楽しんでいただけるサービスを目指し、「メルカリ」が一時 的に購入代金を預かるエスクロー決済を活用した取引環境の整 備や、簡単かつ手頃な価格の配送オプション、差別化されたユ ニークなお客さま体験を提供しています。多くの出品者は、自分に とって必要でなくなったモノが、 5
6 メルペイ 日本最大のフリマアプリを提供する株式会社メルカリのグループ会社で ある、株式会社メルペイが運営するスマホ決済サービス。 使わなくなったものをメルカリで売って得た売 上 金や、銀 行 口
座から チャージしたお金、また「メルペイスマート払い」を利用して、「メルカリ」や 全国174万か所のメルペイ加盟店でのお支払いに利用可能。今後は新し い「信用」を軸にしたサービス展開予定。
7 メルカリ・メルペイ メルカリJP MAU¹ 1802万人 メルペイ 利用者数1 850万人 出典:会社資料。JP版メルカリ事業の通期決算概況(FY2021.6
2Q)より。 1. メルペイ「電子マネー」の登録を行ったユーザと、「メルペイコード決済」、「ネット決済」、 「メルペイスマート払い」等の利用者の合計(重複を除く)2020年10月5日時点。
8 ID Platform Team @kung @nerocrux @kokukuma @eric @g-varona @utkarsh
@gia.nguyen @robert @nikku
9 Introduction 2013年 • メルカリサービス開始 ◦ モノリシックなPHP ◦ クライアント/用途に合わせて、認証認可の仕組みを自前で実装 2017年
• メルペイ設立 ◦ サービス計画段階からマイクロサービス採用 (Golang, GCP/GKE) ▪ メルカリもその後、マイクロサービスへシフト(継続中) ◦ サービスはメルカリ本体と密結合
10 Introduction 2018年 • ID Platform Team 設立 @メルペイ ◦
マイクロサービス基盤のための認可の仕組み を実装 & 運用 ◦ OpenID Connect のサーバを実装 & 運用 ◦ 既存の認証認可基盤(モノリシック)のオーナーになり、運用改善
11 02 Architecture
12 Architecture マイクロサービスアーキテクチャ
13 Architecture マイクロサービスアーキテクチャ (1) 外部からのリクエストに含まれるトークンが色々 i.e. 独自仕様のもの、OIDC Token、Google ID Token,
etc... - Issuer が異なる - モノリシックPHP、OIDC、Google... - Spec も異なる - JWT / Opaque - 異なる Claims
14 Architecture マイクロサービスアーキテクチャ (2) API Gateway の後ろにあるサービス - gRPC で通信する
- 大量に存在する(増え続ける) - 依存関係
15 03 Challenges
16 Challenges マイクロサービスアーキテクチャにおける認可 ちゃれんじ マイクロサービス基盤内の各サービスが正しく認可を行えること • Gateway • 各 Service
17 Challenges 1. Gateway での認可 クライアントからのリクエスト(に含まれるクレデンシャル)が、 リクエスト先のドメイン・エンドポイントにアクセスする権限あるか。
18 Challenges 1. Gateway での認可 Authority というサービスが司る。
19 Challenges 1. Gateway での認可 認可ルール 例 - Mercari App
向けに発行されたトークンが ドメイン 〇〇 の Endpoint にアクセスできる - Scope 〇〇 が含まれたトークンが Endpoint X にアクセスできる
20 Challenges 1. Gateway での認可 認可ルール 定義場所 - Authority /
Gateway 構成要素 - トークンの種類 - トークンのクレーム(audience, scope) 制限粒度 - 現状は ドメイン 単位 - 将来的に エンドポイント 単位で設定したいケースも
21 Challenges 1. Gateway での認可 (1) トークンイントロスペクション Authority による複数のIssuerと通信する -
外部トークンの有効性検証 - 外部トークンのクレームを取得
22 Challenges 1. Gateway での認可 (2) 認可 - 認可ルールに基づく 不許可
- Error
23 Challenges 1. Gateway での認可 (2) 認可 - 認可ルールに基づく 許可
- Authority: 内部向けのトークンを発行 - Gateway: リクエストの継続
24 Challenges 2. 各サービスでの認可 各サービスは自分へのリクエストに対し、 各自で認可ルールを定義し、アクセス制御を行う。
25 Challenges 2. 各サービスでの認可 認可ルール 例: - Payment Service の精算メソッドをアクセスできるのは
Merchant Service のみ - Payment Service の残高照会メソッドをアクセスできる のは、Mercari User からのリクエストのみ
26 Challenges 2. 各サービスでの認可 認可ルール 定義場所 - 各サービス内 - protobuf,
terraform, etc... 制限粒度 - サービス単位 - メソッド単位
27 Challenges 2. 各サービスでの認可 認可ルール 構成要素 - 外部トークンのクレーム( sub, aud,
scope, etc..) - アクセス元のサービスのアイデンティティ
28 Challenges 2. 各サービスでの認可 (1)外部トークンのクレームによる認可 Gateway で認可後、Authority が内部トークン を発行 ⇒
Private Access Token (PAT) 外部トークンのクレームが含まれる。
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 Challenges Private Access Token (PAT) jti - PAT ごとの
Unique ID - リクエスト追跡にも利用される sub - <type>:<id> - mercari user, employee, partner scp - トークンに含まれる scope
31 Challenges Private Access Token (PAT) v - バージョン -
Claim の定義の breaking change など入るときには version up aud - 【間違い】誰向けに発行されたかを示す i.e. OIDC Client ID ⇒ 受信者(recipient)を識別するためのもの i.e. リクエスト経路上にある各サービスの namespace
32 Challenges Private Access Token (PAT) amr - Authentication Methods
References - https://tools.ietf.org/html/rfc8176 - どの手段で認証されたか - i.e. passcode
33 Challenges Private Access Token (PAT) 検証と受け渡し: SDK を提供 •
Authority の JWKs Endpoint から Pub Key を定期取得 & Cache • Client / Server Interceptor • 各 Claim を取得するメソッド • etc
34 Challenges 2. 各サービスでの認可 (1)外部トークンのクレームによる認可 内部トークンの導入メリット • 楽に外部トークンの属性情報を内部サービスに 伝搬 •
各外部トークンのクレームの違いを吸収
35 Challenges 2. 各サービスでの認可 (1)外部トークンのクレームによる認可 各サービスが、PAT に含まれる情報をみて、認可を行う。 • Sub 許可されているユーザ
(種別)かどうか • Scp 必要な scope が含まれているかどうか • AMR 必要な認証方法が実施されているか ※ Aud について、PAT 発行時にリクエストがどのサービスに行き渡るか変わらないので、活用していない あと定義間違ったってところもあry((´;ω;`)ウッ…
36 Challenges 2. 各サービスでの認可 (1)外部トークンのクレームによる認可 • 認可条件とレスポンスも各サービス自分で決める ◦ Scope =
user:profile:read がなかったら、OK 返すが該当リソースを返さない ◦ AMR = PASSCODE がなかったら UNAUTHENTICATED を返す • 汎用的なルールを SDK の機能として提供したりする
37 Challenges 2. 各サービスでの認可 (1)外部トークンのクレームによる認可 例: ExampleFunc にアクセスするには、 Passcode 認証済みが必要
• ルール定義は proto に書く ◦ rpc の定義に、option を追加する形 • サービス起動時に、 proto (file descriptor) が読み込まれる • リクエスト受信時に gRPC interceptor (SDK) が PAT とルールみて、通すか通さないかを決める
38 Challenges 2. 各サービスでの認可 (2) リクエスト元サービスのアイデンティティによる認可 ⇒ サービス間認証認可 に近いイメージ。 例:
Payment Service の精算メソッドは、Merchant Service にしかアクセスできない。
39 Challenges 2. 各サービスでの認可 (2) リクエスト元サービスのアイデンティティによる認可 なぜ必要か - 外部トークンのクレームだけでは判断しきれない -
外部トークンが存在しないケース( batch とか) - サービスは自分をアクセスするサービスを把握・制限すべき(理想)
40 Challenges 2. 各サービスでの認可 (2) リクエスト元サービスのアイデンティティによる認可 A. サービス(Namespace)粒度 ⇒ k8s
NetworkPolicy (namespaceSelector) を利用(L3/L4)
41 Challenges 2. 各サービスでの認可 (2) リクエスト元サービスのアイデンティティによる認可 B. メソッド粒度 ⇒ L7
で実装する
42 Challenges 2. 各サービスでの認可 (2) リクエスト元サービスのアイデンティティによる認可 B. メソッド粒度 MSID Token
(microservice ID Token) を導入 • JWT 形式のアサーション • リクエスト元サービスのアイデンティティと、 リクエスト先サービスを示すもの ※ PAT の用途は変わらない ・「リクエスト元のクレーム」を持つもの presenter presenter recipient
43 Challenges 2. 各サービスでの認可 (2) リクエスト元サービスのアイデンティティによる認可 B. メソッド粒度 Presenter •
MSID Token 作成 • Google Service Account の秘密鍵で 署名 • Recipient へ MSID Token 付きでリクエスト
44 Challenges 2. 各サービスでの認可 (2) リクエスト元サービスのアイデンティティによる認可 B. メソッド粒度 Recipient •
Google IdP から Presenter の公開鍵を取得 • MSID Token の署名などを検証 • 自分が定義したルールによって認可を行う
45 Challenges 2. 各サービスでの認可 まとめ 認可ルール • 外部トークンのクレーム x リクエスト元サービスのアイデンティティ
x etc… 総合的に考慮 • 記載方法・場所は各サービスに委ねる 将来的に • Istio AuthorizationPolicy や opa-envoy-plugin などを検討したい • Protobuf ?? • Centralized Rule Engine ??
46 04 Closing
47 Closing Authorization Platform for Microservices - Fine-grained までほど遠い -
知見が足りなくて悩んでるところいっぱいある MS Platform 外の世界も面白い(また今度) - OpenID Connect and its friends
48 Backend Engineer, ID Platform [Merpay] (EN) https://merc.li/DnSTmraka We Are
Hiring!
49 Let’s talk. https://twitter.com/nerocrux