Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

logica / Takuto Nagami

September 15, 2024
Tweet

More Decks by logica / Takuto Nagami

Other Decks in Technology

Transcript

  1. 自己紹介 • logica (ろじか) • 千葉工業大学 情報科学部 情報ネットワーク学科 3年 •

    ネットワークコンテンツ研究会 (サークル) 所属 ◦ Nekko Cloudチームのソフトウェア担当 • セキュキャンだったり、ICTSCだったり、 Goだったり、Kubernetesだったり… 色んな界隈にいます
  2. これまでとこれから • これまでできたこと ◦ VPNで各拠点を繋ぐ ◦ Proxmoxでクラスタリングし、IaaSを構築する • これからやりたいこと ◦

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

    共通認証認可基盤を作る ←今日はこれの話です ◦ K8sクラスタを建てて、アプリをデプロイできる プラットフォームを整える などなど…
  4. 認証と認可 • 認証 - Authentication ◦ アクセスしているユーザが誰なのかを判別 ◦ 情報漏洩すると非常にマズい •

    認可 - Authorization ◦ 誰にどの操作を許可するのかを判別 ◦ 変更されなければ、実際の影響はない • この二つはセットにすると扱いやすいので、まとめて 「認証認可」と呼ばれる
  5. 認証手法の良し悪し • 自前型 ◦ 良: 独自の手法が使える / 実装が比較的楽 ◦ 悪:

    脆弱な実装が生まれやすい • 外部型 ◦ 良: 比較的安全 / ユーザーの機密情報が増えない ◦ 悪: 難しい / 実装がめんどくさい • 昨今Web界隈では「外部型に寄せよう!」という動きが 高まっている ような気がする
  6. 主な認可手法 • ユーザー紐づけ ◦ それぞれのユーザーに権限を紐づける ◦ 簡単だが、ユーザー・権限が増えると管理が大変 • RBAC (Role

    Based Access Control) ◦ 最近の認可手法のデファクトスタンダード ◦ ユーザー - ロール - 権限 という風に紐づける ◦ ロールで権限を束ねることで、わかりやすくなる
  7. 認証・認可情報を伝播させる技術 • OAuth2 ◦ 認可情報を伝える手段 ◦ 一定のAPIを叩く権限のあるアクセストークンを発行 • OIDC ◦

    OAuth2を拡張した、認証情報を伝える手段 ◦ 認証情報に加え、拡張フィールドでロールなども 伝播できる
  8. これまでとこれから • これまでできたこと ◦ VPNで各拠点を繋ぐ ◦ Proxmoxでクラスタリングし、IaaSを構築する • これからやりたいこと ◦

    共通認証認可基盤を作る ◦ K8sクラスタを建てて、アプリをデプロイできる プラットフォームを整える などなど…
  9. 認証の要件 • Nekko Cloud内のアプリケーションエコシステムに、 共通認証基盤が欲しい ◦ IaaS / Kubernetes基盤 /

    部内Wiki / VPN などなど… ◦ これらを1つのアカウントで済ませたい ◦ 逆に、それ以外のところに使う予定はない • 自分たちで認証情報を管理したくない ◦ 「外部で持つ型」の認証はほぼ確定
  10. Kikkoff • メンバーポータル 兼 OIDC Provider • メンバーポータルとして ◦ Discordのみで認証する

    ◦ ロール付け等、独立したメンバー管理機構 • OIDC Providerとして ◦ 部内アプリケーションの認証手法を統一する ◦ Clientにロールを紐づけ、Provider主体でアプリへ のアクセス認可をする
  11. メンバーのライフサイクル管理 • Kikkoffのメンバー状態 (在籍・ロールなど) を正と して、DiscordやGitHubのメンバーに逆に同期すると いうアイデア ◦ Discord /

    GitHubのロール自動管理 ◦ 長期間アクセスの無い部員を自動でキック ◦ Kikkoffに登録すると、自動で各種サービスに招待 ▪ サークルのキックオフを補助する (名前の由来)
  12. 直接認証とプロキシ型認証 • 直接認証 ◦ アプリケーションが直接認証する ◦ 認証情報はアプリケーションが持つ • プロキシ型認証 ◦

    リバースプロキシが認証し、アプリに伝達 ◦ アプリは認証情報を持たず、ヘッダ等で受け取る • 複雑性をアプリから切り離したい = プロキシ型が適する
  13. Ingress Controllerによる認証の問題点 • Ingress Controllerに実装が依存する ◦ 認証を実装していないIngress Controllerが存在 ◦ 新しい規格であるGateway

    APIでも状況は同じ • アプリケーションと認証システムのライフサイクルが 一致しない ◦ 認証システムが落ちたらアプリにアクセスできない ◦ Ingress Controller内包だったらまだいいが、外付け だと顕著に弱さが出る
  14. Sidecar型認証の利点 • Ingress Controllerに実装が依存しない ◦ アプリケーションPod単体で認証ができる! ◦ 認証が無いIngress ControllerでもOK •

    アプリケーションと認証システムのライフサイクルが 完全に一致する ◦ アプリケーションと一心同体! ◦ 最近K8sでSidecarが改善されたので、いい感じに 実装できそう
  15. Sidauth: Sidecar型認証Operator • CRD: AuthService ◦ Serviceの代わりに使用 ◦ Serviceの設定と、認証設定を包含する •

    Sidauth Operator ◦ AuthServiceを受け取って、以下を生成する ▪ 対象のPod群へのSidecar Injection ▪ Injectしたコンテナへ向けたService