🍣
Kubeflow Notebooksの認証フローを忘備録がてらまとめてみた
Ciliumを使用したクラスタでKubeflowの認証を機能させるべく、認証のフローを追ったのでその記録をば。
ユーザがKubeflow Notebooksを開くまで
つらつらと思いつくがままにmermaidに起こしたらとんでも無いことになったので、
- ユーザーがアカウントの無い状態でアクセスし、Profile作成から出来上がるリソース
- Central DashboardでNamespaceが読み込まれるまで
- Notebookのリストを取得するまで
- Notebookを作成するまで
- NotebookのPodが立ち上がるまで
- Notebookを開くまで
に分けて起きることを説明していく。
ユーザーがアカウントの無い状態でアクセスし、Profile作成から出来上がるリソース
- アカウントが無い状態でCentral Dashboard (CD) にアクセスするとregistration flowに入る (環境変数でON/OFF可)
- フォームに名前を入力するとkind: Profileが作成される
- Profile ControllerがNamespace, Role, RoleBinding, Userを作る
Central DashboardでNamespaceが読み込まれるまで
- headerにuserが書かれた状態でCDに遷移する
- CDがCD API (/api以下) にリクエストする
- backend serverがkfamにリクエストし、userがrolebindingされているnamespaceを取得する
Notebookのリストを取得するまで
- ユーザーがNotebookのページに遷移する
- headerにuserがあることを確認し、Jupyter Web App (JWA) が開き、JWA APIからnotebookのリストを取得する
Notebookを作成するまで
- ユーザーが新規作成を押す
- JWAがAPIを叩く、この際、権限が表現されたAuthorizationPolicyによって認可が行われる
- APIがNotebookを作成する
NotebookのPodが立ち上がるまで
- Notebook ControllerがNotebookを検知する
- VirtualService, Service, Podを作る
- Profile ControllerがAuthorizationPolicyを作る
Notebookを開くまで
- ユーザーのリクエストによってJWAが再度Notebookのリストを取得
- Notebookを開き、/namespace/nameで表現されるアドレスへアクセスする
- このとき、authorizationPolicy2で認証が行われる
- Notebookが開く
おわりに
以上のようにheaderとProfile, User, Namespaceを1対1対応にしてKubeflowは認証を行っており、この構造が既存のKubernetesクラスターとのmergeを難しくさせている。
特にNotebook Controllerが作るVirtualServiceはhosts: ["*"]がハードコーディングされていて複数のドメインを使用しないことが前提となっていたりして工夫が必要である。
分かりやすくしようと頑張ったが、だいぶ煩雑になってしまった。。。
次回はCiliumへの置き換えの戦略について書こうかな。
こちらの記事は以下のリポジトリで管理されています。
誤字脱字、間違い、分かりづらい点、質問等がありましたら、Issueを立てて頂けると幸いです。
Discussion