Azure Kubernetes ServiceとKubeFlowのユーザ管理をAzure Active Directoryで統合 #AzureAD

日立アメリカR&D IoT Edge Labの大崎です。今回Azure Kubernetes Service (以降AKS)とAzure Active Directory(以降AAD)を連携させ社内ユーザ向けDXを実現する方法について説明します。

目的

社内ユーザに提供するサービスでDXを実現するには、ユーザのニーズに合わせ迅速にユーザ追加やサービス追加を実施することが重要です。今回の想定は、AKSで構築したKubernetesクラスタ上に、クラウドネイティブなアプリケーションを稼働させて社内ユーザに利用してもらうことを考えます。
ユーザはアプリケーションだけにアクセスする場合もあれば、クラスタの低レベルなAPIを直接使用する場合もあります。このような状況では、環境を運用するアドミンは、クラスタやアプリケーションにユーザアクセスを許可するためにそれぞれにユーザ登録する必要があり、作業が煩雑です。
AKSの特徴として、クラスタ構築コマンドのオプションを指定するだけで外部IdPとしてAADと連携することが可能です(出典)。外部IdPによりユーザ管理を統合することで、AKSクラスタに加えてアプリケーションも含めた一括したユーザ設定ができます。クラスタやアプリケーションごとのユーザ設定作業が不要になるため、迅速化が期待できます。

本記事では、上記のAKSを使ったシステムの構築方法と動作確認結果を紹介します。AKSクラスタ上には、アプリケーションの一つとしてKubeFlowを構築します。

KubeFlowとは

KubeFlowは、機械学習エンジニア向けの機械学習モデルのセルフサービス開発環境を提供するKubernetes上のマイクロサービスです。内部では、機械学習の開発環境であるJupyterのコンテナや、学習済みモデルの推論処理をリクエスト時に動的に稼働させるKnative、コンテナ間及び外部との間の通信をセキュアにするIstio、ユーザを各機能に誘導するためのダッシュボードなどが稼働します。

KubeFlowについては弊社メンバーによる他の検証記事もございます。

環境構成

Kubernetes上のアプリケーションを社内ユーザ(機械学習エンジニア)に提供するために、アドミンはアプリケーション(KubeFlow)とその土台となるKubernetesクラスタを構築する必要があります。アプリケーションにもKubernetesにもそれぞれ認証認可の仕組みがあり、社内ユーザに利用してもらう際にはユーザ登録作業が必要です。アプリケーション数やクラスタ数が膨大になると、個々にユーザ登録するのは煩雑です(下図)。

今回構築する環境では、AKS上のKubernetesクラスタとKubeFlowの両方が連携可能な認証システムをAAD上に作成します(下図の左の青い箱)。これによって、ユーザ登録作業はこのAADに一回だけ実施すれば良くなります。そのユーザ情報は、KubernetesやKubeFlowに反映され、双方に同一ユーザでログインが可能になります。

使用端末および前提

準備が必要な機材は端末とAzureアカウントのみです。私は今回以下のMacbook端末を使用しました。WindowsでもLinuxでも実行可能です。

端末

スタック	摘要
Hardware	Macbook Pro (15-inch, 2017 = Intel版)
OS	macOS Big Sur 11.6

必要なもの
- Azureのアカウントおよび契約

構築手順

AKSクラスタとKubeFlow、およびAADの構築は以下の手順で実行します。

初期状態は、Azureアカウントのサブスクリプションがあり、AKS用テナント(A)も存在する状態
外部IdPとして利用する別のAADテナント(B IdP用ADテナント)を作成
IdP用ADテナントにユーザ/アドミングループを作成
Azure ADと連携したAKSクラスタを作成
Kubernetesクラスタ上にKubeFlowを構築

後述のAKSとAADの連携は異なるテナント間でも構築できます。今回はAADのテナントを以下2つ使用します。

A. AKSでKubernetesクラスタを構築するためのテナント (AKS用テナントと呼ぶ)
B. 外部IdPとして利用するAADを設定するテナント (以降IdP用テナントと呼ぶ)

