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 サブスクリプションにログインします。

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

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

   # 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. コマンドを使用して、ワークロード ID と OIDC 発行者を有効にした AKS クラスターを az aks create に作成します。

   # 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 のクラスターから 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 サブスクリプションからログアウトします。

   az logout
   

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

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

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

   # 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 にサービス バスとキューを作成します。

   # 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 でユーザー割り当てマネージド 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 のマネージド 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 のマネージド ID のクライアント ID を取得します。

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

3. コマンドを使用して、az servicebus namespace show の 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 のマネージド 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 サブスクリプションからログアウトします。

   az logout
   

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

   az login --tenant $TENANT_A_ID
   

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

   az account set --subscription $TENANT_A_SUBSCRIPTION_ID
   

4. コマンドを使用して、az aks get-credentials の 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 内の 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 portal に移動し、Tenant B の Azure Service Bus キューに移動して、Service Bus Explorer で送信されたメッセージを表示できます。

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

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

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

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

   az login --tenant $TENANT_A_ID
   

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

   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 サブスクリプションにログインします。

   az login --tenant $TENANT_B_ID
   

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

   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 を構成する