Azure Kubernetes Service (AKS) でテナント間ワークロード ID を構成する

この記事では、Azure Kubernetes Service (AKS) でテナント間ワークロード ID を構成する方法について説明します。 テナント間ワークロード ID を使用すると、AKS クラスターから別のテナント内のリソースにアクセスできます。 この例では、あるテナントに Azure Service Bus を作成し、別のテナントの AKS クラスターで実行されているワークロードからメッセージを送信します。

ワークロード ID の詳細については、「ワークロード ID の概要」を参照してください。

前提条件

• 別個のテナントに 1 つずつの、2 つの Azure サブスクリプション。 この記事では、これらを Tenant A と Tenant B とします。

• ローカル コンピューターにインストールされている Azure CLI。 Azure CLI をまだインストールしていない場合は、「Azure CLI のインストール」を参照してください。

• Bash シェル環境。 この記事では、Bash シェル構文を使用します。

• 次のサブスクリプションの詳細が必要です。

  • Tenant A のテナント ID
  • Tenant A のサブスクリプション ID
  • Tenant B のテナント ID
  • Tenant B のサブスクリプション ID

Tenant A でリソースを構成する

Tenant A で、ワークロード ID と OIDC 発行者が有効になっている AKS クラスターを作成します。 このクラスターを使用して、Tenant B 内のリソースへのアクセスを試みるアプリケーションをデプロイします。

Tenant A にログインする

1. az login コマンドを使用して、Tenant A サブスクリプションにログインします。

   # Set environment variable
   TENANT_A_ID=<tenant-id>
   
   az login --tenant $TENANT_A_ID
   

2. az account set コマンドを使用して、Tenant A で正しいサブスクリプションを使用していることを確認します。

   # Set environment variable
   TENANT_A_SUBSCRIPTION_ID=<subscription-id>
   
   # Log in to your Tenant A subscription
   az account set --subscription $TENANT_A_SUBSCRIPTION_ID
   

Tenant A にリソースを作成する

1. Tenant A にリソース グループを作成し、az group create コマンドを使用して AKS クラスターをホストします。

   # Set environment variables
   RESOURCE_GROUP=<resource-group-name>
   LOCATION=<location>
   
   # Create a resource group
   az group create --name $RESOURCE_GROUP --location $LOCATION
   

2. az aks create コマンドを使用して、ワークロード ID と OIDC 発行者を有効にした AKS クラスターを Tenant A に作成します。

   # Set environment variable
   CLUSTER_NAME=<cluster-name>
   
   # Create an AKS cluster
   az aks create \
     --resource-group $RESOURCE_GROUP \
     --name $CLUSTER_NAME \
     --enable-oidc-issuer \
     --enable-workload-identity \
     --generate-ssh-keys
   

AKS クラスターから OIDC 発行者 URL を取得する

• az aks show コマンドを使用して、Tenant A のクラスターから OIDC 発行者 URL を取得します。

  OIDC_ISSUER_URL=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query "oidcIssuerProfile.issuerUrl" --output tsv)
  

Tenant B のリソースを構成する

Tenant B では、Azure Service Bus とマネージド ID を作成し、サービス バスにメッセージを読み書きするためのアクセス許可を割り当て、Tenant A のマネージド ID と AKS クラスターの間の信頼を確立します。

Tenant B にログインする

1. az logout コマンドを使用して、Tenant A サブスクリプションからログアウトします。

   az logout
   

2. az login コマンドを使用して、Tenant B サブスクリプションにログインします。

   # Set environment variable
   TENANT_B_ID=<tenant-id>
   
   az login --tenant $TENANT_B_ID
   

3. az account set コマンドを使用して、Tenant B で正しいサブスクリプションを使用していることを確認します。

   # Set environment variable
   TENANT_B_SUBSCRIPTION_ID=<subscription-id>
   
   # Log in to your Tenant B subscription
   az account set --subscription $TENANT_B_SUBSCRIPTION_ID
   

Tenant B にリソースを作成する

1. Tenant B にリソース グループを作成し、az group create コマンドを使用してマネージド ID をホストします。

   # Set environment variables
   RESOURCE_GROUP=<resource-group-name>
   LOCATION=<location>
   
   # Create a resource group
   az group create --name $RESOURCE_GROUP --location $LOCATION
   