端末の準備(`az` CLIのインストール)

以下ドキュメントを参考に、端末にazure-cliをインストールします。
https://docs.microsoft.com/en-us/cli/azure/install-azure-cli

brew update
brew install azure-cli

以下のコマンドでAzureにログインします。ブラウザが起動して、自分のAzureアカウントで認証を済ませると、azコマンドの設定が完了します。

az login

外部IdPとして利用する別のAzure ADテナントを作成

IdP用ADテナントを以下のドキュメントに従い作成します。

まず、AzureポータルからmyAzureKubeFlowという名称のテナントを作成します。

次に、作成したテナントにazコマンドでログインするためには以下のようにログインします。ブラウザが起動しますので、自分のアカウントで認証を済ませます。この作業によって、ユーザとしては同じなのですが、別のAADテナントを作ったことになります。

az login -t myAzureKubeFlow.onmicrosoft.com --allow-no-subscriptions

[
  {
    "tenantId": "xxxxx",
  }
]

上記のログイン時に表示されるtenantIdをメモしておきます。コマンドライン上で以下のようにメモリに残しておくと便利です。

myAadId=xxxxx

この新しいテナントmyAzureKubeFlowには今何も構築されておらず、まっさらの状態です。以降、テナントmyAzureKubeFlowにはActive Directoryのみを構築し、Kubernetesは構築しません。

ADへのユーザ/アドミングループ追加

この節では、以降AKSクラスタとKubeFlowでログインを確認するために、２名のユーザをADに追加します。

各ユーザの情報は以下です。

ユーザ	ユーザ名	パスワード	Email
ユーザ1 (アドミングループに所属)	`MyFirstUser` `@myAzureKubeFlow.onmicrosoft.com`	(省略)	ユーザ名に同じ
ユーザ2	`MySecondUser` `@myAzureKubeFlow.onmicrosoft.com`	(省略)	ユーザ名に同じ

ユーザ作成

以下２つのコマンドで２つのユーザを作成します。

az ad user create --display-name myUser1 \
                  --password <ユーザ1のパスワード> \
                  --user-principal-name "MyFirstUser@myAzureKubeFlow.onmicrosoft.com"
az ad user create --display-name myUser2 \
                  --password <ユーザ2のパスワード> \
                  --user-principal-name "MySecondUser@myAzureKubeFlow.onmicrosoft.com"

emailの追記

AzureポータルでmyUser1とmyUser2の各ユーザの情報にアクセスすると、EmailやAlternate emailが抜けています。これでは後ほどKubeFlowのログインで失敗するため、そこにUser Principal Nameと同じ内容を書き写し、保存します。


`email`の書き込み(ユーザ1、ユーザ2それぞれで必要)	保存後、以下のように確認できれば問題ありません。

ユーザが２名追加されていることが確認できます。

アドミングループ作成

以下コマンドでAKSのアドミンのグループを作成します。

myadmingroup=myAzureKubeFlowAdminGroup
az ad group create --display-name ${myadmingroup} --mail-nickname ${myadmingroup}

このときのobjectIdを控えておきます。

{
  "objectId": "yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy"
}

myadminid=yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy

アドミングループにユーザを所属させる

アドミングループにユーザ1を追加します

az ad user list | jq '.[] | "\(.userPrincipalName) \(.objectId)"'

ユーザ1に紐付いているobjectIdを以下のように指定して、ユーザ1をアドミンに設定します。

az ad group member add --group ${myadminid} \
                       --member-id <objectID>

これによって、自分のアカウントがアドミングループに追加されました。Azureポータル上も確認できます。

ここまでがIdP用ADテナント作成の手順です。

Azure ADと連携したAKSクラスタを作成

AKSでKubernetesクラスタを作成します。今回AADとの連携のために、以下のドキュメントで紹介されているAKS-managed Azure Active Directory integrationという方法を使います。az aks createコマンドを使ってADとの接続ができます。

