Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
「認証認可」という体験をデザインする ~Nekko Cloud認証認可基盤計画
Search
logica
September 15, 2024
Technology
3
530
「認証認可」という体験をデザインする ~Nekko Cloud認証認可基盤計画
2024/9/15 情報科学若手の会にて発表した際の資料です。
サークル内で開発・運用しているプライベートクラウド基盤において、認証認可基盤の要件定義と設計をした話をまとめています。
logica
September 15, 2024
Tweet
Share
More Decks by logica
See All by logica
kube-vipとkube-proxy置き換えCiliumを積んだ究極のK3sクラスタを建てる
logica0419
4
210
ITエンジニアとして知っておいてほしい、電子メールという大きな穴
logica0419
6
1.1k
標準ライブラリの奥深アップデートを掘り下げよう!
logica0419
2
640
超アナログ中心な印刷会社で「エンジニアリング」を見直す
logica0419
4
210
Pure GoでアニメーションGIFのリサイズを実装する
logica0419
0
430
isugata 〜ISUCONベンチマーカーのためのカッコいいHTTPレスポンスバリデーターを作る
logica0419
0
470
開発を愛する人が最高にISUCONを楽しむ方法
logica0419
0
670
DockerでProtobufをコンパイルしたい!
logica0419
13
1.4k
ISUCON練習に使えるベンチマーカーWeb UIを作った話
logica0419
0
200
Other Decks in Technology
See All in Technology
tenntennはなんでnewmoにnew社したの? - YAPC::Hakodate 2024
tenntenn
PRO
0
220
AWSへのNIST SP800-171管理策 導入に向けての整備/20240930 Mitsutoshi Matsuo
shift_evolve
0
200
テストコードの品質を客観的な数値で担保しよう〜Mutation Testのすすめ〜
ysknsid25
12
3.1k
Develop to Survive - YAPC::Hakodate 2024 Keynote
moznion
8
2.3k
DenoでもViteしたい!インポートパスのエイリアスを指定してラクラクアプリ開発
bengo4com
2
1.9k
【shownet.conf_】コンピューティング資源を統合した分散コンテナ基盤の進化
shownet
PRO
0
400
見えづらい活動の成果の伝え方は日頃からめちゃくちゃ悩んでるけど、実際こんな取り組みをしな がら温度感を合わせにいってるよ / Conveying Hard-to-See Results
kakehashi
4
1.7k
Semantic Kernel の Agent 機能試してみた!
okazuki
1
150
入門 バックアップ
ryuichi1208
18
6.7k
ガバメントクラウド開発と変化と成長する組織 / Organizational change and growth in developing a government cloud
kazeburo
4
750
ゼロから実装まで!機械学習入門
natsuki0726
0
140
【shownet.conf_】持続可能な次世代Wi-Fi運用に向けて
shownet
PRO
0
350
Featured
See All Featured
Statistics for Hackers
jakevdp
796
220k
The Mythical Team-Month
searls
218
43k
Typedesign – Prime Four
hannesfritz
39
2.3k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
355
29k
A Philosophy of Restraint
colly
203
16k
Side Projects
sachag
452
42k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
41
9.2k
How STYLIGHT went responsive
nonsquared
95
5.1k
The Cult of Friendly URLs
andyhume
77
6k
Clear Off the Table
cherdarchuk
91
320k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Transcript
「認証認可」という 体験をデザインする ~Nekko Cloud 認証認可基盤計画 logica 𝕏: @logica0419 GitHub: @logica0419
自己紹介 • logica (ろじか) • 千葉工業大学 情報科学部 情報ネットワーク学科 3年 •
ネットワークコンテンツ研究会 (サークル) 所属 ◦ Nekko Cloudチームのソフトウェア担当 • セキュキャンだったり、ICTSCだったり、 Goだったり、Kubernetesだったり… 色んな界隈にいます
Nekko Cloudチーム
「メンバーの自宅サーバーVPNで 繋いで、プライベートクラウド 作ろう!」っていうチーム 自称「マルチリージョンプライベートクラウド」
ネッコ研が誇る逸般の誤家庭たち
ネッコ研が誇る逸般の誤家庭たち 浦和
ネッコ研が誇る逸般の誤家庭たち 津田沼
ネッコ研が誇る逸般の誤家庭たち 幕張
これらの”リージョン”を… 浦和 津田沼 幕張
VPNで繋げてしまえ! 浦和 津田沼 幕張
論理構成イメージ
これまでとこれから • これまでできたこと ◦ VPNで各拠点を繋ぐ ◦ Proxmoxでクラスタリングし、IaaSを構築する • これからやりたいこと ◦
共通認証認可基盤を作る ◦ K8sクラスタを建てて、アプリをデプロイできる プラットフォームを整える などなど…
これまでとこれから • これまでできたこと ◦ VPNで各拠点を繋ぐ ◦ Proxmoxでクラスタリングし、IaaSを構築する • これからやりたいこと ◦
共通認証認可基盤を作る ←今日はこれの話です ◦ K8sクラスタを建てて、アプリをデプロイできる プラットフォームを整える などなど…
一般的な認証認可
認証と認可 • 認証 - Authentication ◦ アクセスしているユーザが誰なのかを判別 ◦ 情報漏洩すると非常にマズい •
認可 - Authorization ◦ 誰にどの操作を許可するのかを判別 ◦ 変更されなければ、実際の影響はない • この二つはセットにすると扱いやすいので、まとめて 「認証認可」と呼ばれる
認証情報、 自前で持つか? 外部で持つか? 認証の形について、少し整理しておく
自前で持つ型 • パスワード / Passkey / 電話番号認証 など • 認証情報の取扱いにかなり気を付けなければいけない
• アカウントが増えてめんどくさい、という印象が多い
外部で持つ型 • OIDC (OAuth2) / IDaaS など • 「自前で持つ型」を認証基盤が行い、受け渡す •
知識が必要だったり、コードを書く量が増えたりで辛い
認証手法の良し悪し • 自前型 ◦ 良: 独自の手法が使える / 実装が比較的楽 ◦ 悪:
脆弱な実装が生まれやすい • 外部型 ◦ 良: 比較的安全 / ユーザーの機密情報が増えない ◦ 悪: 難しい / 実装がめんどくさい • 昨今Web界隈では「外部型に寄せよう!」という動きが 高まっている ような気がする
主な認可手法 • ユーザー紐づけ ◦ それぞれのユーザーに権限を紐づける ◦ 簡単だが、ユーザー・権限が増えると管理が大変 • RBAC (Role
Based Access Control) ◦ 最近の認可手法のデファクトスタンダード ◦ ユーザー - ロール - 権限 という風に紐づける ◦ ロールで権限を束ねることで、わかりやすくなる
RBACの例: AWS IAM Image by: AWS Document ユーザー ロール with
権限 実際に触るリソース
認証・認可情報を伝播させる技術 • OAuth2 ◦ 認可情報を伝える手段 ◦ 一定のAPIを叩く権限のあるアクセストークンを発行 • OIDC ◦
OAuth2を拡張した、認証情報を伝える手段 ◦ 認証情報に加え、拡張フィールドでロールなども 伝播できる
様々な技術をいい感じに組み 合わせて、認証認可の技術は 成り立っています! 以上が前提知識で、ここからが本題
Nekko Cloudで求められる要件
これまでとこれから • これまでできたこと ◦ VPNで各拠点を繋ぐ ◦ Proxmoxでクラスタリングし、IaaSを構築する • これからやりたいこと ◦
共通認証認可基盤を作る ◦ K8sクラスタを建てて、アプリをデプロイできる プラットフォームを整える などなど…
認証の要件 • Nekko Cloud内のアプリケーションエコシステムに、 共通認証基盤が欲しい ◦ IaaS / Kubernetes基盤 /
部内Wiki / VPN などなど… ◦ これらを1つのアカウントで済ませたい ◦ 逆に、それ以外のところに使う予定はない • 自分たちで認証情報を管理したくない ◦ 「外部で持つ型」の認証はほぼ確定
認可の要件 • どのメンバーがどのアプリケーションを使えるかを コントロールしたい ◦ アプリケーションの中での権限については、 「admin」か「user」かくらいしか存在しない • アプリケーション側に複雑なロジックを実装したくない ◦
アプリケーション側で権限管理をしたくない ◦ 外付けの認可基盤で管理できればBest
肥大化・分散する認可情報 • 認可情報は、肥大化する傾向にある ◦ IAMとか、全部分かってる人いない • 認可情報は、分散していく傾向にある ◦ 認証情報はOIDC等でそのまま伝播できるが、 認可情報はそれぞれのアプリケーションが持つ
◦ OIDCでも伝播できるのはせいぜいロール程度で、 ロールを元に権限を割り振るのはそれぞれのアプリ • これが汎用的な基盤の限界
プラットフォームとしての要件 • できるだけアプリケーションにロジックを入れたくない ◦ 今後みんながアプリケーションを作りやすくする ために、複雑性の隠蔽をしたい ◦ 既存OSSの場合はOIDCの設定 / 自作アプリなら
プロキシで認証できると良い (後述) • Kubernetesをアプリケーションデプロイ基盤として 用いるので、それに即した形にしたい
2つのソリューションを発案した 1. Kikkoff: ネッコ研 共通認証認可基盤 2. Sidauth: K8s上のhttpプロキシ型認証システム
Kikkoff: ネッコ研 共通認証認可基盤
サークルの環境と認証手法 • 部内の全ての人が、Discordサーバーにいる ◦ Discordサーバーに所属していれば、サークル員 • DiscordのOAuthで直接認証するという案が出たが、 以下の問題があった ◦ 認可処理が面倒
(Discordのロールを使うのは厳しい) ◦ OAuthしかないので、OIDCにするためには何かしら のソフトウェアを挟む必要がある
Discordで認証するポータルに OIDC Providerの機能を持たせ 認証を「プロキシ」する! 小規模クラウドだからこそ絞れる要件を、最大限絞った結果
Kikkoff • メンバーポータル 兼 OIDC Provider • メンバーポータルとして ◦ Discordのみで認証する
◦ ロール付け等、独立したメンバー管理機構 • OIDC Providerとして ◦ 部内アプリケーションの認証手法を統一する ◦ Clientにロールを紐づけ、Provider主体でアプリへ のアクセス認可をする
認証の「プロキシ」イメージ • これによって、 ◦ Discordの認証でありながら ◦ OIDCを使った認証情報の伝播ができる!
Provider主体の、単純化された認可
Provider主体の、単純化された認可 Providerがアクセスを切る (認証情報を渡さない)
メンバーのライフサイクル管理 • Kikkoffのメンバー状態 (在籍・ロールなど) を正と して、DiscordやGitHubのメンバーに逆に同期すると いうアイデア ◦ Discord /
GitHubのロール自動管理 ◦ 長期間アクセスの無い部員を自動でキック ◦ Kikkoffに登録すると、自動で各種サービスに招待 ▪ サークルのキックオフを補助する (名前の由来)
Sidauth: K8s上のhttpプロキシ型認証システム
直接認証とプロキシ型認証 • 直接認証 ◦ アプリケーションが直接認証する ◦ 認証情報はアプリケーションが持つ • プロキシ型認証 ◦
リバースプロキシが認証し、アプリに伝達 ◦ アプリは認証情報を持たず、ヘッダ等で受け取る • 複雑性をアプリから切り離したい = プロキシ型が適する
Kubernetesにおけるプロキシ型認証
Kubernetesにおけるプロキシ型認証
Ingress Controllerによる認証の問題点 • Ingress Controllerに実装が依存する ◦ 認証を実装していないIngress Controllerが存在 ◦ 新しい規格であるGateway
APIでも状況は同じ • アプリケーションと認証システムのライフサイクルが 一致しない ◦ 認証システムが落ちたらアプリにアクセスできない ◦ Ingress Controller内包だったらまだいいが、外付け だと顕著に弱さが出る
アプリケーションPodの Sidecar Containerとして 認証システムをInjectする 「自分のことは自分でやれ」型の認証システム
Ingress Controller主体
Sidecar主体
Sidecar型認証の利点 • Ingress Controllerに実装が依存しない ◦ アプリケーションPod単体で認証ができる! ◦ 認証が無いIngress ControllerでもOK •
アプリケーションと認証システムのライフサイクルが 完全に一致する ◦ アプリケーションと一心同体! ◦ 最近K8sでSidecarが改善されたので、いい感じに 実装できそう
Sidauth: Sidecar型認証Operator • CRD: AuthService ◦ Serviceの代わりに使用 ◦ Serviceの設定と、認証設定を包含する •
Sidauth Operator ◦ AuthServiceを受け取って、以下を生成する ▪ 対象のPod群へのSidecar Injection ▪ Injectしたコンテナへ向けたService
アイデア自体は転がっていたが CRDとOperatorまで 作っている人はいなかった 結構面白いプロダクトにできるのでは…?と思っている
まとめ / 今後の展望
認証認可の選択肢は 1つではないと思うが、 我々はこれでやってみたい ユースケースに合わせて適切に設計していきたいですね
実際の開発と未踏事業への挑戦 • まだ開発は開始していない ◦ Nekko Cloudのみんなで頑張って開発していく • 今回紹介した認証認可基盤と、Kubernetesベースの IaaSを設計し、「Kubernetesをベースとした、軽量な 小規模クラウド基盤」として未踏に挑戦してみたい
◦ 事前開発や開発ペースなど、未踏人材の皆さんに アドバイスいただけたら嬉しいです!
ありがとうございました 良き認証認可ライフを!