ポッドマネージド ID からワークロード ID に移行する

2024-08-02

この記事では、Azure Kubernetes Service (AKS) クラスターのポッドマネージド ID から Microsoft Entra Workload ID への移行に焦点を当てます。また、コンテナーベースのアプリケーションで使われる Azure ID クライアントライブラリのバージョンに応じたガイダンスも提供します。

Microsoft Entra ワークロード ID に慣れていない場合は、次の「概要」の記事を参照してください。

開始する前に

Azure CLI バージョン 2.47.0 以降。 az --version を実行してバージョンを見つけ、az upgrade を実行してバージョンをアップグレードします。インストールまたはアップグレードする必要がある場合は、Azure CLI のインストールに関するページを参照してください。

移行シナリオ

このセクションでは、インストールされている Azure ID SDK のバージョンに応じた使用できる移行オプションについて説明します。

いずれのシナリオでも、ワークロード ID を使うようにアプリケーションを更新する前に、フェデレーション信頼を設定する必要があります。最低限必要な手順は次のとおりです。

マネージド ID の資格情報を作成します。
ポッドマネージド ID に既に使われている Kubernetes サービスアカウントにマネージド ID を関連付けるか、新しい Kubernetes サービスアカウントを作成し、それをマネージド ID に関連付けます。
マネージド ID と Microsoft Entra ID の間にフェデレーション信頼関係を確立します。

以前のバージョンから移行する

アプリケーションで Azure ID SDK の最新バージョンが使用されていない場合は、2 つの選択肢があります。

アプリケーション内で、Microsoft が提供する移行サイドカーを使用できます。これにより、Linux アプリケーションが実行する IMDS トランザクションを OpenID Connect (OIDC) にプロキシできます。移行サイドカーは長期的なソリューションを意図したものではなく、ワークロード ID で迅速に稼働させる方法です。次の手順を実行します。
- 移行サイドカーを使ってワークロードをデプロイし、アプリケーションの IMDS トランザクションをプロキシします。
- 認証トランザクションが正常に完了していることを確認します。
- アプリケーションの作業をスケジュールして、SDK をサポートされているバージョンに更新します。
- SDK がサポートされているバージョンに更新されたら、プロキシサイドカーを削除して、アプリケーションをもう一度デプロイできます。
注意

移行サイドカーは、運用環境での使用はサポートされていません。この機能は、アプリケーション SDK をサポートされているバージョンに移行する時間を提供することを目的としており、長期的なソリューションを意図したものではありません。移行サイドカーは、Linux ノードプールでポッドマネージド ID のみを提供するため、Linux コンテナーでのみ使用可能です。
Azure ID クライアントライブラリの最新バージョンをサポートするようにアプリケーションを書き換えます。その後に、次の手順を実行します。
- アプリケーションのデプロイを再開して、ワークロード ID を使った認証を開始します。
- 認証トランザクションが正常に完了することを確認したら、アプリケーションからポッドマネージド ID 注釈を削除し、次にポッドマネージド ID アドオンを削除することができます。

マネージド ID の作成

マネージド ID を作成してポッドに割り当てない場合は、次のステップを実行して、アプリケーションが Azure で認証するために必要なストレージ、Key Vault、またはどんなリソースに必要なアクセス許可も作成して付与します。

Azure CLI [az アカウントセット] コマンドを使用して、特定のサブスクリプションを現在のアクティブなサブスクリプションに設定します。次に、[az identity 作成] コマンドを使用してマネージド ID を作成します。

az account set --subscription "subscriptionID"

az identity create --name "userAssignedIdentityName" --resource-group "resourceGroupName" --___location "___location" --subscription "subscriptionID"

export USER_ASSIGNED_CLIENT_ID="$(az identity show --resource-group "resourceGroupName" --name "userAssignedIdentityName" --query 'clientId' -otsv)"

マネージド ID に、必要な Azure 内のリソースにアクセスするために必要なアクセス許可を付与します。これを行う方法については、リソースへのマネージド ID アクセスの割り当てに関する記事を参照してください。
OIDC 発行者 URL を取得し、環境変数に保存するには、次のコマンドを実行します。クラスター名とリソースグループ名の既定値を置き換えてください。
```
export AKS_OIDC_ISSUER="$(az aks show --name myAKSCluster --resource-group myResourceGroup --query "oidcIssuerProfile.issuerUrl" -o tsv)"
```
変数には、次の例のような発行者 URL が含まれている必要があります。
```
https://eastus.oic.prod-aks.azure.com/00000000-0000-0000-0000-000000000000/00000000-0000-0000-0000-000000000000/
```
既定では、発行者はベース URL の https://{region}.oic.prod-aks.azure.com/{uuid} を使用するように設定されています。ここで {region} の値は、AKS クラスターがデプロイされている場所と一致します。値 {uuid} は OIDC キーを表します。

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

このアプリケーション用に作成された専用の Kubernetes サービスアカウントがない場合は、次のステップを実行して作成し、前のステップで作成したマネージド ID のクライアント ID で注釈を付けます。 az aks バージョン変更資格情報コマンドを使用してクラスター名とリソースグループ名の既定値を置き換えます。

az aks get-credentials --name myAKSCluster --resource-group "${RESOURCE_GROUP}"

次の複数行入力をコピーして Azure CLI に貼り付けます。

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    azure.workload.identity/client-id: ${USER_ASSIGNED_CLIENT_ID}
  name: ${SERVICE_ACCOUNT_NAME}
  namespace: ${SERVICE_ACCOUNT_NAMESPACE}
EOF

IDが正常に作成された場合の出力の例は、次のようになります：

Serviceaccount/workload-identity-sa created

フェデレーション ID 資格情報の信頼を確立する

