Azure Kubernetes Service (AKS) クラスターでワークロード ID をデプロイして構成する

[アーティクル]
06/04/2024

Azure Kubernetes Service (AKS) は、クラスターをすばやくデプロイおよび管理することができる、マネージド Kubernetes サービスです。この記事では、次の方法について説明します:

OpenID Connect 発行者と Microsoft Entra ワークロード ID を含む Azure CLI を使用して AKS クラスターをデプロイします。
Microsoft Entra ワークロード ID と Kubernetes サービスアカウントを作成します。
トークンのフェデレーション用にマネージド ID を構成する。
ワークロードをデプロイし、ワークロード ID を使用して認証を確認します。
必要に応じて、クラスター内のポッドに Azure Key Vault 内のシークレットへのアクセス権を付与します。

この記事では、Kubernetes の基本的な概念を理解していることを前提としています。詳細については、「Azure Kubernetes Services (AKS) における Kubernetes の中心概念」を参照してください。 Microsoft Entra ワークロード ID に慣れていない場合は、次の「概要」の記事を参照してください。

前提条件

Azure サブスクリプションをお持ちでない場合は、開始する前に Azure 無料アカウントを作成してください。
この記事では、Azure CLI のバージョン 2.47.0 以降が必要です。 Azure Cloud Shell を使用している場合は、最新バージョンが既にインストールされています。
クラスターの作成に使用している ID に、適切な最小限のアクセス許可が与えられていることを確認します。 AKS のアクセスと ID の情報については、「Azure Kubernetes Service (AKS) でのアクセスと ID オプション」を参照してください。
複数の Azure サブスクリプションをお持ちの場合は、az account set コマンドを使用して、リソースが課金の対象となる適切なサブスクリプション ID を選択してください。

Note

一部の手順を自動的に構成するのに役立てるために、Service Connector を使用できます。「チュートリアル: ワークロード ID を使用して Service Connector で Azure Kubernetes Service (AKS) の Azure ストレージアカウントに接続する」も参照してください。

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

まず、az account set コマンドを呼び出してサブスクリプション ID を渡すことで、サブスクリプションを現在アクティブなサブスクリプションとして設定します。

az account set --subscription <subscription-id>

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

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

export RESOURCE_GROUP="myResourceGroup"
export LOCATION="eastus"
export CLUSTER_NAME="myAKSCluster"
export SERVICE_ACCOUNT_NAMESPACE="default"
export SERVICE_ACCOUNT_NAME="workload-identity-sa"
export SUBSCRIPTION="$(az account show --query id --output tsv)"
export USER_ASSIGNED_IDENTITY_NAME="myIdentity"
export FEDERATED_IDENTITY_CREDENTIAL_NAME="myFedIdentity"
# Include these variables to access key vault secrets from a pod in the cluster.
export KEYVAULT_NAME="keyvault-workload-id"
export KEYVAULT_SECRET_NAME="my-secret"

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

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

az group create コマンドを呼び出してリソースグループを作成します。

az group create --name "${RESOURCE_GROUP}" --location "${LOCATION}"

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

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

AKS クラスターを作成する

OIDC 発行者を有効にするには、az aks create コマンドと --enable-oidc-issuer パラメーターを使って、AKS クラスターを作成します。次の例では、1 つのノードを含むクラスターを作成します。

az aks create \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${CLUSTER_NAME}" \
    --enable-oidc-issuer \
    --enable-workload-identity \
    --generate-ssh-keys

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

Note

AKS クラスターを作成すると、AKS リソースを保存するための 2 つ目のリソースグループが自動的に作成されます。詳細については、「AKS と一緒にリソースグループが 2 つ作成されるのはなぜでしょうか?」を参照してください。

既存の AKS クラスターを更新する

OIDC 発行者を使用し、ワークロード ID を有効にするには、az aks update コマンドを --enable-oidc-issuer および --enable-workload-identity パラメーターと一緒に使って呼び出し、AKS クラスターを更新できます。次の例では、既存のクラスターを更新しています。

