既存RailsアプリをSSO化して、本番環境で活用した話【WESEEK Tech Conf #12】

既存RailsアプリをSSO化して
本番環境で活用した話
WESEEK Tech Conference #12

#WESEEK_tech
会社概要
株式会社WESEEK
所在地
● 本社：〒169-0051東京都新宿区西早稲田2-20-15高田馬場アクセス10F
● サテライトオフィス：〒874-0838大分県別府市荘園9-1 ルーデンス荘園305
Lead with the web
-Webで未来をリードする-
2

#WESEEK_tech
現在の主な事業
1. 通信大手企業の業務フロー自動化プロジェクト
2. ソーシャルゲームの受託開発
3. 自社発オープンソースプロダクト「GROWI」「GROWI.cloud」の開発
3

#WESEEK_tech
GROWIとは
4
快適な情報共有を、全ての人へ
● OSSとして公開している情報共有ツール(ナレッジベース)
● エンジニアに馴染みのあるMarkdown形式で記述可能
● 柔軟な階層構造での情報管理が可能

#WESEEK_tech
GROWI.cloudとは
情報共有をもっと身近に、もっと手軽に
● OSSであるGROWIを専門的知識がなくても簡単に運用・管理できる、
法人・個人向けの商用サービス
● エンタープライズプランの導入事例
○ インターネットマルチフィード株式会社様
○ 株式会社エイチーム様
○ 株式会社HIKKY(VR法人HIKKY)様
5

#WESEEK_tech
質問の受付方法について
● Zoomのチャット機能で、発表中も随時質問を受け付けます
○ メッセージの送信先設定は「全員」で！
● 発表終了後に10分程度、質疑応答の時間を設けています
6

ハッシュタグ
【 #WESEEK_tech 】
7

既存Railsアプリを
SSO化して
本番環境で活用した話
9

#WESEEK_tech
自己紹介
大谷津昂季
Koki Oyatsu
10
2014年にWESEEKに入社
WESEEK ではサーバサイド(主に RoR) とイン
フラエンジニアを担当しています。
自分が「欲しい！」と思うものを、
まったりと OSS で個人開発しています。
業務
趣味
@kaishuu0123

#WESEEK_tech
自己紹介
今間俊介
Syunsuke Komma
11
2013年にWESEEKに入社
Rails/Kubernetes を中心としたインフラ/アプ
リの設計・構築・運用に携わる。
Cloud Native/Kubernetes 関連の
OSS 探求/ドキュメント読み漁り
業務
趣味
@gutalla

#WESEEK_tech
今日お話しすること
1. インターネットマルチフィード様紹介
2. OpenID Connect に対応した認証基盤を構築した話
○ モチベーション
○ 技術検討アレコレ
○ システム構成
○ 対応後の活用例
3. OpenID Connect 基盤で複数のバックエンドの認証、認可を統一した話
○ モチベーション
○ 技術検討
○ 完成後構成のご紹介
12

インターネットマルチフィード様
紹介
13

#WESEEK_tech
インターネットマルチフィード(株)とは？
14
IXP: Internet eXchange Provider VNE: Virtual Network Enabler
ネットワークな会社です
Public NTPサーバーも提供しています
ntp1.jst.mfeed.ad.jp とか

#WESEEK_tech
WESEEK との関係(1/2)
● WESEEK はインフラ～アプリのフロントエンド開発までワンストップで提供
できる
● 社内の様々な問題の解決・改善のために弊社武井へ相談
○ 内製開発だけでは解決できない課題があった
● 2015年 WESEEKとの共同プロジェクトを開始
○ そこから 6 年以上経て、現在へ
15