2. az servicebus namespace create コマンドと az servicebus queue create コマンドを使用して、Tenant B にサービス バスとキューを作成します。

   # Set environment variable
   SERVICEBUS_NAME=sb-crosstenantdemo-$RANDOM
   
   # Create a new service bus namespace and and return the service bus hostname
   SERVICEBUS_HOSTNAME=$(az servicebus namespace create \
     --name $SERVICEBUS_NAME \
     --resource-group $RESOURCE_GROUP \
     --disable-local-auth \
     --query serviceBusEndpoint \
     --output tsv | sed -e 's/https:\/\///' -e 's/:443\///')
   
   # Create a new queue in the service bus namespace
   az servicebus queue create \
     --name myqueue \
     --namespace $SERVICEBUS_NAME \
     --resource-group $RESOURCE_GROUP
   

3. az identity create コマンドを使用して、Tenant B でユーザー割り当てマネージド ID を作成します。

   # Set environment variable
   IDENTITY_NAME=${SERVICEBUS_NAME}-identity
   
   # Create a user-assigned managed identity
   az identity create --resource-group $RESOURCE_GROUP --name $IDENTITY_NAME
   

Tenant B でリソース ID を取得してアクセス許可を割り当てる

1. az identity show コマンドを使用して、Tenant B のマネージド ID のプリンシパル ID を取得します。

   # Get the user-assigned managed identity principalId
   PRINCIPAL_ID=$(az identity show \
     --resource-group $RESOURCE_GROUP \
     --name $IDENTITY_NAME \
     --query principalId \
     --output tsv)
   

2. az identity show コマンドを使用して、Tenant B のマネージド ID のクライアント ID を取得します。

   CLIENT_ID=$(az identity show \
     --resource-group $RESOURCE_GROUP \
     --name $IDENTITY_NAME \
     --query clientId \
     --output tsv)
   

3. az servicebus namespace show コマンドを使用して、Tenant B の Service Bus 名前空間のリソース ID を取得します。

   SERVICEBUS_ID=$(az servicebus namespace show \
     --name $SERVICEBUS_NAME \
     --resource-group $RESOURCE_GROUP \
     --query id \
     --output tsv)
   

4. az role assignment create コマンドを使用して、Tenant B のマネージド ID に Service Bus メッセージの読み取りと書き込みを行うアクセス許可を割り当てます。

   az role assignment create \
     --role "Azure Service Bus Data Owner" \
     --assignee-object-id $PRINCIPAL_ID \
     --assignee-principal-type ServicePrincipal \
     --scope $SERVICEBUS_ID
   

AKS クラスターとマネージド ID の間の信頼を確立する

このセクションでは、Tenant A の AKS クラスターと Tenant B のマネージド ID の間の信頼を確立するために必要なフェデレーション ID 資格情報を作成します。Tenant A の AKS クラスターの OIDC 発行者 URL と、Tenant B のマネージド ID の名前を使用します。

• az identity federated-credential create コマンドを使用して、フェデレーション ID 資格情報を作成します。

  az identity federated-credential create \
    --name $IDENTITY_NAME-$RANDOM \
    --identity-name $IDENTITY_NAME \
    --resource-group $RESOURCE_GROUP \
    --issuer $OIDC_ISSUER_URL \
    --subject system:serviceaccount:default:myserviceaccount
  

--subject system:serviceaccount:default:myserviceaccount は、この記事で後述する Tenant A で作成する Kubernetes サービス アカウントの名前です。 アプリケーション ポッドが認証要求を行うと、この値は承認要求の subject として Microsoft Entra ID に送信されます。 Microsoft Entra ID は、この値が、フェデレーション ID 資格情報の作成時に設定した値と一致するかどうかに基づいて適格性を判断するため、値が一致することを確認することが重要です。

Azure Service Bus キューにメッセージを送信するアプリケーションをデプロイする

このセクションでは、Tenant B 内の Azure Service Bus キューにメッセージを送信するアプリケーションを Tenant A の AKS クラスターにデプロイします。

Tenant A にログインし、AKS 資格情報を取得する

1. az logout コマンドを使用して、Tenant B サブスクリプションからログアウトします。

   az logout
   

2. az login コマンドを使用して、Tenant A サブスクリプションにログインします。

   az login --tenant $TENANT_A_ID
   

3. az account set コマンドを使用して、Tenant A で正しいサブスクリプションを使用していることを確認します。

   az account set --subscription $TENANT_A_SUBSCRIPTION_ID
   