az aks update \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${CLUSTER_NAME}" \
    --enable-oidc-issuer \
    --enable-workload-identity

OIDC 発行者 URL を取得する

OIDC 発行者 URL を取得し、環境変数に保存するには、次のコマンドを実行します。

export AKS_OIDC_ISSUER="$(az aks show --name "${CLUSTER_NAME}" \
    --resource-group "${RESOURCE_GROUP}" \
    --query "oidcIssuerProfile.issuerUrl" \
    --output tsv)"

環境変数には、次の例のような発行者 URL が含まれている必要があります。

https://eastus.oic.prod-aks.azure.com/00000000-0000-0000-0000-000000000000/11111111-1111-1111-1111-111111111111/

既定では、発行者はベース URL https://{region}.oic.prod-aks.azure.com/{tenant_id}/{uuid} を使用するように設定されています。ここで {region} の値は、AKS クラスターがデプロイされている場所と一致します。値 {uuid} は、不変であるクラスターごとにランダムに生成される guid である OIDC キーを表します。

マネージド ID の作成

[az identity 作成] コマンドを呼び出して、マネージド ID を作成します。

az identity create \
    --name "${USER_ASSIGNED_IDENTITY_NAME}" \
    --resource-group "${RESOURCE_GROUP}" \
    --location "${LOCATION}" \
    --subscription "${SUBSCRIPTION}"

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

export USER_ASSIGNED_CLIENT_ID="$(az identity show \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${USER_ASSIGNED_IDENTITY_NAME}" \
    --query 'clientId' \
    --output tsv)"

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

Kubernetes サービスアカウントを作成し、前の手順で作成したマネージド ID のクライアント ID で注釈を付けます。 az aks バージョン変更資格情報コマンドを使用してクラスター名とリソースグループ名の既定値を置き換えます。

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

az identity federated-credential create \
    --name ${FEDERATED_IDENTITY_CREDENTIAL_NAME} \
    --identity-name "${USER_ASSIGNED_IDENTITY_NAME}" \
    --resource-group "${RESOURCE_GROUP}" \
    --issuer "${AKS_OIDC_ISSUER}" \
    --subject system:serviceaccount:"${SERVICE_ACCOUNT_NAMESPACE}":"${SERVICE_ACCOUNT_NAME}" \
    --audience api://AzureADTokenExchange

Note

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

アプリケーションをデプロイする

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

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: sample-workload-identity
  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>
EOF

重要

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

Azure Key Vault にアクセスするための権限を付与する

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

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

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

export KEYVAULT_RESOURCE_GROUP="myResourceGroup"
export KEYVAULT_NAME="myKeyVault"

az keyvault create \
    --name "${KEYVAULT_NAME}" \
    --resource-group "${KEYVAULT_RESOURCE_GROUP}" \
    --location "${LOCATION}" \
    --enable-purge-protection \
    --enable-rbac-authorization

新しいキーコンテナーにシークレットを作成できるように、RBAC Key Vault Secrets Officer ロールを自分に割り当てます。

export KEYVAULT_RESOURCE_ID=$(az keyvault show --resource-group "${KEYVAULT_RESOURCE_GROUP}" \
    --name "${KEYVAULT_NAME}" \
    --query id \
    --output tsv)

az role assignment create --assignee "\<user-email\>" \
    --role "Key Vault Secrets Officer" \
    --scope "${KEYVAULT_RESOURCE_ID}"

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

export KEYVAULT_SECRET_NAME="my-secret"

az keyvault secret set \
    --vault-name "${KEYVAULT_NAME}" \
    --name "${KEYVAULT_SECRET_NAME}" \
    --value "Hello\!"

Key Vault Secrets User ロールを、前に作成したユーザー割り当てマネージド ID に割り当てます。この手順では、キーコンテナーからシークレットを読み取るアクセス許可をマネージド ID に付与します。

