Backend Engineer’s meetup ~マイクロサービスにおける認証認可基盤
マイクロサービスの内部通信における認証について
@pospome
資料
メルペイ認証チーム（メルカリ、メルペイ） チームに関してはブログあり
ユーザアカウント、ログインはそれぞれのチームで担当しているので認証ではやってない
入社、退職などの社内管理はしてない
セキュリティはセキュリティーチームに都度相談している
では何をしている
OIDC認可の仕組み→今日は説明しない
内部マイクロサービス間の通信認証→こちらを説明
メルカリアプリ Mercari API直接アクセスするパターン
マイクロサービスは Gatewayを介してAuthoriytServiceを利用
AtuhorityServiceは何をしている？
各サービスはトークンで検証
-
1リクエスト１トークン
JWTを採用
内部トークン用SDKを採用
トークン検証 gRPCのintercepter
gorouting
subjectID
文字列type value 複数のID体系を一つの構成で
メルカリを受け取る場合、typeをチェックして弾く
パース処理は、SDKで実装
内部アクセス制限
内部スコープ 各サービスがもつリソースに持つ
外部スコープをそのまま内部スコープにセットすることができる
外部、内部スコープが一致しない場合。
外部スコープ→ユースケースベース
内部スコープ→リソースベース
マッピングするテーブルを持たす
内部トークンのメリット
トークンを１種にできる 直接内部リソースにアクセスできない
外部のアクセストークンを短く設定出来る
できてないこと沢山ある
パネルディスカッション
質問
- マッピングを持たした理由
→関連するマイクロサービスが多ければ多いほど、関わるものが多くなる。ユーザからはどのマイクロ使うかわからないので。ユースケース毎にマッピングテーブルを持たした
- 内部トークンの保持期限
→有効期限、保存していない。可用性→サーバを複数台用意して分散しているけど特別なことはしていない
- 各サービス間のアクセス制御
→マイクロサービス間の認証はやっていない。導入しようとは検討している。originのリクエスト権限の範囲で処理できる機能を制限している。
- 外部スコープと内部スコープの管理→各部門が申請して管理している？監査している？
→まだそこは全然考えていない。そのフェーズにはいってない。課題として考えている
公開鍵の管理、前何世代までOK →前の鍵が使えなくなることは無い。
BASE64の長さが長くなってパフォーマンス問題ならない？
→JWTだとデータ量が多くなるからやめたい→CWTの機運
- アカウントの管理は対象外、アカウントの認証はどこでしている？
→リクエストについているアクセストークンで判断。ログイン部分はマイクロサービス化していない
→レイテンシ、そこまで気にしない。モノリスにするのが一番早いので考えない。必ず通るとこはなるべく早くするように心がけている。ローカルメモリで完結。memchacheとか使いたいがそこまではしてない
トークンの検証SDK自体の更新はどうしている、配信とかは →いい仕組みは出ていない。スプレッドシートで書いて上げている→辛い。正しく提供しているのはGOだけsidecarとかで運用したい
内部トークンを有効期限
→すごく短く。どんなけ待つ必要があるか目安
- マッピング手作業の部分など辛い箇所はどこ
→アカウントの種類が増えると増やすけど、アカウントそんな増えない。マスターデータが増えるタイミングは自動化したい
- あるサービスからバッチ処理実行することはある？
→ある。内部トークンを取得して実施している。秘密鍵を利用している→スコープは現状紐づけていない
- AuthoriytServiceだけでチェックで十分では？
→内部サービス間の通信は必ず大丈夫と認識していないのでそうしている
- 一番厳しいユースケースは？
→pubsub非同期で扱わないといけない時、有効期限が切れた時どうするのか。解決策は特に無い
- 苦労話
→内部通信の技術的な課題をどう解決するか？リソースが足りないPOもやっているので精神的に辛い
→複雑な考え方が社内で通じるのか不安だったが、使われて良かった。
→チームが四人しかいない。人手が足りない。DCまたいで通信が切れたら大障害になっちゃう。認可サーバー経験が豊富で無いのでセキュリティ大丈夫か不安