4. az aks get-credentials コマンドを使用して、Tenant A の AKS クラスターの資格情報を取得します。

   az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME
   

Azure Service Bus キューにメッセージを送信する Kubernetes リソースを作成する

1. default 名前空間に新しい Kubernetes Service Account を作成し、Tenant B のマネージド ID のクライアント ID を kubectl apply コマンドに渡します。 クライアント ID は、Tenant B の Azure Service Bus に対して Tenant A でアプリを認証するために使用されます。

   kubectl apply -f - <<EOF
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     annotations:
       azure.workload.identity/client-id: $CLIENT_ID
     name: myserviceaccount
   EOF
   

2. default 名前空間に新しい Kubernetes ジョブを作成し、Azure Service Bus キューに 100 個のメッセージを送信します。 ポッド テンプレートは、ワークロード ID と前の手順で作成したサービス アカウントを使用するように構成されています。 また、AZURE_TENANT_ID 環境変数が Tenant B のテナント ID に設定されていることにも注意してください。これは、ワークロード ID が既定で AKS クラスターのテナントに設定されるため、Tenant B のテナント ID を明示的に設定する必要があるために必要です。

   kubectl apply -f - <<EOF
   apiVersion: batch/v1
   kind: Job
   metadata:
     name: myproducer
   spec:
     template:
       metadata:
         labels:
           azure.workload.identity/use: "true"
       spec:
         serviceAccountName: myserviceaccount
         containers:
         - image: ghcr.io/azure-samples/aks-app-samples/servicebusdemo:latest
           name: myproducer
           resources: {}
           env:
           - name: OPERATION_MODE
             value: "producer"
           - name: MESSAGE_COUNT
             value: "100"
           - name: AZURE_SERVICEBUS_QUEUE_NAME
             value: myqueue
           - name: AZURE_SERVICEBUS_HOSTNAME
             value: $SERVICEBUS_HOSTNAME
           - name: AZURE_TENANT_ID
             value: $TENANT_B_ID
         restartPolicy: Never
   EOF
   

デプロイを検証する

1. kubectl describe pod コマンドを使用してポッドの状態を確認して、Tenant B 内の Azure Service Bus キューと対話するようにポッドが正しく構成されていることを確認します。

   # Get the dynamically generated pod name
   POD_NAME=$(kubectl get po --selector job-name=myproducer -o jsonpath='{.items[0].metadata.name}')
   
   # Verify the tenant ID environment variable is set for Tenant B
   kubectl describe pod $POD_NAME | grep AZURE_TENANT_ID
   

2. kubectl logs コマンドを使用して、アプリケーションがテナント間でメッセージを送信できたかどうかを確認するには、ポッドのログを確認します。

   kubectl logs $POD_NAME
   

   出力は次の出力例のようになります。

   ...
   Adding message to batch: Hello World!
   Adding message to batch: Hello World!
   Adding message to batch: Hello World!
   Sent 100 messages
   

リソースをクリーンアップする

デプロイが成功したことを確認したら、Azure のコストが発生しないようにリソースをクリーンアップできます。

Tenant A のリソースを削除する

1. az login コマンドを使用して、Tenant A サブスクリプションにログインします。

   az login --tenant $TENANT_A_ID
   

2. az account set コマンドを使用して、Tenant A で正しいサブスクリプションを使用していることを確認します。

   az account set --subscription $TENANT_A_SUBSCRIPTION_ID
   

3. az group delete コマンドを使用して、Azure リソース グループとそのすべてのリソースを削除します。

   az group delete --name $RESOURCE_GROUP --yes --no-wait
   

Tenant B のリソースを削除する

1. az login コマンドを使用して、Tenant B サブスクリプションにログインします。

   az login --tenant $TENANT_B_ID
   

2. az account set コマンドを使用して、Tenant B で正しいサブスクリプションを使用していることを確認します。

   az account set --subscription $TENANT_B_SUBSCRIPTION_ID
   

3. az group delete コマンドを使用して、Azure リソース グループとそのすべてのリソースを削除します。

   az group delete --name $RESOURCE_GROUP --yes --no-wait
   

次のステップ

この記事では、Azure Kubernetes Service (AKS) でテナント間ワークロード ID を構成する方法について説明しました。 ワークロード ID の詳細については、次の記事を参照してください。

• ワークロード ID の概要
• Azure Kubernetes Service (AKS) でワークロード ID を構成する