マルチテナントマルチクラスタKubernetesでもUXを損なわない認証認可の勘所

Preferred Networksでは、独自のAIアクセラレータMN-Coreが利用できるクラウドサービスの開発を進めています。複数のオンプレミスKubernetesクラスタで構成されており、セキュリティとUXを両立するために認証認可の作り込みが重要です。Kubernetes認証認可の構築事例として我々の取組みを紹介します。

イベントサイト: https://community.cncf.io/events/details/cncf-cloud-native-security-japan-presents-cncj-cloud-native-security-japan-kickoff-meetup/

Transcript

1. マルチテナントマルチクラスタKubernetesでも UXを損なわない認証認可の勘所 Cloud Native Security Japan Kickoff meetup (2024/05/17) 株式会社 Preferred Networks 奥井 寛樹
2. 3 自己紹介: 奥井 寛樹 • 2023 - 現在 ◦ 株式会社 Preferred Networks ◦ Cluster Servicesチーム • 2013 - 2023 ◦ 株式会社 NTTコミュニケーションズ • Kubernetesの上位レイヤ中心に活動 ◦ ミドルウェア、IaC、Serving、認証認可 ◦ クラスタサービスのポータル開発（FE/BE/インフラ） ◦ ハイブリッドクラウド連携 • CloudNative Days でも活動
3. 4 • PFNのAIクラウドサービス開発 • 認証の取組み • 認可の取組み • 期待のKubernetes新機能（認証認可） Agenda
4. 5 PFNのAIクラウドサービス開発
5. 6 PFNの事業: AI技術のバリューチェーンを垂直統合 ソリューション・製品 計算基盤 AIチップ PFNは、チップ、計算基盤、生成AI・基盤モデル、ソリューション・製品まで、AI技術のバリューチェーンを垂直統合し、 ソフトウェアとハードウェアを高度に融合することで、競争力の高い技術の開発および産業応用を進めています。 生成AI・基盤モデル 様々な産業・消費者向けのソリューション・製品群 MN-Core™ MN-Core™ 2 GPUクラスタ MN-3 (MN-Core™ クラスタ) 大規模言語モデル マルチモーダル基盤モデル (2024年リリース予定) 次世代機 MN-4 （MN-Core™2 クラスタ MN-Core™ 2による 計算能力のクラウド提供 (2024年開始予定） 物質の電子状態・ エネルギー計算モデル PLaMo-13B Preferred Potential (PFP)
6. 7 PFNの事業: AI技術のバリューチェーンを垂直統合 ソリューション・製品 計算基盤 AIチップ PFNは、チップ、計算基盤、生成AI・基盤モデル、ソリューション・製品まで、AI技術のバリューチェーンを垂直統合し、 ソフトウェアとハードウェアを高度に融合することで、競争力の高い技術の開発および産業応用を進めています。 生成AI・基盤モデル 様々な産業・消費者向けのソリューション・製品群 MN-Core™ MN-Core™ 2 GPUクラスタ MN-3 (MN-Core™ クラスタ) 大規模言語モデル マルチモーダル基盤モデル (2024年リリース予定) 次世代機 MN-4 （MN-Core™2 クラスタ MN-Core™ 2による 計算能力のクラウド提供 (2024年開始予定） 物質の電子状態・ エネルギー計算モデル PLaMo-13B Preferred Potential (PFP)
7. 8 誰もが MN-Core™ シリーズを利用できる AI クラウドサービス Preferred Computing Platform Preferred Computing Platform（以下、PFCP）は株式会社 Preferred Networks（以下、PFN）が構築 運用する深層学習・AI ワークロード向けのクラウドサービスです。PFNが開発する独自アクセラレータであ るMN-Core™ シリーズを唯一利用でき、最先端の性能と効率性を備えています。 強力な計算ノード MN-Core 2 ボードを4基搭載した MN-Core 2 サー バを複数専有して利用できます。すべてのノードは 深層学習に最適化された高速なネットワークで相互 に接続されています。NVIDIA GPU を搭載したノー ドも順次提供予定です。 フルマネージドサービス 深層学習・AI ワークロード向けに拡張された Kubernetes クラスタをマルチテナントで利用でき ます。大規模分散学習から推論サーバの高可用な運 用まで幅広く行なえます。ワークロードの状況を観 測するためのマネージドなモニタリングサービスも 付随しています。 MN-Core 2 サーバの構成 アクセラレータ 8 MN-Core 2 boards x 8 CPU Intel Xeon SPR 8480+ 56C x 2 Memory DDR5 64GB x 16 (2TB) Interconnect NVIDIA ConnectX-6 (100GbE) × 2 OS コンテナ ワークロード ベアメタル
8. 9 2023年のPFN社内計算機クラスタ 社内向けヘテロジニアスk8sクラスタ 2022~ MN-2b 2020~ 2019~ MN-2a MN-3
9. 10 サービス化に向け、増えてます 2022~ MN-2b 2020~ 2019~ … New!! New!! 社外向けの 新しいクラスタ 社内向けヘテロジニアスk8sクラスタ MN-2a MN-3
10. 11 Kubernetesクラスタへの接続構成 • マルチテナント ◦ 複数テナントのユーザが、同一のKubernetesクラスタを共用 • マルチクラスタ ◦ MN-Coreが使えるクラスタ、GPUがたくさん使えるクラスタ ◦ 1ユーザが、用途ごとに使い分けたい
11. 12 Kubernetesクラスタへの接続構成 テナントA apiserver テナントA テナントB テナントC テナントB テナントC apiserver テナントA テナントB テナントC … … … … … … … OIDC IdPにはAuth0を使用 認証 認可 マルチテナント & マルチクラスタ
12. 13 認証の取組み
13. 14 kubectlだけでなく、Webコンソールからも アクセスしたい kubectl => クラスタごとにアクセス Webコンソール => 複数クラスタを一気に見たい テナントA apiserver テナントA テナントB テナントC テナントB テナントC apiserver テナントA テナントB テナントC … … … … … … …
14. 15 • アグリゲータサービスを作り、マルチクラスタを束ねる ◦ ◯ 認証周りの実装が楽 ◦ △ 全クラスタ・全テナントを操作可能な強い権限を持つことになる • 各ユーザのid_tokenでアクセスさせる ◦ ◯ 強い権限を持つアグリゲータが不要 ◦ ◯ k8s RBAC以上のことができない ◦ △ 各クラスタごとに、id_token/refresh_tokenの発行が必要 Webコンソールから複数クラスタにアクセスする案 バグ・脆弱性があったときの 影響が大きくなるので避けたい
15. 16 • アグリゲータサービスを作り、マルチクラスタを束ねる ◦ ◯ 認証周りの実装が楽 ◦ △ 全クラスタ・全テナントを操作可能な強い権限を持つことになる • 各ユーザのid_tokenでアクセスさせる ◦ ◯ 強い権限を持つアグリゲータが不要 ◦ ◯ k8s RBAC以上のことができない ◦ △ 各クラスタごとに、id_token/refresh_tokenの発行が必要 Webコンソールから複数クラスタにアクセスする案 UIのrefresh_tokenは1日未満でexpireさせたい => 毎日アクセスの度に認証PopUp、は避けたい => そもそも、k8s用のClientの期限はもっと長い 複数クラスタの認証が同時に必要になる => 同時に複数PopUp、は避けたい
16. 17 • 本当に必要なときを除き、認証の存在に気付かせない ➔ OAuth2 Web Messaging Mode(prompt=none) • ブラウザが持つクレデンシャルは短命、かつシンプル（単一のセッション）に ➔ k8s認証キャッシュプロキシを介してアクセス • ブラウザ上で使わないtokenは、ブラウザに渡さない ➔ Authorization Code Grant w/ PKCEを使いつつ、 Code Grantはサーバサイドで UXとセキュリティを両立する設計 Frontend (CSR) Frontend (SSR) k8s proxy Server Side Client Side apiserver apiserver iframe 認証 & code取得 (有効なセッションが ない場合のみPopUp) ServerActionで codeを渡す codeとid_token/refresh_token を交換 Tokenを渡す id_tokenの ローテーション 接続先クラスタをHeaderで指定 => id_tokenと交換してリクエスト k8s API call ALB k8s clientのlong-lived refresh_tokenはUIに渡さず、 UIのshort-lived tokenに集約
17. 18 UXとセキュリティを両立する設計 proxyの id_tokenが有効 proxyの refresh_tokenが有効 IdPの セッションが有効 iframeを開いて IdPのログイン画面を表 示 いいえ id_tokenをHeaderに付 与してrequest いいえ refresh token flowで id_token発行 サーバサイドで id_token/refresh_token と 交換し、k8s proxyに格納 いいえ ここに到達するまで ユーザは認証に気付かない mode=web_messaging (prompt=none)で 裏で認証できる Frontend (CSR) Frontend (SSR) k8s proxy Server Side Client Side apiserver apiserver iframe 認証 & code取得 (有効なセッションが ない場合のみPopUp) ServerActionで codeを渡す codeとid_token/refresh_token を交換 Tokenを渡す id_tokenの ローテーション 接続先クラスタをHeaderで指定 => id_tokenと交換してリクエスト k8s API call ALB
18. 19 認可の取組み
19. 20 • Namespace作成を許可したいが、任意のNamespace作成権限は付与できない • k8s RBACで表現しきれない様々な認可（主に、ClusterWideな依存の参照） • ユーザ・管理者両方のマニフェスト管理負荷を下げたい マルチテナントなので、認可が重要 テナントA テナントB テナントC apiserver テナントA テナントB テナントC … … … …
20. 21 • Namespace作成を許可したいが、任意のNamespace作成権限は付与できない ➔ Hierarchical Namespaces(以下HNS）を採用 • k8s RBACで表現しきれない様々な認可（主に、ClusterWideな依存の参照） ➔ ValidatingAdmissionPolicy を含む 複数の Admission Webhook で実現 • ユーザ・管理者両方のマニフェスト管理負荷を下げたい ➔ HNSのPropagation機能と、ValidatingAdmissionPolicyを組み合わせて活用 マルチテナントなので、認可が重要 テナントA テナントB テナントC apiserver テナントA テナントB テナントC … … … …
21. 22 • HNS: SubnamespaceAnchorにより、階層的なNamespaceを構成できる ➔ SubnamespaceAnchor作成が許可されたNamespace下に限り、Namespaceを作成できる ➔ 親Namespaceに作ったリソースは、子Namespaceに伝搬する Hierarchical Namespaces (HNS) animal animal--cat animal--dog 通常のNamespace SubnamespaceAnchorにより 作成されたNamespace animal--cat animal--dog SubnamespaceAnchor SubnamespaceAnchorの作成だけ 認可すれば、Namespace作成権限を 提供できる
22. 23 • HNS: SubnamespaceAnchorにより、階層的なNamespaceを構成できる ➔ SubnamespaceAnchor作成が許可されたNamespace下に限り、Namespaceを作成できる ➔ 親Namespaceに作ったリソースは、子Namespaceに伝搬する Hierarchical Namespaces (HNS) animal--cat animal--dog propagate 通常のNamespace SubnamespaceAnchorにより 作成されたNamespace animal 親Namespaceで作成すると 子Namespaceに伝搬 親から伝搬したリソース は子では消せない
23. 24 • テナントごとにRoot Namespaceを1つ用意 ◦ これを根とするNamespaceツリー単位で、テナント間の権限分離をする • Root Namespaceの上位に管理Namespaceを作成し、リソースを伝搬 ◦ 各テナントの全Namespaceに配置でき、管理が容易 ◦ ユーザ側では変更・削除ができず、強制できる HNSのマルチテナント向けの使い方 animal-system animal animal--cat animal--dog propagate User側 System側 システム側から伝搬 => 伝搬された側は変更できない ので、強制できる テナントの Root Namespace vehicle vehicle--car vehicle-system
24. 25 • VAP: kube-apiserver組み込みのValidation機能 ◦ ValidationルールをCELで記述 ◦ API Callがないのでパフォーマンスが良い。Webhookサーバが不要で運用も楽 ◦ v1.30でGA ValidatingAdmissionPolicy (VAP) Validationルール ConfigMapや 任意のカスタムリソース （Bring your own CRD） Validationルールに対して 条件ごとのインプットを指定
25. 26 • HNSと組み合わせて、テナント属性を注入したValidationを低コストに実現 ◦ テナント属性をまとめたカスタムリソースを、paramKindとして使用 ◦ HNSで付与されるLabelを、テナントの識別（Bindingの条件）に使用 VAPのマルチテナント向けの使い方 テナント向け Validationルール テナント属性をまとめた カスタムリソース HNSで付与される、テナントの NamespaceツリーごとのLabelを 適用条件に使用
26. 27 （参考）VAPマニフェストの例 apiVersion: admissionregistration.k8s.io/v1beta1 kind: ValidatingAdmissionPolicy metadata: name: namespace-policy spec: failurePolicy: Fail paramKind: apiVersion: org.preferred.jp/v1alpha1 kind: Config matchConstraints: resourceRules: - apiGroups: ["hnc.x-k8s.io"] apiVersions: ["*"] operations: ["CREATE"] resources: ["subnamespaceanchors"] validations: - expression: "object.metadata.name.startsWith” + “(params.spec.orgName)” messageExpression: "'metadata.name must be prefixed by ... apiVersion: org.preferred.jp/v1alpha1 kind: Config metadata: namespace: animal name: org-config spec: orgName: animal ... apiVersion: admissionregistration.k8s.io/v1beta1 kind: ValidatingAdmissionPolicyBinding metadata: name: spec: policyName: namespace-policy validationActions: [Deny] paramRef: namespace: animal name: org-config parameterNotFoundAction: Deny matchResources: matchPolicy: Equivalent objectSelector: {} namespaceSelector: matchExpressions: - key: animal-system.tree.hnc.x-k8s.io/depth operator: Exists HNSのlabelを使って 各テナントのNSに限定 テナント属性をカスタムリソース にしてパラメタライズする 条件とルールを CELで記述
27. 28 • 簡単なValidation => VAP ◦ 課題1: 現状、Mutationがない ◦ 課題2: 複雑なものは書くのもテストもつらい • 簡単なMutation => Gatekeeper ◦ Validationではあまり使っていない（PSA関連などで限定的に使用） • 複雑なMutation/Validation => 自作のAdmission Webhook ◦ テストがほしい程度に複雑なロジックは、Goで実装 VAPと他のAdmission Webhookの棲み分け たくさんあって、どこでMutation/Validationされているか混乱しがち
28. 29 期待のKubernetes新機能 （認証認可）
29. 30 うれしい新機能が盛り沢山 • KEP-3331: Structured Authentication Config (v1.30 beta) ➔ 複数のOIDCクライアントが利用できる！（kubectlとUIでtokenの期限を変えられる） ➔ JWTのClaimをCELで検証できる！（不要なリクエストを減らせる） • KEP-3221: Structured Authorization Configuration (v1.30 beta) ➔ システムユーザなどを除外するルールがCELで書ける！（不要なリクエストを減らせる） ➔ Admission Webhookの実行順序を細かく設定できる！ • KEP-3962: Mutating Admission Policies (v1.31 alpha予定) ➔ VAPと同じ方式でMutationが簡単にかける！ ➔ Admission Webhookの数を減らして、シンプルにできる！
30. 31 • Preferred Networksの計算基盤関連チームでは採用を実施中です！ ◦ 機械学習プラットフォームエンジニア (クラスタのサービス化 ) ◦ ストレージエンジニア (ストレージの企画設計管理運用 ) ◦ 大規模計算基盤エンジニア/ネットワーク・インフラ運用エンジニア (クラスタの物理設計、 MN-Coreを含めた先端システム設計等 ) • カジュアル面談もやってます → We're Hiring !!
31. Making the real world computable