export IDENTITY_PRINCIPAL_ID=$(az identity show \
    --name "${USER_ASSIGNED_IDENTITY_NAME}" \
    --resource-group "${RESOURCE_GROUP}" \
    --query principalId \
    --output tsv)

az role assignment create \
    --assignee-object-id "${IDENTITY_PRINCIPAL_ID}" \
    --role "Key Vault Secrets User" \
    --scope "${KEYVAULT_RESOURCE_ID}" \
    --assignee-principal-type ServicePrincipal

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

export KEYVAULT_URL="$(az keyvault show \
    --resource-group ${KEYVAULT_RESOURCE_GROUP} \
    --name ${KEYVAULT_NAME} \
    --query properties.vaultUri \
    --output tsv)"

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

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: sample-workload-identity-key-vault
  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: ${KEYVAULT_URL}
      - name: SECRET_NAME
        value: ${KEYVAULT_SECRET_NAME}
  nodeSelector:
    kubernetes.io/os: linux
EOF

すべてのプロパティが webhook によって正しく挿入されているかどうかを確認するには、 kubectl describe コマンドを使用します：

kubectl describe pod sample-workload-identity-key-vault | grep "SECRET_NAME:"

成功すると、出力は次のようになります。

      SECRET_NAME:                 ${KEYVAULT_SECRET_NAME}

ポッドがトークンを取得し、リソースにアクセスできることを確認するには、kubectl ログコマンドを使用します。

kubectl logs sample-workload-identity-key-vault

成功すると、出力は次のようになります。

I0114 10:35:09.795900       1 main.go:63] "successfully got secret" secret="Hello\\!"

重要

Azure RBAC ロールの割り当ては、反映されるまでに最大 10 分かかる場合があります。ポッドがシークレットにアクセスできない場合は、ロールの割り当てが反映されるまで待つ必要があります。詳細については、「Azure RBAC のトラブルシューティング」を参照してください。

ワークロード ID を無効にする

AKS クラスターで有効にされ、構成されている Microsoft Entra ワークロード ID を無効にするには、次のコマンドを実行します:

az aks update \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${CLUSTER_NAME}" \
    --disable-workload-identity

次のステップ

この記事では、Kubernetes クラスターをデプロイし、アプリケーションワークロードでその資格情報による認証を行うための準備としてワークロード ID を使用するように構成しました。これで、アプリケーションをデプロイし、最新バージョンの Azure ID クライアントライブラリでワークロード ID を使用するように構成する準備ができました。最新のクライアントライブラリバージョンを使用するようにアプリケーションを書き換えることができない場合は、ワークロード ID を短期的な移行ソリューションとして使ってマネージド ID を使用して認証するように、アプリケーションポッドを設定できます。

サービスコネクタ統合は、AKS ワークロードと Azure バッキングサービスの接続構成を簡素化するのに役立ちます。認証とネットワーク構成を安全に処理し、ベストプラクティスに従って Azure サービスに接続することができます。詳細については、「ワークロード ID を使用して AKS の Azure OpenAI Service に接続する」と「サービスコネクタの概要」を参照してください。

次の方法で共有

Azure Kubernetes Service (AKS) クラスターでワークロード ID をデプロイして構成する

前提条件

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

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

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

AKS クラスターを作成する

既存の AKS クラスターを更新する

OIDC 発行者 URL を取得する

マネージド ID の作成

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

フェデレーション ID 資格情報を作成する

アプリケーションをデプロイする

Azure Key Vault にアクセスするための権限を付与する

ワークロード ID を無効にする

次のステップ

フィードバック

その他のリソース

次の方法で共有

Azure Kubernetes Service (AKS) クラスターでワークロード ID をデプロイして構成する

前提条件

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

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

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

AKS クラスターを作成する

既存の AKS クラスターを更新する

OIDC 発行者 URL を取得する

マネージド ID の作成

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

フェデレーション ID 資格情報を作成する

アプリケーションをデプロイする

Azure Key Vault にアクセスするための権限を付与する

ワークロード ID を無効にする

次のステップ

フィードバック

その他のリソース

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

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