#WESEEK_tech
WESEEK との関係(2/2)
● インターネットマルチフィード様と WESEEK との開発について
詳しく知りたい方は過去の WESEEK Tech Conf (#8)の資料があります
○ https://techplay.jp/event/823418
16

17
OpenID Connect に対応した認証基盤を構築した話
実現したこと

#WESEEK_tech
実現したこと
18
OpenID Connect に対応した
認証基盤を構築した話
● 社内システム(Rails 製)のアカウント情報を利用して、
ユーザ向けの複数サイトにて、共通 IDでログイン可能に(SSO)

#WESEEK_tech
SSO(Single Sign On とは?)
1つの ID とパスワードで複数のサービスにログインする仕組み
19
引用: https://teams.qiita.com/news/sso/

20
モチベーション

#WESEEK_tech
モチベーション(1/3)
● nautilus という JPNAP 業務の中枢を担う社内システムを開発していた
○ MF, WESEEK が協力して作った内製システム
○ 顧客情報(顧客名、会社名 etc)の他に機器管理も担う
● nautilus で取り扱っている情報を顧客向けに公開したい
○ 連絡先メールアドレス、会社名
○ 現在契約している回線
○ etc …
● JPNAP ポータルサイト(My.JPNAP) の発足
21

#WESEEK_tech
My.JPNAP
22

#WESEEK_tech
● 「ポータル以外に顧客向けのドキュメントを公開する場所とか欲しいよね」
● 「ポータルサイト以外にも認証認可の機構を入れたいよね」
23
①サイトごとに認証の
ロジックを実装する？
④サイトが今よりも
増える場合は？
⑤社内システムは絶賛
稼働中で停止しづらい
⑥新しい仕組みを導入するに
しても、社内システムにアカ
ウントがすでにあるし …
(移行コスト)
②ユーザ増えたら
都度都度、各サイトに
アカウント追加するの？
③認可はどうする？
(ユーザ A はサイト A は見
えて、サイト B は見えな
い)

#WESEEK_tech
1. サイトごとに認証のロジックを実装する？
2. ユーザが増えたら都度都度、各サイトにアカウントを追加するの？
3. 認可はどうする？
4. サイトが今より増える場合は？
=> 認証と認可の一元管理 (SSO+α)
5. 社内システムは絶賛稼働中で停止しづらい
=> なるべく社内システムを現行から落とさないように
6. 新しい仕組みを導入するにしても、社内システムにアカウントがすでにある
し …
=> 既存アカウントを活用する
24

25
技術検討

#WESEEK_tech
技術検討の流れ
26
1. 前提条件の確認
2. プロトコルの検討
3. ソリューション検討
4. 導入

#WESEEK_tech
技術検討(前提条件の確認)
● 社内システム(nautilus) には社員などのアカウント情報がすでにある
○ メールアドレス、パスワード
● SSO を実現するには汎用的な技術を使いたい
○ OpenID Connect、SAML、etc …
● 社内システムのアカウント情報を別システムに移すのは大変
○ 移行手順、停止期間、SPoF ...
27

#WESEEK_tech
28
4. 導入

#WESEEK_tech
技術検討(プロトコルの検討)
● SAML
○ メリット
■ 枯れている
■ 柔軟な認可管理が可能
○ デメリット
■ ネットの情報源が少ない
■ 認可における制御が複雑 (そうに見えた)
● OpenID Connect
○ メリット
■ ネットの情報源が(比較的)豊富
○ デメリット
■ 認可に関する情報が少ない
■ SAML ほどの柔軟性は (おそらく) ない
29

#WESEEK_tech
技術検討(OpenID Connect とは？)
● OpenID Connect 1.0 is a simple identity layer on top of the OAuth
2.0 protocol.
○ OAuth 2.0 プロトコルに identity の概念を足したもの
○ https://openid.net/connect/
● OAuth 2.0 の身近な例
○ Google, Twitter, GitHub、Facebook などでの認証(正: 認可)
30

#WESEEK_tech
技術検討(「OAuth 認証」について)
● OAuth 2.0 では User ID の取得方法など「ユーザを識別する規定はない」
○ 「でも、認証っぽいこと(ユーザ識別)できてるじゃん？」
● あくまで Google、Twitter など各社が独自で実装しているもの
○ プロフィール API というもので個人を識別
31

#WESEEK_tech
技術検討(OAuth と OIDC の比較)
32
参考: OAuth認証とは何か?なぜダメなのか - 2020冬
OAuth 2.0 OIDC

#WESEEK_tech
33
4. 導入

#WESEEK_tech
技術検討(実装の検討)
● 自前実装
○ OpenID Connect を実装するのは比較的容易だが、
セキュリティ部分の実装は怖い
● OSS を利用する
○ Keycloak
■ 認証情報を LDAP などに Proxy してくれるが、今回の要件には多機能だった
(WESEEK では GROWI.cloud で技術検証済み)
○ Hydra(ハイドラ)
■ 既存の認証リソースを活用して OpenID Connect 対応にさせる OSS
34

35
Hydra の紹介

#WESEEK_tech
Hydra の紹介
● ORY 社が開発している OAuth 2.0 and OIDC Certified® Server
○ https://www.ory.sh/hydra/
○ 利用言語: Go 言語
● Hydra がやってくれること
○ Hydra と既存ソフトが協調することで
OpenID Connect プロトコルを代理で話してくれる (間のやりとりはHTTP)
● Hydra がやってくれないこと(#Limitations)
○ ユーザアカウントの管理
■ ユーザ登録、パスワードリセット etc
○ etc
36

#WESEEK_tech
システム構成(導入前)
● nautilus とポータルが API で直に通信する構成
○ 点線部分は SSO に対応させたいサイト
37

#WESEEK_tech
システム構成(導入後)
38
nautilus の前段に
Hydra が挟まる構成

#WESEEK_tech
ログインの流れをもう少し詳しく
39
参考:
https://www.ory.sh/hydra/docs/
concepts/login
ポータルサイト
nautilus
(社内システム)

#WESEEK_tech
[再掲] モチベーション(3/3)
1. サイトごとに認証のロジックを実装する？
2. ユーザが増えたら都度都度、各サイトにアカウントを追加するの？
3. 認可はどうする？
4. サイトが今より増える場合は？
=> ✔ 一元管理 (SSO)
5. 社内システムは絶賛稼働中で停止しづらい
=> ✔ なるべく社内システムを現行から落とさないように
6. 新しい仕組みを導入するにしても、社内システムにアカウントがすでにある
し …
=> ✔ 既存アカウントを活用する
40

#WESEEK_tech
Rails アプリ側で追加実装した箇所
● ログイン用の画面
● Hydra とやり取りするための API
○ 認証用
○ Consent (同意) 用
○ ログアウト用
● 社内システム側で受け取った Token
が正しいかどうかを検証する箇所
41

#WESEEK_tech
苦労したポイント
● Rails で利用していた devise gem とセッションの関係
○ Hydra がセッション相当を管理してくれるので、
Hydra でのエンドポイントでは devise gem のセッションを無効化するケアが必要
○ 認証フローの複雑化
○ 「社内からのアクセスは devise のセッションを使って、ユーザ向けは無効化して ...」
● 多要素認証(2FA)機能の実装
○ Hydra 単体では 2FA はサポートされていない
○ 2FA 用のセッションを適切にハンドリングする必要がある
○ 「Rails で 2FA 機能を実装して、2FA 用の Cookie は送るようにして ...」
42

#WESEEK_tech
SSO 対応後の活用例
● oauth2-proxy を使ったスタティックなサイトを SSO 対応にした
○ https://github.com/oauth2-proxy/oauth2-proxy
○ 我々が直接コードを触れない OSS でも SSO 対応に
● OpenID Connect 対応になったので、インフラ側の技術検討が促進された
○ この後ご紹介
43

#WESEEK_tech
[再掲] システム構成(導入後)
44

#WESEEK_tech
まとめ
1. 既存の業務システムの認証データと Hydra を活用することによって
OpenID Connect に対応することができ、SSO を実現できた
○ 既存リソースの有効活用
2. OpenID Connect 対応になったことによって、インフラ側でも
OpenID Connect を前提とした技術検討ができるようになった
45
OpenID Connect 基盤で複数のバックエンドの認証、認可を統一した話へ

46
OpenID Connect 基盤で複数のバックエンドの認証、認可を統一した話
実現したこと

#WESEEK_tech
実現したこと
1. 認証認可部分の実装をサービスの外に出し、共通化した
1. どのようなサービスに対しても、OIDC 基盤と nautilus 上にあるユーザ・
権限情報を利用して、認証認可を追加できるようになった
47
OIDC 基盤で複数のバックエンドの
認証、認可を統一した話

#WESEEK_tech
実現したこと(構成図)
48

49
モチベーション

#WESEEK_tech
● JPNAP ポータルサイト(My.JPNAP) は発足した
○ nautilus というバックエンド 1 つの状態
● nautilus 以外で提供している情報も顧客向けに公開したい(追加要件)
○ nautilus = My.JPNAP backend
○ トラフィックグラフ
○ 実際に顧客向けインターフェースで流れているトラフィック量
○ Looking Glass
○ etc…
● 別のサービスに対しても同じ枠組みで認証/認可の仕組みを入れたい！
50

#WESEEK_tech
● 前段に oauth2-proxy を導入することで、既存のサービスに手をいれずに
SSO 認証基盤を利用した認証は可能になった
● 認可は？
○ nautilus ではアプリ内に自前で認可ロジックを入れて、リクエストが来たときにチェッ
クするようにしていた
○ それ以外のサービスの場合、oauth2-proxy だけでは高度な認可は実現できない
○ チェック対象のサービスによらず、URL ごとに必要な権限のチェックができるようにし
たい
● どうやって実現するか？
51

#WESEEK_tech
技術検討へ
● 考えることの量が多かったため、以下の二部に分けて説明します
○ 構成編
○ 認可手法編
52

53
技術検討(構成編)

#WESEEK_tech
技術検討(構成編/前提条件の確認)
● nautilus が権限情報を持っている
○ どの契約情報に対して、どういう操作を許可するのか
● 既にあるサービスに手を入れる形にはしたくない
○ 面倒見なければいけないコード量を増やしたくない
■ 違う言語/FW を使ってるアプリだと、増えるのはコード量だけではない
○ OSS だったら拡張して、自前バージョンを作り、保守する必要がある…
● 稼働環境は Kubernetes を利用している
● サービスにリクエストが到達する前に認可できるようにできないか？
54

#WESEEK_tech
● 構成イメージ(導入前)
55

#WESEEK_tech
● 構成イメージ(導入後の理想像/認可ロジックはまだ不明)
56
認
可
ロ
ジ
ッ
ク
認
可
ロ
ジ
ッ
ク
認
可
ロ
ジ
ッ
ク

#WESEEK_tech
技術検討(課題まとめ)
1. 認可ロジックだけをどうやって抜き出してサービス前段で実行するのか
○ 利用者からのリクエストは HTTP なので、前段にリバースプロキシを入れる？
2. プロキシにどの実装を使うのか
3. プロキシの設定をどうやって管理/反映するのか
4. 認可ロジックを何で実装するか
5. 認可情報をサービスへどうやって渡すのか
57

#WESEEK_tech
技術検討(課題まとめ)
○ 利用者からのリクエストは HTTP なので、前段にリバースプロキシを入れる
58
構成編では、1.～3. を対象に考えます。
4./5. については後述します。

#WESEEK_tech
技術検討(構成編/手法検討)
1. サービスメッシュを導入する
○ メッシュのプロキシに認可レイヤーを持たせる
■ 既に Kubernetes を利用していたため、Istio がチーム内で知られていた
○ ただ、認可のレイヤーを追加するだけでは too much 感？
2. サービスの前にプロキシを自前で立てる
○ プロキシ実装の選択、設定などを自分で考え、管理・運用する必要がある
■ 認可対象のサービスごとに異なる設定以外も管理・運用する必要がある
■ どういう構成で動かすのか、どういう設定にするか
○ 考えなければいけないことが多い
59

#WESEEK_tech
技術検討(構成編/手法検討)
1. サービスメッシュを導入する
○ メッシュのプロキシに認可レイヤーを持たせる
■ My.JPNAP 稼働環境では既に Kubernetes を利用していたため、Istio がチーム
内で知られていた
○ ただ、認可のレイヤーを追加するだけでは too much 感？
2. サービスの前にプロキシを自前で立てる
○ プロキシ実装の選択、設定などを自分で考え、管理・運用する必要がある
■ 認可対象のサービスごとに異なる設定以外も管理・運用する必要がある
■ どういう構成で動かすのか、どういう設定にするか
○ 考えなければいけないことが多い
60
チームで検討した結果、技術的に面白そう、要件を満たせそう、
という点から 1. を選択することに

61
サービスメッシュ/Istio とは？

#WESEEK_tech
サービスメッシュとは？
● サービスメッシュを採用する利点
○ サービスへの通信に関する設定・実装を、アプリの実装から切り離せる
○ サービス間通信の任意の場所に、処理を差し込むことが可能
■ 今回のケースだと、認可処理をサービスメッシュで差し込むことができる
■ サービス側に個別に認可ロジックを用意する必要がなくなる
● サービスメッシュを利用しない場合
○ 必要な通信機能を、各サービスでそれぞれの言語で実装していかなければならない
○ たとえ実装言語、ライブラリなどを統一したとしても、各サービスごとに保守するコー
ド量は増える
62

#WESEEK_tech
サービスメッシュとは？
● 各サービス間の通信で共通で必要となる部分を切り出して、共通の設定とし
て管理できるようにする仕組み
63
ref: https://www.redhat.com/ja/topics/microservices/what-is-a-service-mesh

#WESEEK_tech
Istio とは？
● Kubernetes 上でサービスメッシュを実現するための 1 実装
○ https://istio.io
● Sidecar proxy として Envoy を採用
○ 今回認可を共通化するために利用した External Authorization Filter(ext_authz) も
Envoy の一機能
● メッシュ内の設定は全て Kubernetes 上のリソースとして管理される
○ 他のリソースと同様に YAML として管理可能
○ 既に My.JPNAP では Git リポジトリでリソースを
管理していたため都合がよい
64

#WESEEK_tech
[再掲] 技術検討(課題まとめ)
65

#WESEEK_tech
○ Istio なら各 Pod に sidecar として Envoy が入ってくれる
○ Envoy だったら External Authorization Filter を差し込んで実行できそう
○ Istio は Envoy 一択
○ Istio の Custom Resources で、他の Kubernetes リソースとともに yaml で管
理できる
66

#WESEEK_tech
[再掲] 技術検討(構成編/前提条件の確認)
67
認
可
ロ
ジ
ッ
ク
認
可
ロ
ジ
ッ
ク
認
可
ロ
ジ
ッ
ク

#WESEEK_tech
● 構成イメージ(Istio 導入後の理想像/認可ロジックはまだ不明)
技術検討(構成編/結果)
68
認可ロ
ジック
認可ロ
ジック
認可ロ
ジック

69
技術検討(認可手法編)

#WESEEK_tech
70

#WESEEK_tech
技術検討(認可手法編/前提条件の確認)
● 構成は決まったが、実際の認可ロジックはどうやって実装する？
○ Istio(Envoy) に対象となるサービスにリクエストを送る前に、外部のサービスに問い合
わせて許可/拒否するモジュールはあった(External Authorization Filter)
○ 認可ロジックを実装する外部のサービス部分をどうするか考える必要がある
● 認可ロジック実装で、考える必要があった事柄
○ クライアントが送ってきた token の検証方法
○ 認可ロジックの実装方法、利用実装
○ リクエストしてきた人のログイン情報をサービスに渡す方法
● 自前実装は増やしたくない
71

#WESEEK_tech
技術検討(認可手法編/token 検証)
● クライアントが送ってきた access token の検証方法
○ ORY Oathkeeper を利用することに
○ 検証には OAuth2.0 Token Introspection(RFC7662) を使う
■ Hydra/Oathkeeper は実装を持っている
● Oathkeeper とは？
○ Hydra と同じく ORY 社が開発している Identity and Access Proxy
■ https://www.ory.sh/oathkeeper/
○ Reverse-proxy モード以外にも、HTTP リクエストを通す/通さないの判定をしてくれ
る API が備わっている
■ authenticator(認証)、authorizer(認可)など、フェーズごとに設定できる
○ URL ごとにどのような認証認可を行うかを JSON or YAML で書いておく
○ Envoy との連携もサポート
72

#WESEEK_tech
技術検討(認可手法編/token 検証)
● Oathkeeper の設定サンプル
73
- id: request-authorization-to-status-api
version: v0.38.3-beta.1
match:
url: <https|http>://status.example.com/api/v1/<.*>
methods:
- GET
- POST
- PATCH
- PUT
- DELETE
authenticators:
- handler: oauth2_introspection
authorizer:
handler: allow
mutators:
- handler: id_token
errors:
- handler: json
別途エンドポイントの設定は必要だが、こ
の設定だけで HTTP リクエスト内の token
を検証できる

#WESEEK_tech
技術検討(認可手法編/認可ロジック)
● 認証ロジックの実装方法、利用実装
○ Oathkeeper にも authorizer の設定はあるが、外部サービスに検証を依頼するのが主
で Oathkeeper それ自体ではロジックの定義は不可能
○ OPA を利用することに
● OPA とは？
○ Policy-based control for cloud native environments
■ https://www.openpolicyagent.org/
○ rego という軽量言語にロジックを記載していく
■ JSON を入力値として、rule という単位で条件に当てはまる/当てはまらないを書
いていく(Policy as Code)
○ Istio との連携もサポート
■ https://github.com/open-policy-agent/opa-envoy-
plugin/tree/main/examples/istio
74

#WESEEK_tech
技術検討(認可手法編/認可ロジック)
● rego サンプル
75
# envoyから渡されるhttp_requestそのままではほしいデータのキーのが深すぎるため
# ショートネームでアクセス出来るようにしている
import input.attributes.request.http as http_request
# ルールのデフォルト値
default allow = false
(snip)
# GET /api/v4/user_groups/:user_groups_id/user_groups/:id
allow {
some user_group_id, ug_id
http_request.method == "GET"
input.parsed_path = ["api", "v4", "user_groups", user_group_id, "user_groups", ug_id]
is_token_valid
ABILITY_MANAGE_USER_GROUP == nautilus_authz_data(user_group_id, MODEL_UG, ug_id)["abilities"][_]
}
input に HTTP リクエストに関する情報が
入ってくるので、それを基にメソッド、
URL 等の情報から条件を書いていく

#WESEEK_tech
技術検討(認証認可編/情報の受け渡し)
● リクエストしてきた人のログイン情報をOPA/サービスに渡す方法
○ Oathkeeper の mutator(変換機能) を使い、JWT ID Token を生成し渡すことに
○ サービスは JWT の中身からリクエストしてきた利用者の情報を拾える
○ また JWT には署名機能もついているため、検証を行うことで無効な JWT を拒否するこ
ともできる
● OPA は JWT のデコード/検証に built-in で対応している
● サービス側でログイン情報を拾う場合は、JWT のデコード/検証ロジックの
実装だけ
○ どんな言語でも非常に薄い実装になる！
○ 認可はサービスに到達する前に実施済みなので、考慮不要！
76

#WESEEK_tech
77

#WESEEK_tech
○ Oathkeeper と OPA を組み合わせて利用する
○ Oathkeeper では access token の検証、OPA で URL ごとに認可ルールを書いて
いく
○ Oathkeeper で JWT を発行して、認可情報を渡す形で実現した
78

79
完成構成

#WESEEK_tech
[再掲] 技術検討(構成編/前提条件の確認)
80
認
可
ロ
ジ
ッ
ク
認
可
ロ
ジ
ッ
ク
認
可
ロ
ジ
ッ
ク

#WESEEK_tech
完成構成(全体)
81

#WESEEK_tech
完成構成(全体)
82
Authorization: Bearer XXX
(hydra が発行した access token)
Authorization: Bearer YYY.ZZZ
(oathkeeper が発行した JWT)
Authorization: Bearer YYY.ZZZ
(oathkeeper が発行した JWT)
Authorization: Bearer XXX
(hydra が発行した access token)
hydra への access token 検証、
JWT への変換を行う
JWT から認可情報を拾い、nautilus
に対して当該ユーザの権限を問い合
わせ、許可/拒否を返す

#WESEEK_tech
サービスで追加実装した箇所
● OPA 向けにユーザが持っている権限を返すエンドポイント(nautilus)
○ OPA で認可チェックをする際に実行される
○ リクエストされるパスごとに、必要となる権限が異なる
○ OPA 側では、本エンドポイントを叩いて、必要な権限がある場合は許可、ない場合は拒
否するようなロジックを書いている
● JWT を検証/JWT からリクエストユーザの情報を取り出す middleware
○ 返すデータをサービス側で制御するケースで利用される
■ ex.) 契約一覧などの index action など
83

#WESEEK_tech
苦労したポイント(1/2)
● 上手く動かない時に、見ないといけないログが多かった
○ いろいろなソフトを一度に増やしたため、1 つの HTTP リクエストの認可の結果を見る
にも、それぞれのソフトのログを一度に見る必要があった
○ (tmux でペインを開いて複数のコンテナを
stern しておく…)
84

#WESEEK_tech
苦労したポイント(2/2)
● Envoy ext_authz の設定を入れる Istio の設定を編み出すのが大変だった
○ ext_authz が Istio native でサポートされていないため、EnvoyFilter というリソー
スで設定を書かないといけなかった
○ EnvoyFilter は Istio が生成してくれる Envoy コンフィグ中の「どの箇所に」設定を
追加する、という書き方をする必要がある
○ 希望の場所にコンフィグを持ってくるための書き方を編み出すのに時間がかかった
■ 文字通りの挙動をしてくれなかったり…
■ ex.) INSERT_FIRST が動かない
85
configPatches:
- applyTo: HTTP_ROUTE
match: &config_patches_match
context: SIDECAR_INBOUND
routeConfiguration:
name: inbound|3050||
patch:
# どうやっても、INSERT_BEFORE/INSERT_FIRST で default route の前に値を入れられないので、
# 仕方なく、まず MERGE で default を書き換える
operation: MERGE
value:
decorator: &decorator
operation: gargant-app.gargant.svc.cluster.local:3050/*
match:
safe_regex:
google_re2: {}
regex: (/api/v[0-9]+)?/healthz
name: gargant_healthz
route: &route
cluster: inbound|3050||
maxGrpcTimeout: 0s
timeout: 0s
typed_per_filter_config: &disable_ext_authz
envoy.filters.http.ext_authz:
'@type': type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthzPerRoute
disabled: true

#WESEEK_tech
まとめ(1/2)
1. Istio を導入し、OPA/Oathkeeper をさらに組み合わせることで、認可を
サービスの外に出し、共通化できるようになった
○ 自前実装を増やすことなく、ほとんどの箇所を設定で管理できるようにできた
1. どのようなサービスに対しても、OIDC 基盤と nautilus 上にあるユーザ・
権限情報を利用して、認証認可を追加できるようになった
○ 新たな認可方式を実装する場合も、OPA/Oathkeeper で実現できれば、サービスに
タッチせずに実装可能になった
○ ex.) API token 機能(実装中)
86

#WESEEK_tech
まとめ(2/2)
● 今回ご紹介した構成
○ Kubernetes クラスタ上で複数のバックエンドを立ち上げて運用している人におすすめ
○ 構成要素、利用技術は多い
○ 一度うまく動けば、その後の転用・拡張は比較的容易
■ 構成要素の増加により、拡張ポイントが増える
■ 認証認可に関する自前実装も増えない
■ サービスメッシュにより、サービスにリクエストが到達する前に任意の処理を挟
めるようになる
87

#WESEEK_tech
お知らせ① 次回のWESEEK Tech Conf
89

イベントへのご参加ありがとうございました。
アンケートへのご協力をお願いいたします。
WESEEK Tech Conference #12

既存RailsアプリをSSO化して、本番環境で活用した話【WESEEK Tech Conf #12】

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a 既存RailsアプリをSSO化して、本番環境で活用した話【WESEEK Tech Conf #12】

Similar a 既存RailsアプリをSSO化して、本番環境で活用した話【WESEEK Tech Conf #12】 (20)

Más de WESEEKWESEEK

Más de WESEEKWESEEK (15)

既存RailsアプリをSSO化して、本番環境で活用した話【WESEEK Tech Conf #12】