Azure Arc クラスターで有効になっている AKS にワークロード ID をデプロイして構成する (プレビュー)

[アーティクル]
12/20/2024

適用対象: Azure Local バージョン 23H2

ワークロード ID フェデレーションを使用すると、Microsoft Entra ID のユーザー割り当てマネージド ID またはアプリ登録を構成して、Kubernetes などの外部 ID プロバイダー (IdP) からのトークンを信頼し、Azure Key Vault や Azure Blob Storage など、Microsoft Entra によって保護されたリソースへのアクセスを有効にできます。

Azure Arc によって有効になっている Azure Kubernetes Service (AKS) は、ワークロード ID が有効な Kubernetes クラスターを簡単にデプロイできるマネージド Kubernetes サービスです。この記事では、次のタスクを実行する方法について説明します。

ワークロード ID が有効になっている AKS Arc クラスターを作成します (プレビュー)。
Kubernetes サービスアカウントを作成し、Azure マネージド ID にバインドします。
OIDC 発行者を信頼するために、マネージド ID にフェデレーション資格情報を作成します。
アプリケーションをデプロイします。
例: クラスター内のポッドに、Azure キーコンテナー内のシークレットへのアクセス権を付与します。

ワークロード ID フェデレーションの概念の概要については、「Azure Arc 対応 Kubernetes (プレビュー)でのワークロード ID フェデレーション」を参照してください。

重要

これらのプレビュー機能は、セルフサービスのオプトインベースで利用できます。プレビューは、"現状有姿" および "利用可能な限度" で提供され、サービスレベルアグリーメントおよび限定保証から除外されるものとします。 Azure Arc プレビューで有効になっている Azure Kubernetes Service は、ベストエフォートベースでカスタマーサポートによって部分的にカバーされます。

Note

パブリックプレビューでは、AKS on Azure Local バージョン 23H2 では、AKS クラスターの作成時にワークロード ID を有効にできます。ただし、クラスターの作成後にワークロード ID を有効にするか、その後で無効にすることは現在サポートされていません。

前提条件

Azure Arc を有効にして Kubernetes クラスターをデプロイする前に、次の前提条件が必要です。

Azure サブスクリプションをお持ちでない場合は、開始する前に無料アカウントを作成してください。
この記事では、Azure CLI のバージョン 1.4.23 以降が必要です。 Azure Cloud Shell を使用している場合は、最新バージョンが既にインストールされています。

環境変数をエクスポートする

必要な ID を構成する手順を簡略化するために、次のコマンドでは、この記事の例で参照されている環境変数を定義します。次の値は固有の値に置き換えてください。

$AZSubscriptionID = "00000000-0000-0000-0000-000000000000" 
$Location = "westeurope" 
$resource_group_name = "myResourceGroup" 

$aks_cluster_name = "myAKSCluster" 

$SERVICE_ACCOUNT_NAMESPACE = "default" 
$SERVICE_ACCOUNT_NAME = "workload-identity-sa" 

$FedIdCredentialName = "myFedIdentity" 
$MSIName = "myIdentity" 

# To access key vault secrets from a pod in the cluster, include these variables:
$KVName = "KV-workload-id" 
$KVSecretName= "KV-secret"

アクティブなサブスクリプションを設定する

最初に、サブスクリプションを現在アクティブなサブスクリプションとして設定します。サブスクリプション ID で az アカウントセットコマンドを実行します。

az login  
az account set -s $AZSubscriptionID

リソースグループを作成する

Azure リソースグループは、Azure リソースが展開され管理される論理グループです。リソースグループを作成する際は、場所の指定を求めるプロンプトが表示されます。この場所は、リソースグループのメタデータが格納される場所です。また、リソースの作成時に別のリージョンを指定しない場合は、Azure でリソースが実行される場所でもあります。

リソースグループを作成するには、az group create コマンドを実行します。

az group create --name $resource_group_name --location $Location

次の出力例は、リソースグループの正常な作成を示しています。

{ 
  "id": "/subscriptions/<guid>/resourceGroups/myResourceGroup", 
  "location": "westeurope", 
  "managedBy": null, 
  "name": "$resource_group_name", 
  "properties": { 
    "provisioningState": "Succeeded" 
  }, 
  "tags": null 
}

手順 1: ワークロード ID が有効になっている AKS Arc クラスターを作成する

AKS Arc クラスターを作成するには、 $customlocation_ID と $logicnet_Id の両方の値が必要です。

