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
Takuto Nagami
September 15, 2024
Technology
6
790
「認証認可」という体験をデザインする ~Nekko Cloud認証認可基盤計画
2024/9/15 情報科学若手の会にて発表した際の資料です。
サークル内で開発・運用しているプライベートクラウド基盤において、認証認可基盤の要件定義と設計をした話をまとめています。
Takuto Nagami
September 15, 2024
Tweet
Share
More Decks by Takuto Nagami
See All by Takuto Nagami
Maintainer Meetupで「生の声」を聞く ~講演だけじゃないKubeCon
logica0419
1
410
理想の英語力に一直線!最高効率な英語学習のすゝめ
logica0419
6
350
Gophers EX: What We’ve Been Up To in Feb–May 2025 / 2025年2~5月 Gophers EX活動報告書
logica0419
0
74
Gophers EX プロジェクト説明
logica0419
2
34
HA K8s Clusterのスタンダードが覆る!? Cilium 1.18の🔥激アツ🔥新機能
logica0419
0
230
External SecretsのさくらProvider初期実装を担当しています
logica0419
0
300
え!! 日本国内でGo言語のバイリンガル勉強会を!?
logica0419
2
330
Golangci-lint v2爆誕: 君たちはどうすべきか
logica0419
1
700
プロポーザル一次〆切に向けて
logica0419
1
73
Other Decks in Technology
See All in Technology
【CEDEC2025】『Shadowverse: Worlds Beyond』二度目のDCG開発でゲームをリデザインする~遊びやすさと競技性の両立~
cygames
PRO
1
370
AIのグローバルトレンド 2025 / ai global trend 2025
kyonmm
PRO
1
150
Kiroでインフラ要件定義~テスト を実施してみた
nagisa53
3
370
Infrastructure as Prompt実装記 〜Bedrock AgentCoreで作る自然言語インフラエージェント〜
yusukeshimizu
1
140
Strands Agents & Bedrock AgentCoreを1分でおさらい
minorun365
PRO
8
350
Amazon S3 Vectorsは大規模ベクトル検索を低コスト化するサーバーレスなベクトルデータベースだ #jawsugsaga / S3 Vectors As A Serverless Vector Database
quiver
2
730
僕たちが「開発しやすさ」を求め 模索し続けたアーキテクチャ #アーキテクチャ勉強会_findy
bengo4com
0
2.5k
Lambda management with ecspresso and Terraform
ijin
2
170
風が吹けばWHOISが使えなくなる~なぜWHOIS・RDAPはサーバー証明書のメール認証に使えなくなったのか~
orangemorishita
15
5.8k
全員が手を動かす組織へ - 生成AIが変えるTVerの開発現場 / everyone-codes-genai-transforms-tver-development
tohae
0
200
Serverless Meetup #21
yoshidashingo
1
130
家族の思い出を形にする 〜 1秒動画の生成を支えるインフラアーキテクチャ
ojima_h
3
1.2k
Featured
See All Featured
Measuring & Analyzing Core Web Vitals
bluesmoon
8
550
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
The Pragmatic Product Professional
lauravandoore
36
6.8k
StorybookのUI Testing Handbookを読んだ
zakiyama
30
6k
Fireside Chat
paigeccino
38
3.6k
What's in a price? How to price your products and services
michaelherold
246
12k
Unsuck your backbone
ammeep
671
58k
Optimizing for Happiness
mojombo
379
70k
[RailsConf 2023] Rails as a piece of cake
palkan
56
5.8k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
The Straight Up "How To Draw Better" Workshop
denniskardys
235
140k
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をベースとした、軽量な 小規模クラウド基盤」として未踏に挑戦してみたい
◦ 事前開発や開発ペースなど、未踏人材の皆さんに アドバイスいただけたら嬉しいです!
ありがとうございました 良き認証認可ライフを!