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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

自己紹介 ● logica (ろじか) ● 千葉工業大学情報科学部情報ネットワーク学科 3年 ● ネットワークコンテンツ研究会 (サークル) 所属 ○ Nekko Cloudチームのソフトウェア担当 ● セキュキャンだったり、ICTSCだったり、 Goだったり、Kubernetesだったり… 色んな界隈にいます

Slide 3

Slide 3 text

Nekko Cloudチーム

Slide 4

Slide 4 text

「メンバーの自宅サーバーVPNで繋いで、プライベートクラウド作ろう！」っていうチーム自称「マルチリージョンプライベートクラウド」

Slide 5

Slide 5 text

ネッコ研が誇る逸般の誤家庭たち

Slide 6

Slide 6 text

ネッコ研が誇る逸般の誤家庭たち浦和

Slide 7

Slide 7 text

ネッコ研が誇る逸般の誤家庭たち津田沼

Slide 8

Slide 8 text

ネッコ研が誇る逸般の誤家庭たち幕張

Slide 9

Slide 9 text

これらの”リージョン”を… 浦和津田沼幕張

Slide 10

Slide 10 text

VPNで繋げてしまえ！浦和津田沼幕張

Slide 11

Slide 11 text

論理構成イメージ

Slide 12

Slide 12 text

これまでとこれから ● これまでできたこと ○ VPNで各拠点を繋ぐ ○ Proxmoxでクラスタリングし、IaaSを構築する ● これからやりたいこと ○ 共通認証認可基盤を作る ○ K8sクラスタを建てて、アプリをデプロイできるプラットフォームを整えるなどなど…

Slide 13

Slide 13 text

これまでとこれから ● これまでできたこと ○ VPNで各拠点を繋ぐ ○ Proxmoxでクラスタリングし、IaaSを構築する ● これからやりたいこと ○ 共通認証認可基盤を作る ←今日はこれの話です ○ K8sクラスタを建てて、アプリをデプロイできるプラットフォームを整えるなどなど…

Slide 14

Slide 14 text

一般的な認証認可

Slide 15

Slide 15 text

認証と認可 ● 認証 - Authentication ○ アクセスしているユーザが誰なのかを判別 ○ 情報漏洩すると非常にマズい ● 認可 - Authorization ○ 誰にどの操作を許可するのかを判別 ○ 変更されなければ、実際の影響はない ● この二つはセットにすると扱いやすいので、まとめて「認証認可」と呼ばれる

Slide 16

Slide 16 text

認証情報、自前で持つか？外部で持つか？認証の形について、少し整理しておく

Slide 17

Slide 17 text

自前で持つ型 ● パスワード / Passkey / 電話番号認証など ● 認証情報の取扱いにかなり気を付けなければいけない ● アカウントが増えてめんどくさい、という印象が多い

Slide 18

Slide 18 text

外部で持つ型 ● OIDC (OAuth2) / IDaaS など ● 「自前で持つ型」を認証基盤が行い、受け渡す ● 知識が必要だったり、コードを書く量が増えたりで辛い

Slide 19

Slide 19 text

認証手法の良し悪し ● 自前型 ○ 良: 独自の手法が使える / 実装が比較的楽 ○ 悪: 脆弱な実装が生まれやすい ● 外部型 ○ 良: 比較的安全 / ユーザーの機密情報が増えない ○ 悪: 難しい / 実装がめんどくさい ● 昨今Web界隈では「外部型に寄せよう！」という動きが高まっているような気がする

Slide 20

Slide 20 text

主な認可手法 ● ユーザー紐づけ ○ それぞれのユーザーに権限を紐づける ○ 簡単だが、ユーザー・権限が増えると管理が大変 ● RBAC (Role Based Access Control) ○ 最近の認可手法のデファクトスタンダード ○ ユーザー - ロール - 権限という風に紐づける ○ ロールで権限を束ねることで、わかりやすくなる