$customlocation_ID: カスタムの場所の Azure Resource Manager ID。カスタムの場所は、Azure Local Version 23H2 クラスターのデプロイ中に構成されます。インフラストラクチャ管理者は、カスタムの場所の Resource Manager ID を指定する必要があります。インフラストラクチャ管理者がカスタムの場所名とリソースグループ名を提供する場合は、 $customlocation_ID = $(az customlocation show --name "<your-custom-location-name>" --resource-group $resource_group_name --query "id" -o tsv)を使用して Resource Manager ID を取得することもできます。
$logicnet_Id: 作成された Azure ローカル論理ネットワークの Azure Resource Manager ID 次の手順を実行します。インフラストラクチャ管理者は、論理ネットワークの Resource Manager ID を指定する必要があります。インフラストラクチャ管理者が論理ネットワーク名とリソースグループ名を指定した場合は、 $logicnet_Id = $(az stack-hci-vm network lnet show --name "<your-lnet-name>" --resource-group $resource_group_name --query "id" -o tsv)を使用して Resource Manager ID を取得することもできます。

パラメーターを使用して --enable-oidc-issuer --enable-workload-identity コマンドを実行します。 entra-admin-group-object-ids を指定しプロキシモードアクセス用の Microsoft Entra ID 管理グループのメンバーであることを確認します。

az aksarc create  
-n $aks_cluster_name -g $resource_group_name  
--custom-location $customlocation_ID --vnet-ids $logicnet_Id  
--aad-admin-group-object-ids <entra-admin-group-object-ids> 
--generate-ssh-keys  
--enable-oidc-issuer --enable-workload-identity

数分後、コマンドが完了し、クラスターに関する情報が JSON 形式で返されます。

プロビジョニングされたクラスターが正常に作成された後、ワークロード ID 拡張機能がデプロイされるまでに時間がかかる場合があります。次のコマンドを使用して、ワークロード ID 拡張機能の状態を確認します。

az connectedk8s show -n $aks_cluster_name -g $resource_group_name