まず、azコマンドでAKS用テナント(自分のアカウントにもともと紐付いていたテナント)に戻ります。

az login -t <AKS用テナント>.onmicrosoft.com --allow-no-subscriptions

AKSクラスタのリソース群を入れるリソースグループを新規作成します。

myenv=myAzureKubeFlow
myrg=${myenv}RG
az group create -l westus -n ${myenv}RG

リソースグループ内にAKSクラスタを作成します。このときのポイントは、--enable-aadオプションを指定し、aad-tenant-idオプションと--aad-admin-group-object-idsオプションにはそれぞれ 前述のIdP用テナントIDとアドミングループのIDを設定するところです。

mycluster=${myenv}Cluster
az aks create -g ${myrg} -n ${mycluster} \
--enable-aad --aad-admin-group-object-ids ${myadminid} --aad-tenant-id ${myAadId} --load-balancer-managed-outbound-ip-count 1

これだけでAADが連携されたクラスタが作成できました。正しく以下の"adminGroupObjectIDs", "tenantId"が設定されていることを出力から確認できます。

{
  "aadProfile": {
    "adminGroupObjectIDs": [
      "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
    ],
    "clientAppId": null,
    "enableAzureRbac": false,
    "managed": true,
    "serverAppId": null,
    "serverAppSecret": null,
    "tenantId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
  },

ポータル上では以下のようにAKSクラスタの状態を確認できます。

AKSクラスタのテスト(Kubernetesクラスタにアクセスする)

kubectlコマンドでAKSクラスタにアクセスします。まず、以下のコマンドでkubectl用プロファイルを読み込みます。

az aks get-credentials --resource-group ${myrg} --name ${mycluster}

以下のようにkubectlを実行すると、まずはAzureアカウントの認証を実行し、その結果(認証済みのトークン)をプロファイルに追記することで作成済みAKSクラスタにアクセスに可能になります。

$ kubectl get nodes
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code XXXXXXXXX to authenticate.

上記認証後、以下の出力が見られ、AKSクラスタにアクセスできていることが分かります。

NAME                                STATUS   ROLES   AGE   VERSION
aks-nodepool1-xxxxxxxx-vmss000000   Ready    agent   18m   v1.20.9
aks-nodepool1-xxxxxxxx-vmss000001   Ready    agent   18m   v1.20.9
aks-nodepool1-xxxxxxxx-vmss000002   Ready    agent   18m   v1.20.9

AKSに静的なIPアドレスを付与する

外部からアクセスするための静的なIPアドレスをAKSのKubernetesクラスタに付与します。
まず、以下のドキュメントに従いパブリックIPアドレスを取得し、クラスタに割り付けます。

まずパブリックIPアドレスを新規作成します。

az network public-ip create --resource-group ${myrg} --name myAKSPublicIP --sku Standard --allocation-method static --query publicIp.ipAddress -o tsv

XXX.XXX.XXX.XXX

コマンド実行後に取得できるIPアドレスを保持しておきます。

STATIC_IP=XXX.XXX.XXX.XXX

ClusterがパブリックIPを割り当てられるRoleを割り当てます。

aksPrincipalId=$(az aks list | jq '.[0].identity.principalId')
az role assignment create \
    --assignee ${aksPrincipalId} \
    --role "Network Contributor" \
    --scope /subscriptions/${subscription}/resourceGroups/${myrg}

テスト用に以下のリソースをtest.yamlとして保存し、以下コマンドでAKSクラスタにデプロイしてみます。

test.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: aks-helloworld-one  
spec:
  replicas: 1
  selector:
    matchLabels:
      app: aks-helloworld-one
  template:
    metadata:
      labels:
        app: aks-helloworld-one
    spec:
      containers:
      - name: aks-helloworld-one
        image: mcr.microsoft.com/azuredocs/aks-helloworld:v1
        ports:
        - containerPort: 80
        env:
        - name: TITLE
          value: "Welcome to Azure Kubernetes Service (AKS)"
---
apiVersion: v1
kind: Service
metadata:
  name: aks-helloworld-one
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-resource-group: myAzureKubeFlowRG
spec:
  type: LoadBalancer
  loadBalancerIP: <パブリックIPアドレス>
  ports:
  - port: 80
  selector:
    app: aks-helloworld-one

kubectl apply -f test.yaml

パブリックIPアドレスにアクセスすると以下のように表示されるので、静的なIPアドレスをKubernetes内のWebサービスに付与できたことが分かります。

確認が取れたので、テスト用Webサービスを削除しておきます。

kubectl delete -f test.yaml

ここまででAKSクラスタ構築が完了しました。すでにAADとも連携が完了しています。

KubeFlowの構築

KubeFlow連携のためのIdP用テナントの準備

AADのIdP用テナントmyAzureKubeFlowに、KubeFlowが認証を依頼するための"App registrations"設定を作成します。


`myAzureKubeFlow`テナントにWebポータルでアクセスし、`App registrations`を参照します。	"New registration"をクリック。"kubeflow"というアプリを登録。

"Certificates & secrets"からClient Secretsを作成。	作成されたシークレット

最後のValueと、Overviewに記載のApplication (client) ID = Client IDを控えておきます。

KubeFlow側のURIの追加


Authentication内のPlatform configurationsから `+ Add a platform`を選択し、	`Web`を選択。

Redirect URIsに`https://<パブリックIPアドレス>/login/oidc`を設定します。

ここまででKubeFlow用準備が完了です。

KubeFlowのインストール

KubeFlowのインストールにはkfctlコマンドを利用する方法とマニフェストを直接kubectlで流し込む方法があります。
今回は後者を利用しKubeFlowをAKS上にインストールします。

ドキュメントは以下を参考にし、まずは以下コマンドでKubeFlowのマニフェストのレポジトリをダウンロードします。
https://github.com/kubeflow/manifests#installation

git clone https://github.com/kubeflow/manifests.git

マニフェストの中身をIdP連携/HTTPS利用のために一部変更します。

まず、Azure ADにOIDC接続できるようにするために、OpenID Connectに関する以下のファイルを修正します。

manifests/common/oidc-authservice/base/params.env

- OIDC_PROVIDER=http://dex.auth.svc.cluster.local:5556/dex
+ OIDC_PROVIDER=https://login.microsoftonline.com/<ADのテナントID = myAadId>/v2.0
+ AUTHSERVICE_URL_PREFIX=
- OIDC_AUTH_URL=/dex/auth
+ OIDC_AUTH_URL=
- OIDC_SCOPES=profile email groups
+ OIDC_SCOPES=openid profile email
- REDIRECT_URL=/login/oidc
+ REDIRECT_URL=https:/<パブリックIPアドレス>/login/oidc
- SKIP_AUTH_URI=/dex
+ SKIP_AUTH_URI=
USERID_HEADER=kubeflow-userid
USERID_PREFIX=
USERID_CLAIM=email
PORT="8080"
STORE_PATH=/var/lib/authservice/data.db

以下ファイルに、AADで作成したシークレットを記載します。

manifests/common/oidc-authservice/base/secret_params.env

- CLIENT_ID=kubeflow-oidc-authservice
+ CLIENT_ID=<AADにおけるApp registrationsのClient ID>
- CLIENT_SECRET=pUBnBOY80SnXgjibTYM9ZWNzY2xreNGQok
+ CLIENT_SECRET=<Azure ADで作成したValue>

次にHTTPSを許可するため、以下の項目を末尾に足します。

manifests/common/istio-1-9/kubeflow-istio-resources/base/kf-istio-resources.yaml

  - hosts:
    - '*'
    port:
        name: https
        number: 443
        protocol: HTTPS
    tls:
        mode: SIMPLE
        privateKey: /etc/istio/ingressgateway-certs/tls.key
        serverCertificate: /etc/istio/ingressgateway-certs/tls.crt

初回ダッシュボードアクセス時にユーザ自身にNamespaceを自動作成させるために、以下のように編集します。

manifests/apps/centraldashboard/upstream/base/parames.env

- CD_REGISTRATION_FLOW=false
+ CD_REGISTRATION_FLOW=true

ここまでの編集が完了したら、kustomizeコマンドを使用しKubeFlow用のマニフェストkubeflow.yamlを作成します。この際に、ドキュメントに記載の通り、最新のkustomize 4以降には対応していないようですので、GithubのKustomizeレポジトリから3.x系の最新の3.10.0をダウンロードして使用します。

curl -LO https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize%2Fv3.10.0/kustomize_v3.10.0_darwin_amd64.tar.gz
tar zxvf kustomize_v3.10.0_darwin_amd64.tar.gz
./kustomize build manifests/example > kubeflow.yaml

生成したマニフェストkubeflow.yamlをkubectlコマンドを利用してAKSクラスタにインストールします。ドキュメントに従い、kubectlが全リソース分完了するまでwhileループを回します。

while ! kubectl apply -f kubeflow.yaml; do echo "Retrying to apply resources"; sleep 10; done

全リソースが適用されるとコマンドは終了します。

インストール後の設定(HTTPSアクセス周り)

KubeFlow自体はインストールできましたが、その上にパブリックIPアドレスをKubeFlow用のゲートウェイが使用するために以下のコマンドを実行します。

kubectl patch svc istio-ingressgateway -n istio-system -p '{"spec":{"loadBalancerIP":"40.78.45.167", "type":"LoadBalancer"}, "metadata": { "annotations": { "service.beta.kubernetes.io/azure-load-balancer-resource-group": "myAzureKubeFlowRG"}}}'

パブリックIPの設定反映(ロードバランサからのIP払い出し)が完了するまで、以下コマンドで待機します。

kubectl get svc -n istio-system -w
NAME                    TYPE           CLUSTER-IP     EXTERNAL-IP           PORT(S)
istio-ingressgateway    LoadBalancer   10.0.130.154   <パブリックIPアドレス>   15021:30153/TCP,80:30836/TCP,443:32438/TCP,31400:32111/TCP,15443:31910/TCP   7m48s

HTTPSアクセスを許可するため、以下の内容の<パブリックIPアドレス>を書き換えファイルcertificate.yamlを作成する。

apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
  name: istio-ingressgateway-certs
  namespace: istio-system
spec:
  commonName: istio-ingressgateway.istio-system.svc
  ipAddresses:
  - <パブリックIPアドレス>
  isCA: true
  issuerRef:
      kind: ClusterIssuer
      name: kubeflow-self-signing-issuer
  secretName: istio-ingressgateway-certs

以下コマンドでそれを適用し、パブリックIPアドレス用のHTTPS用の証明書が発行されます。これにより、HTTPS経由でKubeFlowにアクセス可能となります。

kubectl apply -f certificate.yaml

以上で、KubeFlowのインストールが完了しました。

動作確認

AAD作成時に新規作成したユーザ1とユーザ2で A.KubeFlowとB.Kubernetesにそれぞれアクセスしてみます。

A. KubeFlowへのアクセス

まず、登録されたユーザでKubeFlowへのアクセスを試します。

ユースケースとしては、一般的な機械学習開発者がKubeFlowのWebインターフェース上で開発作業する中で多くのケースが該当します。

ユーザ1のアカウントでKubeFlowにアクセスするため、HTTPSでパブリックIPアドレスにアクセスします。

https://<IPアドレス>

確認の結果、以下の通り、ユーザの初回ログイン時には初期画面が開き、Namespace名を指定できました。その後、ノートブックを作成し機械学習開発の作業を開始できました。AKSクラスタやKubeFlowに特段の設定は不要であり、AADのユーザ登録さえしておけば、この環境にログインできました。


初回ログイン(1)	初回ログイン(2)

初回ログイン(3 Namespace名指定)	ダッシュボード

ノートブック作成後	ノートブックへのアクセス

上記の作業において、NamespacemyfirstuserがKubernetes上に作成されます。ユーザ2についても同様にログインして確認をしておきます。ログイン後に作成されたNamespaceは、下図のようにダッシュボードの左上のプルダウンから確認できます。この画面からわかるように、ユーザ1もユーザ2も自分のNamespaceしかアクセスできませんでした。


ユーザ1で選択できるNamespace	ユーザ2で選択できるNamespace

B. Kubernetesを使用する

次に、登録されたユーザでKubernetesへ直接アクセスできるかを確認しました。このアクセスパターンのユースケースとしては、たとえば機械学習開発者がInferenceのためのWebサービスを自分で構築するためにkubectlを操作するといったケースがあります。

確認の結果、kubectlにて各ユーザでログイン後、各ユーザが作成したNamespace内のリソースを正しく表示できました。

AADのユーザ情報で認証し、kubectlを使ってKubernetesにアクセスします。

まずazコマンドでユーザ1としてIdP用ADテナントにログインします。

az login -t myAzureKubeFlow.onmicrosoft.com --allow-no-subscriptions

ブラウザが開いた後、ユーザ1のユーザ名、パスワードを入力します。

kubectlの設定をします。ここでは異なるテナント内のAKSにアクセスするため、--subscriptionを指定するのがポイントです。

az aks get-credentials --resource-group ${myrg} --name ${mycluster} --subscription ${subscription}

A.のログイン後であればNamespaceが作成されています。以下のコマンドで、自分のNamespace myfirstuserのリソースを表示してみます。

kubectl get all -n myfirstuser

NAME                                                   READY   STATUS    RESTARTS   AGE
pod/ml-pipeline-ui-artifact-5dd95d555b-265bn           2/2     Running   0          11m
pod/ml-pipeline-visualizationserver-6b44c6759f-s7cfr   2/2     Running   0          11m
(以下略)

ユーザ1はユーザ2のNamespaceにアクセスすることができます。これは、ユーザ1をアドミングループに追加したためです。したがって、以下のコマンドも成功します。

kubectl get all -n myseconduser
NAME                                                   READY   STATUS    RESTARTS   AGE             
pod/ml-pipeline-ui-artifact-5dd95d555b-265bn           2/2     Running   0          7m48s           
pod/ml-pipeline-visualizationserver-6b44c6759f-s7cfr   2/2     Running   0          7m48s  
(以下略)

次に、ユーザ2でのアクセスを確認します。上記と同じ流れでログインをしますが、ユーザ名・パスワードはユーザ2のものを使用します。

自分のNamespaceにアクセスし、内部のリソースを確認することができます。

kubectl get all -n myseconduser
NAME                                                   READY   STATUS    RESTARTS   AGE
pod/ml-pipeline-ui-artifact-5dd95d555b-265bn           2/2     Running   0          20m
pod/ml-pipeline-visualizationserver-6b44c6759f-s7cfr   2/2     Running   0          20m

ユーザ2からユーザ1のNamespaceにアクセスし、内部のリソースを確認することはできません。

kubectl get all -n myfirstuser
Error from server (Forbidden): pods is forbidden: User "MySecondUser@myAzureKubeFlow.onmicrosoft.com
" cannot list resource "pods" in API group "" in the namespace "myfirstuser"

C. アクセスコントロールの確認

ユーザ1とユーザ2という異なるユーザでログインし、AKSとKubeFlowそれぞれでどの範囲にアクセス可能か確認しました。

#1 KubeFlowへのWeb UIを利用したアクセス (OpenID Connect経由でのシングルサインオン)
- このタイミングでAKS内にNamespaceが作成される
#2 kubectlを用いたAKSへのアクセス
- #1の操作後であれば、Namespaceとそこへのアクセス権付与(RoleBinding)は完了しているため、自分のみがアクセス可能なNamespaceを利用可能。

KubernetesクラスタとKubeFlowでのアクセスコントロールの確認結果を下表にまとめます。

ユーザ	アクセス手段	アクセス先リソース	成否
ユーザ1(アドミングループ)	KubeFlow	ユーザ1のNamespace	可能
ユーザ1(アドミングループ)	`kubectl`	ユーザ1のNamespace	可能
ユーザ1(アドミングループ)	KubeFlow	ユーザ2のNamespace	不可能 (他人であるため *1)
ユーザ1(アドミングループ)	`kubectl`	ユーザ2のNamespace	可能 (アドミンが有効でアクセス権があるため)
ユーザ2	KubeFlow	ユーザ2のNamespace	可能
ユーザ2	`kubectl`	ユーザ2のNamespace	可能
ユーザ2	KubeFlow	ユーザ1のNamespace	不可能 (他人であるため *1)
ユーザ2	`kubectl`	ユーザ1のNamespace	不可能 (Namespaceアクセス権がないため *1)

基本的にはアクセス手段に関わらず、ユーザが自分のNamespaceにのみアクセスできることが保証されています。例外として、kubectlはアドミンを考慮したアクセス権が付与されます。KubeFlowはNamespaceを基本的にユーザごとに割り当てますが、Contributorというアクセス権付与の仕組みを使えばNamespaceを複数のユーザで共有する設定もできます(*1)。

*1 https://www.kubeflow.org/docs/components/multi-tenancy/getting-started/#managing-contributors-through-the-kubeflow-ui

後片付け

Kubernetesクラスタを削除する

作成したクラスタは以下のコマンドで削除可能です。

az aks delete -g ${myrg} -n ${mycluster}

Are you sure you want to perform this operation? (y/n): y

IdP用テナントを削除する

AADの"Manage tenants"から作成したテナントを削除することができます。以下のようなチェックリストが出てきますので、App registrationsなどを終了させ、最後にテナントを削除します。

余談

さらに自動化する (Azure Logic Appsによるユーザ登録)

AADはユーザ登録などのAPIを持っており、IPaaSサービス(integration platform as a service)であるAzure Logic Appsからでも呼び出しを自動実行することが可能です。Azure Logic Appsの追加使用により、以下のようなユーザ登録自動化も可能です。

Formでユーザ登録依頼があったら、
Teams上に通知＆承認待ちを表示し、
ユーザ依頼と承認結果に基づいてAADのテナントにユーザを登録し、
そのユーザをAAD内の適切なグループに配属し、
登録完了をTeamsに返答する

ユーザ登録後は、ユーザ自身が初回KubeFlowアクセス時に自動的にNamespaceが作成されるように設定(CD_REGISTRATION_FLOW=true)済みですので、管理者は特段の作業は不要です。

まとめ

AKSのKubernetesクラスタとAADとの連携ができました。AKS-managed Azure Active Directory integrationの方法を使用することで、AKSのクラスタ作成のオプションにAADのパラメータを指定するだけで、スムーズに必要な連携を構築できました。

さらに、AADでユーザ管理しておくことで、KubernetesクラスタだけでなくアプリケーションであるKubeFlowのユーザ登録も一元化できました。新規登録されたユーザは、KubeFlowにログインすると同時に、その後のkubectlにより同一ユーザでKubernetesクラスタにアクセスも可能でした。

余談として、Azure ADへのユーザ登録自体もAzure App Logicを使えば自動化できることも紹介しました。私は日立アメリカR&D向けの機械学習開発環境の運用において、この仕組を利用してKubernetesへのユーザ登録の自動ワークフローも運用しています。

以上のように、Kubernetesとアプリケーションのユーザ管理を統合しておくことで、ユーザ登録のプロセスが迅速化でき、社内ユーザ向けDXの実現に一歩近づいたと考えます。このような改善の積み重ねていくことで、社内ユーザ向けDXを実現できると考えています。

謝辞

マイクロソフト社の阪本真悟様には、日頃よりAzureの様々なサービスについてご教示いただきました。本件に関してもAADの基本的な使い方から相談に乗っていただき、Azure Logic Appsのことも教えていただきました。御礼申し上げます。

Azure Kubernetes ServiceとKubeFlowのユーザ管理をAzure Active Directoryで統合

目的