Slide 21

Slide 21 text

RBACの例: AWS IAM Image by: AWS Document ユーザーロール with 権限実際に触るリソース

Slide 22

Slide 22 text

認証・認可情報を伝播させる技術 ● OAuth2 ○ 認可情報を伝える手段 ○ 一定のAPIを叩く権限のあるアクセストークンを発行 ● OIDC ○ OAuth2を拡張した、認証情報を伝える手段 ○ 認証情報に加え、拡張フィールドでロールなども伝播できる

Slide 23

Slide 23 text

様々な技術をいい感じに組み合わせて、認証認可の技術は成り立っています！以上が前提知識で、ここからが本題

Slide 24

Slide 24 text

Nekko Cloudで求められる要件

Slide 25

Slide 25 text

Slide 26

Slide 26 text

認証の要件 ● Nekko Cloud内のアプリケーションエコシステムに、共通認証基盤が欲しい ○ IaaS / Kubernetes基盤 / 部内Wiki / VPN などなど… ○ これらを1つのアカウントで済ませたい ○ 逆に、それ以外のところに使う予定はない ● 自分たちで認証情報を管理したくない ○ 「外部で持つ型」の認証はほぼ確定

Slide 27

Slide 27 text

認可の要件 ● どのメンバーがどのアプリケーションを使えるかをコントロールしたい ○ アプリケーションの中での権限については、「admin」か「user」かくらいしか存在しない ● アプリケーション側に複雑なロジックを実装したくない ○ アプリケーション側で権限管理をしたくない ○ 外付けの認可基盤で管理できればBest

Slide 28

Slide 28 text

肥大化・分散する認可情報 ● 認可情報は、肥大化する傾向にある ○ IAMとか、全部分かってる人いない ● 認可情報は、分散していく傾向にある ○ 認証情報はOIDC等でそのまま伝播できるが、認可情報はそれぞれのアプリケーションが持つ ○ OIDCでも伝播できるのはせいぜいロール程度で、ロールを元に権限を割り振るのはそれぞれのアプリ ● これが汎用的な基盤の限界

Slide 29

Slide 29 text

プラットフォームとしての要件 ● できるだけアプリケーションにロジックを入れたくない ○ 今後みんながアプリケーションを作りやすくするために、複雑性の隠蔽をしたい ○ 既存OSSの場合はOIDCの設定 / 自作アプリならプロキシで認証できると良い (後述) ● Kubernetesをアプリケーションデプロイ基盤として用いるので、それに即した形にしたい

Slide 30

Slide 30 text

2つのソリューションを発案した 1. Kikkoﬀ: ネッコ研共通認証認可基盤 2. Sidauth: K8s上のhttpプロキシ型認証システム

Slide 31

Slide 31 text

Kikkoﬀ: ネッコ研共通認証認可基盤

Slide 32

Slide 32 text

サークルの環境と認証手法 ● 部内の全ての人が、Discordサーバーにいる ○ Discordサーバーに所属していれば、サークル員 ● DiscordのOAuthで直接認証するという案が出たが、以下の問題があった ○ 認可処理が面倒 (Discordのロールを使うのは厳しい) ○ OAuthしかないので、OIDCにするためには何かしらのソフトウェアを挟む必要がある

Slide 33

Slide 33 text

Discordで認証するポータルに OIDC Providerの機能を持たせ認証を「プロキシ」する！小規模クラウドだからこそ絞れる要件を、最大限絞った結果

Slide 34

Slide 34 text

Kikkoﬀ ● メンバーポータル兼 OIDC Provider ● メンバーポータルとして ○ Discordのみで認証する ○ ロール付け等、独立したメンバー管理機構 ● OIDC Providerとして ○ 部内アプリケーションの認証手法を統一する ○ Clientにロールを紐づけ、Provider主体でアプリへのアクセス認可をする

Slide 35

Slide 35 text