# agentState = "Succeeded" 
"agentPublicKeyCertificate": "", 
  "agentVersion": "1.21.10", 
  "arcAgentProfile": { 
    "agentAutoUpgrade": "Enabled", 
    "agentErrors": [], 
    "agentState": "Succeeded", 
    "desiredAgentVersion": "", 
    "systemComponents": null 

# oidcIssuerProfile "enabled": true and "issuerUrl" present 

"oidcIssuerProfile": { 
    "enabled": true, 
    "issuerUrl": "https://oidcdiscovery-{location}-endpoint-1111111111111111.000.azurefd.net/00000000-0000-0000-0000-000000000000/11111111-1111-1111-1111-111111111111/"}

Azure portal では、Kubernetes クラスターの Properties セクションで、wiextension 拡張機能を表示できます。

重要

AKS Arc クラスターのセキュリティ強化の一環として、ワークロード ID 有効化によって 2 つの変更がトリガーされます。まず、Kubernetes サービスアカウント署名キーは 45 日ごとに自動的にローテーションされ、90 日間有効なままになります。次に、 --service-account-extend-token-expiration フラグが無効になっており、トークンの有効性が 1 年から最大 24 時間に短縮されます。

OIDC 発行者 URL を環境変数に保存する

AKS クラスターが正常に作成されたら、OIDC 発行者 URL を取得し、環境変数に保存できます。次のコマンドを実行します。

$SERVICE_ACCOUNT_ISSUER =$(az connectedk8s show --n $aks_cluster_name --resource-group $resource_group_name --query "oidcIssuerProfile.issuerUrl" --output tsv)

手順 2: Kubernetes サービスアカウントを作成し、Azure マネージド ID にバインドする

まず、マネージド ID を作成します。 az id create コマンドを実行します。

az identity create --name $MSIName --resource-group $resource_group_name --location $Location --subscription $AZSubscriptionID

次に、マネージド ID のクライアント ID の変数を作成します。

$MSIId=$(az identity show --resource-group $resource_group_name --name $MSIName --query 'clientId' --output tsv)
$MSIPrincipalId=$(az identity show --resource-group $resource_group_name --name $MSIName --query 'principalId' --output tsv)

Kubernetes サービスアカウントを作成する

Kubernetes サービスアカウントを作成し、前の手順で作成したマネージド ID のクライアント ID で注釈を付けます。

az connectedk8s proxy -n $aks_cluster_name -g $resource_group_name

新しいウィンドウを開きます。次の CLI コマンドをコピーして貼り付けます。

$yaml = @" apiVersion: v1 kind: ServiceAccount metadata: annotations: azure.workload.identity/client-id: $MSIId name: $SERVICE_ACCOUNT_NAME namespace: $SERVICE_ACCOUNT_NAMESPACE "@ $yaml = $yaml -replace '\$MSIId', $MSIId ` -replace '\$SERVICE_ACCOUNT_NAME', $SERVICE_ACCOUNT_NAME ` -replace '\$SERVICE_ACCOUNT_NAMESPACE', $SERVICE_ACCOUNT_NAMESPACE $yaml | kubectl apply -f -

次の出力は、サービスアカウントの正常な作成を示しています。

serviceaccount/workload-identity-sa created

手順 3: OIDC 発行者を信頼するためのフェデレーション資格情報をマネージド ID に作成する

まず、フェデレーション ID 資格情報を作成します。 az identity federated-credential create コマンドを呼び出して、マネージド ID、サービスアカウント発行者、サブジェクトの間にフェデレーション ID 資格情報を作成します。 Microsoft Entra のフェデレーション ID 資格情報の詳細については、Microsoft Entra ID でのフェデレーション ID 資格情報の概要に関する記事を参照してください。

# Create a federated credential 

az identity federated-credential create --name $FedIdCredentialName --identity-name $MSIName --resource-group $resource_group_name --issuer $SERVICE_ACCOUNT_ISSUER --subject "system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME}" 

# Show the federated credential 

az identity federated-credential show --name $FedIdCredentialName --resource-group $resource_group_name --identity-name $MSIName

Note

フェデレーション ID 資格情報を追加した後、反映されるまでに数秒かかります。その直後に行われたトークン要求は、キャッシュが更新されるまで失敗する可能性があります。この問題を回避するには、フェデレーション ID 資格情報の作成後に少しの遅延を追加することを検討してください。

手順 4: アプリケーションをデプロイする

アプリケーションポッドをデプロイする場合、マニフェストは、「Kubernetes サービスアカウントの作成」の手順で作成されたサービスアカウントを参照する必要があります。次のマニフェストは、アカウント、具体的には metadata\namespace プロパティと spec\serviceAccountName プロパティを参照する方法を示しています。 image のイメージと、containerName のコンテナー名を指定してください。

$image = "<image>"  # Replace <image> with the actual image name 
$containerName = "<containerName>"  # Replace <containerName> with the actual container name 

$yaml = @" 
apiVersion: v1 
kind: Pod 
metadata: 
  name: sample-quick-start 
  namespace: $SERVICE_ACCOUNT_NAMESPACE 
  labels: 
    azure.workload.identity/use: "true" # Required. Only pods with this label can use workload identity. 
spec: 
  serviceAccountName: $SERVICE_ACCOUNT_NAME 
  containers: 
    - image: $image 
      name: $containerName 
"@ 

# Replace variables within the YAML content 
$yaml = $yaml -replace '\$SERVICE_ACCOUNT_NAMESPACE', $SERVICE_ACCOUNT_NAMESPACE ` 
                -replace '\$SERVICE_ACCOUNT_NAME', $SERVICE_ACCOUNT_NAME 

# Apply the YAML configuration 
$yaml | kubectl apply -f -

重要

ワークロード ID を使用するアプリケーションポッドに、ポッド仕様にラベル azure.workload.identity/use: "true" が含まれるようにします。それ以外の場合、ポッドは再起動後に失敗します。

例: Azure Key Vault にアクセスするためのアクセス許可を付与する

この手順の手順では、ポッドから Azure キーコンテナー内のシークレット、キー、または証明書にアクセスする方法について説明します。このセクションの例では、ワークロード ID のキーコンテナー内のシークレットへのアクセスを構成しますが、同様の手順を実行してキーまたは証明書へのアクセスを構成できます。

次の例は、Azure ロールベースのアクセス制御 (Azure RBAC) アクセス許可モデルを使用して、ポッドにキーコンテナーへのアクセスを許可する方法を示しています。 Azure Key Vault の Azure RBAC アクセス許可モデルの詳細については、「Azure RBAC を使用して Azure キーコンテナーへのアクセス許可をアプリケーションに付与する」を参照してください。

消去保護と RBAC 承認が有効になっているキーコンテナーを作成します。既存のキーコンテナーが消去保護と RBAC 承認の両方に対して構成されている場合は、それを使用することもできます。

az keyvault create --name $KVName --resource-group $resource_group_name --location $Location --enable-purge-protection --enable-rbac-authorization

# retrieve the key vault ID for role assignment
$KVId=$(az keyvault show --resource-group $resource_group_name --name $KVName --query id --output tsv)

RBAC Key Vault Secrets Officer ロールを自分に割り当てて、新しいキーコンテナーにシークレットを作成できるようにします。新しいロールの割り当てが認可サーバーに伝達されて更新されるまで、"最大で 5 分" かかることがあります。
```
az role assignment create --assignee-object-id $MSIPrincipalId --role "Key Vault Secrets Officer" --scope $KVId --assignee-principal-type ServicePrincipal
```

キーコンテナーにシークレットを作成します。

az keyvault secret set --vault-name $KVName --name $KVSecretName --value "Hello!"

Key Vault Secrets User ロールを、前に作成したユーザー割り当てマネージド ID に割り当てます。この手順では、キーコンテナーからシークレットを読み取るアクセス許可をマネージド ID に付与します。
```
az role assignment create --assignee-object-id $MSIPrincipalId --role "Key Vault Secrets User" --scope $KVId --assignee-principal-type ServicePrincipal
```

キーコンテナー URL の環境変数を作成します。

$KVUrl=$(az keyvault show --resource-group $resource_group_name --name $KVName --query properties.vaultUri --output tsv)

サービスアカウントと Key Vault URL を参照するポッドをデプロイします。

$yaml = @" 
apiVersion: v1 
kind: Pod 
metadata: 
  name: sample-quick-start 
  namespace: $SERVICE_ACCOUNT_NAMESPACE 
  labels: 
    azure.workload.identity/use: "true" 
spec: 
  serviceAccountName: $SERVICE_ACCOUNT_NAME 
  containers: 
    - image: ghcr.io/azure/azure-workload-identity/msal-go 
      name: oidc 
      env: 
      - name: KEYVAULT_URL 
        value: $KVUrl 
      - name: SECRET_NAME 
        value: $KVSecretName 
  nodeSelector: 
    kubernetes.io/os: linux 
"@ 

# Replace variables within the YAML content 
$yaml = $yaml -replace '\$SERVICE_ACCOUNT_NAMESPACE', $SERVICE_ACCOUNT_NAMESPACE ` 
                -replace '\$SERVICE_ACCOUNT_NAME', $SERVICE_ACCOUNT_NAME ` 
                -replace '\$KVUrl', $KVUrl ` 
                -replace '\$KVSecretName', $KVSecretName 

# Apply the YAML configuration 
$yaml | kubectl --kubeconfig <path-to-aks-cluster-kubeconfig> apply -f -

AKS Arc クラスターを削除する

AKS Arc クラスターを削除するには、az aksarc delete コマンドを使用します。

az aksarc delete -n $aks_cluster_name -g $resource_group_name

Note

PodDisruptionBudget (PDB) リソースを使用して AKS Arc クラスター削除すると、これらの PDB リソースが削除されない可能性があるという既知の問題があります。 Microsoft はこの問題を認識しており、修正に取り組んでいます。

PDB は、ワークロード ID が有効な AKS Arc クラスターに既定でインストールされます。ワークロード ID が有効な AKS Arc クラスターを削除するには、トラブルシューティングガイドのを参照してください。

次のステップ

この記事では、Kubernetes クラスターをデプロイし、アプリケーションワークロードでその資格情報による認証を行うための準備としてワークロード ID を使用するように構成しました。これで、アプリケーションをデプロイし、最新バージョンの Azure ID クライアントライブラリでワークロード ID を使用するように構成する準備ができました。

次の方法で共有

Azure Arc クラスターで有効になっている AKS にワークロード ID をデプロイして構成する (プレビュー)

前提条件

環境変数をエクスポートする

アクティブなサブスクリプションを設定する

リソースグループを作成する

手順 1: ワークロード ID が有効になっている AKS Arc クラスターを作成する

OIDC 発行者 URL を環境変数に保存する

手順 2: Kubernetes サービスアカウントを作成し、Azure マネージド ID にバインドする

Kubernetes サービスアカウントを作成する

手順 3: OIDC 発行者を信頼するためのフェデレーション資格情報をマネージド ID に作成する

手順 4: アプリケーションをデプロイする

例: Azure Key Vault にアクセスするためのアクセス許可を付与する

AKS Arc クラスターを削除する

次のステップ

フィードバック

その他のリソース

次の方法で共有

Azure Arc クラスターで有効になっている AKS にワークロード ID をデプロイして構成する (プレビュー)

前提条件

環境変数をエクスポートする

アクティブなサブスクリプションを設定する

リソース グループを作成する

手順 1: ワークロード ID が有効になっている AKS Arc クラスターを作成する

OIDC 発行者 URL を環境変数に保存する

手順 2: Kubernetes サービス アカウントを作成し、Azure マネージド ID にバインドする

Kubernetes サービス アカウントを作成する

手順 3: OIDC 発行者を信頼するためのフェデレーション資格情報をマネージド ID に作成する

手順 4: アプリケーションをデプロイする

例: Azure Key Vault にアクセスするためのアクセス許可を付与する

AKS Arc クラスターを削除する

次のステップ

フィードバック

その他のリソース

リソースグループを作成する

手順 2: Kubernetes サービスアカウントを作成し、Azure マネージド ID にバインドする

Kubernetes サービスアカウントを作成する