az ID federated-credential作成コマンドを使用して、マネージド ID、サービスアカウント発行者、サブジェクトの間にフェデレーション ID 資格情報を作成します。値 resourceGroupName、userAssignedIdentityName、federatedIdentityName、serviceAccountNamespaceとserviceAccountName を置き換えます。

az identity federated-credential create --name federatedIdentityName --identity-name userAssignedIdentityName --resource-group resourceGroupName --issuer ${AKS_OIDC_ISSUER} --subject system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME} --audience api://AzureADTokenExchange

Note

フェデレーション ID 資格情報が最初に追加された後に反映されるまでに数秒かかります。フェデレーション ID 資格情報を追加した直後にトークン要求が行われると、古いデータがあるディレクトリにキャッシュが設定されるため、数分失敗する可能性があります。このイシューを回避するには、フェデレーション ID 資格情報を追加した後に若干の遅延を追加できます。

移行サイドカーを使ってワークロードをデプロイする

注意

移行サイドカーは、運用環境での使用はサポートされていません。この機能は、アプリケーション SDK をサポートされているバージョンに移行する時間を提供することを目的としており、長期的なソリューションを意図したものではありません。ポッド管理の ID は Linux ノードプールでのみ利用可能であったため、移行サイドカーは Linux コンテナー専用です。

アプリケーションがマネージド ID を使用していて、引き続き IMDS に依存してアクセストークンを取得する場合は、ワークロード ID 移行サイドカーを使用してワークロード ID への移行を使用できます。このサイドカーは移行ソリューションであり、長期的なアプリケーションでは、クライアントアサーションをサポートする最新の Azure Identity SDK を使用するようにコードを変更する必要があります。

ワークロードを更新またはデプロイするには、移行サイドカーを使用する場合にのみ、これらのポッド注釈を追加します。ポッド仕様でサイドカーを使用するには、次の注釈値を挿入します：

azure.workload.identity/inject-proxy-sidecar - 値は、trueか false
azure.workload.identity/proxy-sidecar-port - 値は、プロキシサイドカーに必要なポートです。既定値は 8000 です。

上記の注釈を持つポッドが作成されると、Azure Workload Identity mutating webhook によって、init-container とプロキシサイドカーがポッドスペックに自動的に挿入されます。

既に実行されている Webhook は、ポッドのデプロイに次の YAML スニペットを追加します。変更されたポッド仕様の例を次に示します：

apiVersion: v1
kind: Pod
metadata:
  name: httpbin-pod
  labels:
    app: httpbin
    azure.workload.identity/use: "true"
  annotations:
    azure.workload.identity/inject-proxy-sidecar: "true"
spec:
  serviceAccountName: workload-identity-sa
  initContainers:
  - name: init-networking
    image: mcr.microsoft.com/oss/azure/workload-identity/proxy-init:v1.1.0
    securityContext:
      capabilities:
        add:
        - NET_ADMIN
        drop:
        - ALL
      privileged: true
      runAsUser: 0
    env:
    - name: PROXY_PORT
      value: "8000"
  containers:
  - name: nginx
    image: nginx:alpine
    ports:
    - containerPort: 80
  - name: proxy
    image: mcr.microsoft.com/oss/azure/workload-identity/proxy:v1.1.0
    ports:
    - containerPort: 8000

この構成は、ポッドが作成されるすべての構成に適用されます。アプリケーションを更新またはデプロイした後、 kubectl describe pod コマンドを使用して、ポッドが実行中の状態であることを確認できます。この値 podName を、デプロイされたポッドのイメージ名に置き換えます。

kubectl describe pods podName

ポッドが IMDS トランザクションを渡すことを確認するには、kubectl logs コマンドを使用します。この値 podName を、デプロイされたポッドのイメージ名に置き換えます：

kubectl logs podName

次のログ出力は、プロキシサイドカーを介した正常なコミュニケーションに似ています。ログに、トークンが正常に取得されたこと、および GET 操作が正常に完了したことが表示されていることを確認します。

I0926 00:29:29.968723       1 proxy.go:97] proxy "msg"="starting the proxy server" "port"=8080 "userAgent"="azure-workload-identity/proxy/v0.13.0-12-gc8527f3 (linux/amd64) c8527f3/2022-09-26-00:19"
I0926 00:29:29.972496       1 proxy.go:173] proxy "msg"="received readyz request" "method"="GET" "uri"="/readyz"
I0926 00:29:30.936769       1 proxy.go:107] proxy "msg"="received token request" "method"="GET" "uri"="/metadata/identity/oauth2/token?resource=https://management.core.windows.net/api-version=2018-02-01&client_id=<client_id>"
I0926 00:29:31.101998       1 proxy.go:129] proxy "msg"="successfully acquired token" "method"="GET" "uri"="/metadata/identity/oauth2/token?resource=https://management.core.windows.net/api-version=2018-02-01&client_id=<client_id>"

ポッドマネージド ID 削除する

テストが完了し、アプリケーションがプロキシサイドカーを使ってトークンを取得できたら、クラスターからポッドの Microsoft Entra ポッドマネージド ID マッピングを削除してから、ID を削除できます。

az aks pod-identity delete コマンドを実行して、ポッドから ID を削除します。これは、ポッドマネージド ID マッピングを使用する名前空間内のすべてのポッドがサイドカーを使用するように移行された後にのみ行う必要があります。
```
az aks pod-identity delete --name podIdentityName --namespace podIdentityNamespace --resource-group myResourceGroup --cluster-name myAKSCluster
```

次のステップ

このアーティクルでは、移行オプションとしてワークロード ID を使用して認証するようにポッドを設定する方法について説明しました。 Microsoft Entra ワークロード ID の詳細については、次の概要に関する記事を参照してください。

次の方法で共有

ポッド マネージド ID からワークロード ID に移行する