認証の「プロキシ」イメージ ● これによって、 ○ Discordの認証でありながら ○ OIDCを使った認証情報の伝播ができる！

Slide 36

Slide 36 text

Provider主体の、単純化された認可

Slide 37

Slide 37 text

Provider主体の、単純化された認可 Providerがアクセスを切る (認証情報を渡さない)

Slide 38

Slide 38 text

メンバーのライフサイクル管理 ● Kikkoﬀのメンバー状態 (在籍・ロールなど) を正として、DiscordやGitHubのメンバーに逆に同期するというアイデア ○ Discord / GitHubのロール自動管理 ○ 長期間アクセスの無い部員を自動でキック ○ Kikkoﬀに登録すると、自動で各種サービスに招待 ■ サークルのキックオフを補助する (名前の由来)

Slide 39

Slide 39 text

Sidauth: K8s上のhttpプロキシ型認証システム

Slide 40

Slide 40 text

直接認証とプロキシ型認証 ● 直接認証 ○ アプリケーションが直接認証する ○ 認証情報はアプリケーションが持つ ● プロキシ型認証 ○ リバースプロキシが認証し、アプリに伝達 ○ アプリは認証情報を持たず、ヘッダ等で受け取る ● 複雑性をアプリから切り離したい = プロキシ型が適する

Slide 41

Slide 41 text

Kubernetesにおけるプロキシ型認証

Slide 42

Slide 42 text

Kubernetesにおけるプロキシ型認証

Slide 43

Slide 43 text

Ingress Controllerによる認証の問題点 ● Ingress Controllerに実装が依存する ○ 認証を実装していないIngress Controllerが存在 ○ 新しい規格であるGateway APIでも状況は同じ ● アプリケーションと認証システムのライフサイクルが一致しない ○ 認証システムが落ちたらアプリにアクセスできない ○ Ingress Controller内包だったらまだいいが、外付けだと顕著に弱さが出る

Slide 44

Slide 44 text

アプリケーションPodの Sidecar Containerとして認証システムをInjectする「自分のことは自分でやれ」型の認証システム

Slide 45

Slide 45 text

Ingress Controller主体

Slide 46

Slide 46 text

Sidecar主体

Slide 47

Slide 47 text

Sidecar型認証の利点 ● Ingress Controllerに実装が依存しない ○ アプリケーションPod単体で認証ができる！ ○ 認証が無いIngress ControllerでもOK ● アプリケーションと認証システムのライフサイクルが完全に一致する ○ アプリケーションと一心同体！ ○ 最近K8sでSidecarが改善されたので、いい感じに実装できそう

Slide 48

Slide 48 text

Sidauth: Sidecar型認証Operator ● CRD: AuthService ○ Serviceの代わりに使用 ○ Serviceの設定と、認証設定を包含する ● Sidauth Operator ○ AuthServiceを受け取って、以下を生成する ■ 対象のPod群へのSidecar Injection ■ Injectしたコンテナへ向けたService

Slide 49

Slide 49 text

アイデア自体は転がっていたが CRDとOperatorまで作っている人はいなかった結構面白いプロダクトにできるのでは…？と思っている

Slide 50

Slide 50 text

まとめ / 今後の展望

Slide 51

Slide 51 text

認証認可の選択肢は 1つではないと思うが、我々はこれでやってみたいユースケースに合わせて適切に設計していきたいですね

Slide 52

Slide 52 text

実際の開発と未踏事業への挑戦 ● まだ開発は開始していない ○ Nekko Cloudのみんなで頑張って開発していく ● 今回紹介した認証認可基盤と、Kubernetesベースの IaaSを設計し、「Kubernetesをベースとした、軽量な小規模クラウド基盤」として未踏に挑戦してみたい ○ 事前開発や開発ペースなど、未踏人材の皆さんにアドバイスいただけたら嬉しいです！

Slide 53

Slide 53 text

ありがとうございました良き認証認可ライフを！