TKGでは、認証に外部Identity Provider(IdP)を利用することができる。TKG1.3以降はPinnipedというコンポーネントが含まれており、これが外部IdPを担った認証を行うようになっている。
Pinnipedについては星野さんのCNDO2021の発表が参考になるので興味のある方は是非。
OpenID Connectを使った認証はTKGのドキュメントに記載があるのだけど、これはOktaを使った説明になっている。 自分は普段Auth0をIdPとして使っており(CNDT/CNDOもAuth0)、そちらを使ったログインをやりたいなと思い、今回の記事を書くことにした。
なおOkta/Auth0に限らずOpenID ConnectなIdPであれば似たような設定で利用可能だと思うので、適宜読み替えて活用してもらえれば。
Management Clusterの構築手順
これ以降の解説はTKG1.3.1 を前提とする。
Management Clusterを作る
Management Clusterの作り方は、1点を除き通常とほぼ変わりなし。今回はUIを使って構築してみる。
$ tanzu management-cluster create --ui
いつもの画面。今回はvSphereを使うが、認証周りについてはEC2でもAzureでも同じだと思われる。
Iaas Providerの設定は通常と変わらず。各自利用している環境に合わせて変更。
Management Cluster Settings。ここも通常と変わらないが、 CONTROL PLANE ENDPOINT の値だけちゃんとメモしておくこと。後で使います。
この後 6. Kubernetes Networkまでは通常と一緒なので割愛。
次に7. Identity Management。ここが一番のポイント。一旦TKG側の設定はここで止めておいて、Auth0の設定に入る。
Auth0の設定をする
auth0.com Auth0にログインをする。アカウントを持っていない方は新規登録しておきましょう。今回の用途くらいであれば無料の範囲内で利用可能。
ログインしたら、Applications-> Create Applicationをクリック。
Nameは任意の名前を。application typeはRegular Web Applicationsを選ぶ。
次にアプリケーションの設定にはいるが、すこし下にスクロールしたところにあるApplication URIsのAllowed Callback URIsに https://<Control PlaneのIP>:31234/callback を入れる。IPには先ほど控えたControl Planeの値を。これが出来たら一旦Save。
TKGのOIDCの設定をする
Auth0の画面を開いたままTKGの画面に戻る。
Identity Managementの項目に、Auth0の値を転記していく。
- ISSUER URL -
http://<Auth0 appのDomain>/- https:// および 末尾のスラッシュを忘れないこと。これを忘れるとログインが失敗する
- CLIENT ID -
Auth0のClient ID - CLIENT SECRET -
Auth0のClient Secret - SCOPES -
openid,groups,email - USERNAME CLAIM - どの値をUsernameとして扱うか。今回は
emailを指定 - GROUPS CLAIM - どの値をGroupとして扱うか。今回は
groupsを指定
入れ終わったらNEXTをクリック。残りの設定は通常のクラスタ作成と変わらない。
全ての設定が終わったらインストールを開始。しばらく待ち。
Management Clusterの設定
Management Clusterの設定が終わったら、次は tanzu コマンドを使ってadminのkubeconfigを取得。この段階ではOIDC認証は使っていない。
$ tanzu management-cluster kubeconfig get --admin Credentials of cluster 'demo' have been saved You can now access the cluster by running 'kubectl config use-context demo-admin@demo' $ kubectl config use-context demo-admin@demo Switched to context "demo-admin@demo".
Pinniped周りのPodが正しく上がっているかを確認。この段階で何らしかのErrorが発生していたら、コンフィグを間違っている可能性があるので kubectl logs などを使って確認する。
$ kubectl get all -n pinniped-supervisor NAME READY STATUS RESTARTS AGE pod/pinniped-post-deploy-job-bfzhn 0/1 Completed 0 3m4s pod/pinniped-supervisor-f5dd7d547-pbxbd 1/1 Running 0 2m20s pod/pinniped-supervisor-f5dd7d547-xjw8l 1/1 Running 0 2m20s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/pinniped-supervisor NodePort 100.65.72.169 <none> 443:31234/TCP 3m4s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/pinniped-supervisor 2/2 2 2 3m4s NAME DESIRED CURRENT READY AGE replicaset.apps/pinniped-supervisor-f5dd7d547 2 2 2 3m4s NAME COMPLETIONS DURATION AGE job.batch/pinniped-post-deploy-job 1/1 44s 3m4s
次に、OIDC経由のユーザーにClusterRoleを付与する。今回はManagement Clusterの全権を付与したいので、cluster-admin をユーザーにつける。ユーザーに与える権限を絞りたい場合は、ここで別のClusterRoleやRoleをbindingすれば良い
$ kubectl create clusterrolebinding cluster-admin-jacopen --clusterrole cluster-admin --user jacopen@gmail.com clusterrolebinding.rbac.authorization.k8s.io/cluster-admin-jacopen created
終わったら、OIDCで認証するためのkubeconfigを出力する。今回は /tmp/mgmt_oidc_kubeconfig に出力している
$ tanzu management-cluster kubeconfig get --export-file /tmp/mgmt_oidc_kubeconfig You can now access the cluster by running 'kubectl config use-context tanzu-cli-demo@demo' under path '/tmp/mgmt_oidc_kubeconfig'
出力したkubeconfigを使ってリソースを取得してみる。
kubectl --kubeconfig /tmp/mgmt_oidc_kubeconfig get all
すると、自動的にブラウザが立ち上がってAuth0の認証画面に飛ばされるので、Auth0に設定してある認証手段(user/pass, Google, GitHubなど)を利用してログイン。すると、ブラウザには以下のように表示され、kubectl側では無事にレスポンスが帰ってきているはず。
これで無事Management ClusterをOIDCのユーザー経由で利用できるようになった。
OIDC経由のユーザーでtanzuコマンドを利用できるようにする
OIDC経由のユーザーをcluster-adminにしたので、そのユーザーを使ってtanzuコマンドからclusterの作成等が可能になる。
環境を分けるために別ユーザーを作成の後、 tanzu login --endpoint "https://<Management Cluster IP>:6443" --name <Management Cluster名> を実行。
すると自動的にブラウザが立ち上がり、Auth0での認証が行われる。認証が通れば以下ののようになる。
$ tanzu login --endpoint "https://10.9.11.103:6443" --name demo ✔ successfully logged in to management cluster using the kubeconfig demo
$ tanzu management-cluster get
NAME NAMESPACE STATUS CONTROLPLANE WORKERS KUBERNETES ROLES
demo tkg-system running 1/1 1/1 v1.20.5+vmware.1 management
Details:
NAME READY SEVERITY REASON SINCE MESSAGE
/demo True 113m
├─ClusterInfrastructure - VSphereCluster/demo True 113m
├─ControlPlane - KubeadmControlPlane/demo-control-plane True 113m
│ └─Machine/demo-control-plane-kp9pv True 113m
└─Workers
└─MachineDeployment/demo-md-0
└─Machine/demo-md-0-86cb4697d7-sm8p8 True 113m
Providers:
NAMESPACE NAME TYPE PROVIDERNAME VERSION WATCHNAMESPACE
capi-kubeadm-bootstrap-system bootstrap-kubeadm BootstrapProvider kubeadm v0.3.14
capi-kubeadm-control-plane-system control-plane-kubeadm ControlPlaneProvider kubeadm v0.3.14
capi-system cluster-api CoreProvider cluster-api v0.3.14
capv-system infrastructure-vsphere InfrastructureProvider vsphere v0.7.7
tanzuコマンドを使ってManagement clusterの情報を得ることができた。
![MRG 可変式ダンベル 26kg ブロックダンベル 可変式 ダンベル (5～26kg) [1年保証]](https://m.media-amazon.com/images/I/41hSu0CWQAL.jpg "MRG 可変式ダンベル 26kg ブロックダンベル 可変式 ダンベル (5～26kg) [1年保証]")
