「認証認可」という体験をデザインする ～Nekko Cloud認証認可基盤計画

2024/9/15 情報科学若手の会にて発表した際の資料です。
サークル内で開発・運用しているプライベートクラウド基盤において、認証認可基盤の要件定義と設計をした話をまとめています。

Transcript

1. 「認証認可」という 体験をデザインする ～Nekko Cloud 認証認可基盤計画 logica 𝕏: @logica0419 GitHub: @logica0419
2. 自己紹介 • logica (ろじか) • 千葉工業大学 情報科学部 情報ネットワーク学科 3年 • ネットワークコンテンツ研究会 (サークル) 所属 ◦ Nekko Cloudチームのソフトウェア担当 • セキュキャンだったり、ICTSCだったり、 Goだったり、Kubernetesだったり… 色んな界隈にいます
3. Nekko Cloudチーム
4. 「メンバーの自宅サーバーVPNで 繋いで、プライベートクラウド 作ろう！」っていうチーム 自称「マルチリージョンプライベートクラウド」
5. ネッコ研が誇る逸般の誤家庭たち
6. ネッコ研が誇る逸般の誤家庭たち 浦和
7. ネッコ研が誇る逸般の誤家庭たち 津田沼
8. ネッコ研が誇る逸般の誤家庭たち 幕張
9. これらの”リージョン”を… 浦和 津田沼 幕張
10. VPNで繋げてしまえ！ 浦和 津田沼 幕張
11. 論理構成イメージ
12. これまでとこれから • これまでできたこと ◦ VPNで各拠点を繋ぐ ◦ Proxmoxでクラスタリングし、IaaSを構築する • これからやりたいこと ◦ 共通認証認可基盤を作る ◦ K8sクラスタを建てて、アプリをデプロイできる プラットフォームを整える などなど…
13. これまでとこれから • これまでできたこと ◦ VPNで各拠点を繋ぐ ◦ Proxmoxでクラスタリングし、IaaSを構築する • これからやりたいこと ◦ 共通認証認可基盤を作る ←今日はこれの話です ◦ K8sクラスタを建てて、アプリをデプロイできる プラットフォームを整える などなど…
14. 一般的な認証認可
15. 認証と認可 • 認証 - Authentication ◦ アクセスしているユーザが誰なのかを判別 ◦ 情報漏洩すると非常にマズい • 認可 - Authorization ◦ 誰にどの操作を許可するのかを判別 ◦ 変更されなければ、実際の影響はない • この二つはセットにすると扱いやすいので、まとめて 「認証認可」と呼ばれる
16. 認証情報、 自前で持つか？ 外部で持つか？ 認証の形について、少し整理しておく
17. 自前で持つ型 • パスワード / Passkey / 電話番号認証 など • 認証情報の取扱いにかなり気を付けなければいけない • アカウントが増えてめんどくさい、という印象が多い
18. 外部で持つ型 • OIDC (OAuth2) / IDaaS など • 「自前で持つ型」を認証基盤が行い、受け渡す • 知識が必要だったり、コードを書く量が増えたりで辛い
19. 認証手法の良し悪し • 自前型 ◦ 良: 独自の手法が使える / 実装が比較的楽 ◦ 悪: 脆弱な実装が生まれやすい • 外部型 ◦ 良: 比較的安全 / ユーザーの機密情報が増えない ◦ 悪: 難しい / 実装がめんどくさい • 昨今Web界隈では「外部型に寄せよう！」という動きが 高まっている ような気がする
20. 主な認可手法 • ユーザー紐づけ ◦ それぞれのユーザーに権限を紐づける ◦ 簡単だが、ユーザー・権限が増えると管理が大変 • RBAC (Role Based Access Control) ◦ 最近の認可手法のデファクトスタンダード ◦ ユーザー - ロール - 権限 という風に紐づける ◦ ロールで権限を束ねることで、わかりやすくなる
21. RBACの例: AWS IAM Image by: AWS Document ユーザー ロール with 権限 実際に触るリソース
22. 認証・認可情報を伝播させる技術 • OAuth2 ◦ 認可情報を伝える手段 ◦ 一定のAPIを叩く権限のあるアクセストークンを発行 • OIDC ◦ OAuth2を拡張した、認証情報を伝える手段 ◦ 認証情報に加え、拡張フィールドでロールなども 伝播できる
23. 様々な技術をいい感じに組み 合わせて、認証認可の技術は 成り立っています！ 以上が前提知識で、ここからが本題
24. Nekko Cloudで求められる要件
25. これまでとこれから • これまでできたこと ◦ VPNで各拠点を繋ぐ ◦ Proxmoxでクラスタリングし、IaaSを構築する • これからやりたいこと ◦ 共通認証認可基盤を作る ◦ K8sクラスタを建てて、アプリをデプロイできる プラットフォームを整える などなど…
26. 認証の要件 • Nekko Cloud内のアプリケーションエコシステムに、 共通認証基盤が欲しい ◦ IaaS / Kubernetes基盤 / 部内Wiki / VPN などなど… ◦ これらを1つのアカウントで済ませたい ◦ 逆に、それ以外のところに使う予定はない • 自分たちで認証情報を管理したくない ◦ 「外部で持つ型」の認証はほぼ確定
27. 認可の要件 • どのメンバーがどのアプリケーションを使えるかを コントロールしたい ◦ アプリケーションの中での権限については、 「admin」か「user」かくらいしか存在しない • アプリケーション側に複雑なロジックを実装したくない ◦ アプリケーション側で権限管理をしたくない ◦ 外付けの認可基盤で管理できればBest
28. 肥大化・分散する認可情報 • 認可情報は、肥大化する傾向にある ◦ IAMとか、全部分かってる人いない • 認可情報は、分散していく傾向にある ◦ 認証情報はOIDC等でそのまま伝播できるが、 認可情報はそれぞれのアプリケーションが持つ ◦ OIDCでも伝播できるのはせいぜいロール程度で、 ロールを元に権限を割り振るのはそれぞれのアプリ • これが汎用的な基盤の限界
29. プラットフォームとしての要件 • できるだけアプリケーションにロジックを入れたくない ◦ 今後みんながアプリケーションを作りやすくする ために、複雑性の隠蔽をしたい ◦ 既存OSSの場合はOIDCの設定 / 自作アプリなら プロキシで認証できると良い (後述) • Kubernetesをアプリケーションデプロイ基盤として 用いるので、それに即した形にしたい
30. 2つのソリューションを発案した 1. Kikkoff: ネッコ研 共通認証認可基盤 2. Sidauth: K8s上のhttpプロキシ型認証システム
31. Kikkoff: ネッコ研 共通認証認可基盤
32. サークルの環境と認証手法 • 部内の全ての人が、Discordサーバーにいる ◦ Discordサーバーに所属していれば、サークル員 • DiscordのOAuthで直接認証するという案が出たが、 以下の問題があった ◦ 認可処理が面倒 (Discordのロールを使うのは厳しい) ◦ OAuthしかないので、OIDCにするためには何かしら のソフトウェアを挟む必要がある
33. Discordで認証するポータルに OIDC Providerの機能を持たせ 認証を「プロキシ」する！ 小規模クラウドだからこそ絞れる要件を、最大限絞った結果
34. Kikkoff • メンバーポータル 兼 OIDC Provider • メンバーポータルとして ◦ Discordのみで認証する ◦ ロール付け等、独立したメンバー管理機構 • OIDC Providerとして ◦ 部内アプリケーションの認証手法を統一する ◦ Clientにロールを紐づけ、Provider主体でアプリへ のアクセス認可をする
35. 認証の「プロキシ」イメージ • これによって、 ◦ Discordの認証でありながら ◦ OIDCを使った認証情報の伝播ができる！
36. Provider主体の、単純化された認可
37. Provider主体の、単純化された認可 Providerがアクセスを切る (認証情報を渡さない)
38. メンバーのライフサイクル管理 • Kikkoffのメンバー状態 (在籍・ロールなど) を正と して、DiscordやGitHubのメンバーに逆に同期すると いうアイデア ◦ Discord / GitHubのロール自動管理 ◦ 長期間アクセスの無い部員を自動でキック ◦ Kikkoffに登録すると、自動で各種サービスに招待 ▪ サークルのキックオフを補助する (名前の由来)
39. Sidauth: K8s上のhttpプロキシ型認証システム
40. 直接認証とプロキシ型認証 • 直接認証 ◦ アプリケーションが直接認証する ◦ 認証情報はアプリケーションが持つ • プロキシ型認証 ◦ リバースプロキシが認証し、アプリに伝達 ◦ アプリは認証情報を持たず、ヘッダ等で受け取る • 複雑性をアプリから切り離したい = プロキシ型が適する
41. Kubernetesにおけるプロキシ型認証
42. Kubernetesにおけるプロキシ型認証
43. Ingress Controllerによる認証の問題点 • Ingress Controllerに実装が依存する ◦ 認証を実装していないIngress Controllerが存在 ◦ 新しい規格であるGateway APIでも状況は同じ • アプリケーションと認証システムのライフサイクルが 一致しない ◦ 認証システムが落ちたらアプリにアクセスできない ◦ Ingress Controller内包だったらまだいいが、外付け だと顕著に弱さが出る
44. アプリケーションPodの Sidecar Containerとして 認証システムをInjectする 「自分のことは自分でやれ」型の認証システム
45. Ingress Controller主体
46. Sidecar主体
47. Sidecar型認証の利点 • Ingress Controllerに実装が依存しない ◦ アプリケーションPod単体で認証ができる！ ◦ 認証が無いIngress ControllerでもOK • アプリケーションと認証システムのライフサイクルが 完全に一致する ◦ アプリケーションと一心同体！ ◦ 最近K8sでSidecarが改善されたので、いい感じに 実装できそう
48. Sidauth: Sidecar型認証Operator • CRD: AuthService ◦ Serviceの代わりに使用 ◦ Serviceの設定と、認証設定を包含する • Sidauth Operator ◦ AuthServiceを受け取って、以下を生成する ▪ 対象のPod群へのSidecar Injection ▪ Injectしたコンテナへ向けたService
49. アイデア自体は転がっていたが CRDとOperatorまで 作っている人はいなかった 結構面白いプロダクトにできるのでは…？と思っている
50. まとめ / 今後の展望
51. 認証認可の選択肢は 1つではないと思うが、 我々はこれでやってみたい ユースケースに合わせて適切に設計していきたいですね
52. 実際の開発と未踏事業への挑戦 • まだ開発は開始していない ◦ Nekko Cloudのみんなで頑張って開発していく • 今回紹介した認証認可基盤と、Kubernetesベースの IaaSを設計し、「Kubernetesをベースとした、軽量な 小規模クラウド基盤」として未踏に挑戦してみたい ◦ 事前開発や開発ペースなど、未踏人材の皆さんに アドバイスいただけたら嬉しいです！
53. ありがとうございました 良き認証認可ライフを！