Backend Engineer’s meetup ~マイクロサービスにおける認証認可基盤~

• connpass
• ハッシュタグ：#merpay_meetup

メルカリさん恒例のオリジナルドリンクもらいました

1. マイクロサービスの内部通信における認証について

登壇者：@pospome さん

スライド （日本語が消えてしまっていますが、ダウンロードしたら見れました）

上記スライドの簡易メモ

• アカウント管理とログイン処理はそれぞれのチームに任せている

  • SubjectID という 全サービス共通のID に変換して扱う

• メルカリでは、OIDCベースの認可の仕組みを採用

  • RFCに書いてあるものと大差ないので、今回は マイクロサービスの内部通信における認証 について話す

• 全サービスは Gatwway を経由

  • Gateway から Authority Service にくる

• Authority Service を認証基盤チームが管理

  • 外部からのリクエスト検証と内部通信用のトークンを生成している

• 内部トークンは毎リクエストごとに生成

  • マイクロサービス間で使用されるトークンはリクエスト単位で同一

• 内部トークン用のSDKを提供

  • Goのみ対応
  • SDKを使うといろいろとよしなにしてくれる
    • クレームをいい感じに取得
    • SubjectID のパースとかをいい感じにしてくれる

• マイクロサービスはバッチのためのエンドポイントをもつことがあるので、Gatewayによってユーザが直接叩くことがきない環境を作れるのはメリットとなる

2. パネルディスカッション

登壇者：

• Keigo Watanabe さん
• @kazegusuri
• @nerocrux
• @pospome

パネルディスカッションのはずがほとんど質疑で終わりましたｗ

質疑は さきほどの 発表 に対するものが主でした。

したがって、以下、上記発表に関する質問と回答になります。

Q. 第三パーティーにスコープを指定させるのではなく、外部スコープと内部スコープのマッピングを行ったのはなぜか

A.

ユースケースベースでスコープを提供した方が第三パーティーの開発者がわかりやすい。

リソースベースだとどれが必要なスコープなのかが分かりづらい。

（yyh-gl 感想）

AWSのポリシーがリソースベースだと思うんだけど、どのポリシーが必要か分かりづらいもんねー

Q. JWT（内部トークン）の保持期間（消すタイミング、有効期限）

A. 保存していない

Q. Authority Serviceの可用性

A.

処理自体は複雑ではないし、特に何か特別なことをやっているわけではない。

マイクロサービスに対するリクエストのリトライ、タイムアウトとかはやっている。

Q. サービス間のアクセス制御はどのようにやってるか？各サービスが送信元をチェックするのか？どのサービスが度のサービスにアクセスするかの制御はどうしてるのか？

A.

どちらかというと認可の話だと思っている。まだやっていない。

Originを見て、どこまでの処理をマイクロサービスがやっていいかは決めている。

Q. 不正監視はしている？

A. 内部トークンの有効期限が短いので、現状やっていない。

Q. 外部スコープと内部スコープの管理が大変そう。マイクロサービスを分割したときとか。このテーブルの管理は（誰が）どうやっている？

A.

まだ一部でしか使っていないので、管理が難しいフェーズではない。ただし、今後その必要性は感じているので、対策を考える必要あり。

Q. 公開鍵の失効タイミングはどのようにしているか？スロット的な仕組みは入れているのか？

A.

公開鍵と秘密鍵はN世代で管理している。

メルペイでは Design Doc を作ってしっかりと議論してから開発を進めていくと決めている。

Q. JWTトークンにクレーム含ませると長くなってくると思うけど、パフォーマンスとか大丈夫？

A.

長くなることは懸念している。

CWT(https://tools.ietf.org/html/rfc8392)(CBOR ) とかで、バイナリ化したいと勝手に思っている。

Q. ユーザーのアカウント認証は Authority Service でやっているか？

A. ログイン部分は特にやってない

Q. 可用性について、性能面で意識したこと

A.

まず、前提としてメルカリはレイテンシについてはあんまり考えない方針。レイテンシはモノリシックにしたら早くなるに決まっているから。

ただ、共通基盤は全サービスが利用するから早くする必要がある。だからmemcachedとかでローカルで完結するようにしたりはしてる。

Q. SDKの更新はどうやっている

A. @here ですｗ 配布先に展開が必要… まさに今問題になっていますｗ

Q. SDKの更新は サイドカー とか Istio でやらない？

A. 今後やっていきたいです

Q. トークンの有効期限

A.

ものすごく短い。リフレッシュもできない。

1リクエストが10分かかるわけもないという判断軸で期限を決めている。

Q. 外部と内部のマッピングなどの手作業が必要になるところはどこがある

A.

SubjectID はアカウントの種類が増えると増やさないといけないが、アカウントの種類はそんなに増えないと思っているので、その都度増やす対応を取る。

他にマスターデータも手作業が必要である。今はは手作業でやっていてしんどいので自動化していきたい。

Q. あるサービスから他のサービスにバッチ処理することはあるか

A.

あります。バッチ処理のときも内部トークンを使う。

内部トークンは Authority Service から生成する仕組みがある。

（各サービスが秘密鍵をもっていて、それを使うと生成できる。その秘密鍵にスコープは現在ない。今後つけたい）

Q. 外部スコープと内部スコープのマッピングにクライアント情報を足せば、各マイクロサービス間で認証する必要がなさそう。（＝Authority Serviceだけで認証が完結できそう）

A.

反対です。それは各マイクロサービスが絶対に安全であるという前提でやっているから。

各Serviceが自分が受けていいものかを判断する。どんなリクエストが来るかはわからない。

Q. 一番厳しいユースケースは？（今後認証基盤の大変そうなところ）

A.

内部トークンの寿命が短いので、pub/subといった非同期通信に対応できない。解決策はまだない。

バッチ処理は各サービスが Authority Service にトークンを作りに行くようにしている。（それでしのいでいる）

---

ここでようやくパネルディスカッションです。

話題はひとつだけですがｗ

Q. 苦労話

A.

• @pospome さん

  内部通信における問題を考えるということがしんどい。

  PO的なこともやっているので、いろいろやらないといけなくてさらにしんどい。

• @kazegusuri さん

  Authority Service の複雑な考え方が社内に受け入れられるか不安だった。

  しかし、ちゃんと受け入れてもらえてよかったー。

  @pospome さんと @nerocrux さんがよくやってくれたおかげ。

• @nerocrux さん

  フルタイムで手を動かせるエンジニアが4人だけでつらい。

  認可サーバのユースケースはよく変わるからつらい。