Point of failure・運用負担の増加
● 各Microservicesが賢くなりすぎると保守が大変
● bug修正・仕様修正のたびに全体再デプロイ。最悪の場合は都度サービスメンテ
● 認証認可という根幹の部分の変更反映はなるべく数を減らしたい
→ Microservicesを賢くさせたくない
Slide 21
Slide 21 text
Microservicesを賢くさせたくない
Slide 22
Slide 22 text
API GatewayとSTSで解決しよう!
Slide 23
Slide 23 text
API Gateway
Slide 24
Slide 24 text
中央集権的GWによる責務のオフロード
● 外部認証プロバイダーとはAPI Gatewayでのみ通信
● MicroservicesからはFirebaseおよびCognitoの知識を完全に隠蔽
Microservice A
Microservice B
Microservice C
API Gateway
1. ユーザーアクセス
2. 署名検証
3. 検証済リクエスト
Slide 25
Slide 25 text
CONTOUR as API Gateway
● オープンソースのKubernetes向けingress controller (CNCF Incubating Project)
● 実装はEnvoyのwrapper → External Authorizationが設定できる
Slide 26
Slide 26 text
What is ExtAuthZ ?
● Envoyが提唱するEnvoy ↔ 外部認証サーバー間の通信プロトコル
● Envoyを通過するリクエストに対する中間処理を切り出せる
Contour + ExtAuthZを活用したArchitecture
● external_auth.protoを実装したAuthority Serviceを自前実装
● routing、流量調整、gRPC-Web変換等を行うContourと責務分離
Microservice A
Microservice B
Microservice C
1. ユーザーリクエスト
3. 署名検証
5. 検証済みリクエスト
Contour
Authority Service
2. ExtAuthZ 4. Success
Slide 30
Slide 30 text
Contour + ExtAuthZを活用したArchitecture
Microservice A
Microservice B
Microservice C
3. 署名検証
Contour
Authority Service
2. ExtAuthZ 5. Denied
4. 認証エラー
● エラーの場合はExtAuthZサーバー(Authority Service)からDenied Responseを返す
● Microservicesにはリクエストは到達しない
6. 認証エラー
1. ユーザーリクエスト
Slide 31
Slide 31 text
STS(Security Token Service)
Slide 32
Slide 32 text
Authority Service as Security Token Service
おさらい👇
● External Token(FirebaseとCognito)のJWT Payloadは型が異なる
● ExtAuthZサーバー(Authority Service)ではMetadataの上書きが可能
Slide 33
Slide 33 text
Authority ServiceをSTSとして活用しよう!
(署名検証 & 署名発行)
Slide 34
Slide 34 text
Authority Service as Security Token Service
● Authority ServiceでExternal Tokenを正規化して新たにInternal Tokenを
署名発行する → Token Exchangeと呼ばれる手法
Slide 35
Slide 35 text
Authority Service as Security Token Service
● Authority ServiceでExternal Tokenを正規化して新たにInternal Tokenを
署名発行する → Token Exchangeと呼ばれる手法
● What is Internal Token?
○ IssuerがAuthority ServiceのJWT
○ 内部通信でのみ利用
○ 正規化済みのPayload
○ 1リクエストごとに発行する
○ External Tokenよりも寿命が短い(expが短命な)JWT = 60秒
■ → 万が一の漏出に対する耐性
認可機構に求める要件
① 可読性
○ API Methodsの仔細まで読まなくても認可スコープを瞬時に把握でき
ること
② 記述性
○ 言語非依存・FW非依存・ドメイン非依存であること
= 個別のMicroservicesのドメイン知識が無くても容易に認可スコー
プを記述できること
③ 変更容易性
○ 全てのMicroservices repositoriesに修正を加えなくても安全に
Platform全体への認可スコープ追加/削除が行えること