Azure CLI を使用して Azure Active Directory と Azure Kubernetes Service を統合する (レガシ)

警告

**このドキュメントで説明されている機能 Azure AD 統合 (レガシ) は 2024 年 2 月 29 日に非推奨になります。

AKS には、サーバーまたはクライアント アプリケーションの管理を必要としない、改善された新しい AKS マネージド Azure AD エクスペリエンスが備えられています。 移行する場合は、こちらの手順に従ってください。

Azure Kubernetes Service (AKS) は、ユーザー認証に Azure Active Directory (AD) を使うように構成することができます。 この構成では、Azure AD 認証トークンを使って AKS クラスターにログインできます。 また、クラスター オペレーターが、ユーザーの ID またはディレクトリ グループ メンバーシップに基づいて、Kubernetes のロールベースのアクセス制御 (Kubernetes RBAC) を構成することもできます。

この記事では、必要な Azure AD コンポーネントを作成してから、Azure AD 対応クラスターをデプロイして、AKS クラスターで基本的な Kubernetes ロールを作成する方法について説明します。

この記事で使用されているサンプル スクリプトの完成版については、Azure CLI のサンプルの AKS と Azure AD の統合に関するページにある完全なスクリプトを参照してください。

次の制限事項が適用されます。

  • Azure AD は、Kubernetes RBAC が有効なクラスターでのみ有効にすることができます。
  • Azure AD のレガシ統合は、クラスター作成時にのみ有効にすることができます。

開始する前に

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

https://shell.azure.com にアクセスし、ブラウザーで Cloud Shell を開きます。

一貫性を保ち、この記事のコマンドを実行するのに役立てるため、目的の AKS クラスター名に変数を作成します。 次の例では、myakscluster という名前を使用しています。

aksname="myakscluster"

Azure AD 認証の概要

Azure AD 認証は、OpenID Connect によって AKS クラスターに提供されます。 OpenID Connect は、OAuth 2.0 プロトコル上に構築された ID レイヤーです。 OpenID Connect の詳細については、OpenID Connect のドキュメントを参照してください。

Kubernetes クラスターの内部からは、webhook トークン認証を使って認証トークンが確認されます。 webhook トークン認証は、AKS クラスターの一部として構成および管理されます。 Webhook トークン認証の詳細については、Webhook 認証のドキュメントを参照してください。

Note

AKS 認証用に Azure AD を構成すると、2 つの Azure AD アプリケーションが構成されます。 この操作は、Azure テナント管理者が行う必要があります。

Azure AD サーバー コンポーネントを作成する

AKS と統合するには、ID 要求のエンドポイントとして機能する Azure AD アプリケーションを作成して使用します。 必要な最初の Azure AD アプリケーションが、ユーザーの Azure AD グループ メンバーシップを取得します。

az ad app create コマンドを使用してサーバー アプリケーション コンポーネントを作成してから、az ad app update コマンドを使用してそのグループ メンバーシップの要求を更新します。 次の例では、「開始する前に」セクションで定義した aksname 変数を使用して変数を作成します。

# Create the Azure AD application
serverApplicationId=$(az ad app create \
    --display-name "${aksname}Server" \
    --identifier-uris "https://${aksname}Server" \
    --query appId -o tsv)

# Update the application group membership claims
az ad app update --id $serverApplicationId --set groupMembershipClaims=All

ここで、az ad sp create コマンドを使用して、サーバー アプリのサービス プリンシパルを作成します。 このサービス プリンシパルは、Azure プラットフォーム内で自身を認証するために使用されます。 次に、az ad sp credential reset コマンドを使用してサービス プリンシパルのシークレットを取得し、次のいずれかのステップで使用するために serverApplicationSecret という名前の変数に割り当てます。

# Create a service principal for the Azure AD application
az ad sp create --id $serverApplicationId

# Get the service principal secret
serverApplicationSecret=$(az ad sp credential reset \
    --name $serverApplicationId \
    --credential-description "AKSPassword" \
    --query password -o tsv)

Azure AD サービス プリンシパルには、次のアクションを実行するためのアクセス許可が必要です。

  • ディレクトリ データの読み取り
  • サインインとユーザー プロファイルの読み取り

az ad app permission add コマンドを使用して、これらのアクセス許可を割り当てます。

az ad app permission add \
    --id $serverApplicationId \
    --api 00000003-0000-0000-c000-000000000000 \
    --api-permissions e1fe6dd8-ba31-4d61-89e7-88639da4683d=Scope 06da0dbc-49e2-44d2-8312-53f166ab848a=Scope 7ab1d382-f21e-4acd-a863-ba3e13f7da61=Role

最後に、az ad app permission grant コマンドを使用して、前の手順で割り当てたアクセス許可をサーバー アプリケーションに付与します。 現在のアカウントがテナント管理者ではない場合、このステップは失敗します。また、az ad app permission admin-consent を使用して、管理者の同意を別途必要とする可能性のある情報を Azure AD アプリケーションが要求するためのアクセス許可を追加する必要もあります。

az ad app permission grant --id $serverApplicationId --api 00000003-0000-0000-c000-000000000000
az ad app permission admin-consent --id  $serverApplicationId

Azure AD クライアント コンポーネントを作成する

2 つ目の Azure AD アプリケーションは、Kubernetes CLI (kubectl) を使用してユーザーが AKS クラスターにログインするときに使われます。 このクライアント アプリケーションでは、認証要求をユーザーから取得して、その資格情報とアクセス許可を確認します。 az ad app create コマンドを使用して、クライアント コンポーネント用に Azure AD アプリを作成します。

clientApplicationId=$(az ad app create \
    --display-name "${aksname}Client" \
    --native-app \
    --reply-urls "https://${aksname}Client" \
    --query appId -o tsv)

az ad sp create コマンドを使用して、クライアント アプリケーション用にサービス プリンシパルを作成します。

az ad sp create --id $clientApplicationId

az ad app show コマンドを使用して、サーバー アプリの oAuth2 ID を取得して、2 つのアプリ コンポーネント間の認証フローを許可します。 この oAuth2 ID は、次のステップで使用されます。

oAuthPermissionId=$(az ad app show --id $serverApplicationId --query "oauth2Permissions[0].id" -o tsv)

az ad app permission add コマンドを使用して、クライアント アプリケーションおよびサーバー アプリケーション コンポーネントが oAuth2 通信フローを使用するためのアクセス許可を追加します。 次に、az ad app permission grant コマンドを使用して、サーバー アプリケーションと通信するためのアクセス許可をクライアント アプリケーションに付与します。

az ad app permission add --id $clientApplicationId --api $serverApplicationId --api-permissions ${oAuthPermissionId}=Scope
az ad app permission grant --id $clientApplicationId --api $serverApplicationId

クラスターをデプロイする

2 つの Azure AD アプリケーションが作成されたので、今度は AKS クラスターそのものを作成します。 最初に、az group create コマンドを使用して、リソース グループを作成します。 次の例では、米国東部リージョンにリソース グループを作成します。

クラスター用にリソース グループを作成します。

az group create --name myResourceGroup --location EastUS

az account show コマンドを使用して Azure サブスクリプションのテナント ID を取得します。 次に、az aks create コマンドを使用して AKS クラスターを作成します。 AKS クラスターを作成するコマンドは、サーバーとクライアント アプリケーションの ID、サーバー アプリケーション サービス プリンシパルのシークレット、およびテナント ID を提供します。

tenantId=$(az account show --query tenantId -o tsv)

az aks create \
    --resource-group myResourceGroup \
    --name $aksname \
    --node-count 1 \
    --generate-ssh-keys \
    --aad-server-app-id $serverApplicationId \
    --aad-server-app-secret $serverApplicationSecret \
    --aad-client-app-id $clientApplicationId \
    --aad-tenant-id $tenantId

最後に、az aks get-credentials コマンドを使用して、クラスター管理者資格情報を取得します。 次のいずれかのステップで、通常の user クラスターの資格情報を取得して、Azure AD 認証のフローの動作を確認します。

az aks get-credentials --resource-group myResourceGroup --name $aksname --admin

Kubernetes RBAC バインドの作成

Azure Active Directory アカウントを AKS クラスターで使用できるようにするには、その前にまず、ロールのバインドまたはクラスター ロールのバインドを作成する必要があります。 付与するアクセス許可を "ロール" によって定義し、それらを "バインド" によって目的のユーザーに適用します。 これらの割り当ては、特定の名前空間に適用することも、クラスター全体に適用することもできます。 詳細については、Kubernetes RBAC 認可の使用に関するページを参照してください。

az ad signed-in-user show コマンドを使用して、現在ログインしているユーザーのユーザー プリンシパル名 (UPN) を取得します。 このユーザー アカウントは、次のステップで Azure AD の統合に対して有効化されます。

az ad signed-in-user show --query userPrincipalName -o tsv

重要

Kubernetes RBAC のバインドの付与先となるユーザーが同じ Azure AD テナントに存在する場合は、userPrincipalName に基づいてアクセス許可を割り当てます。 ユーザーが別の Azure AD テナント内にいる場合、代わりに objectId プロパティをクエリして使用します。

basic-azure-ad-binding.yaml という名前の YAML マニフェストを作成し、次の内容を貼り付けます。 最後の行で、userPrincipalName_or_objectId を前のコマンドで出力された UPN またはオブジェクト ID に置き換えます。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: contoso-cluster-admins
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: userPrincipalName_or_objectId

kubectl apply コマンドを使用して ClusterRoleBinding を作成し、YAML マニフェストのファイル名を指定します。

kubectl apply -f basic-azure-ad-binding.yaml

Azure AD でクラスターにアクセスする

ここで、AKS クラスターの Azure AD 認証の統合をテストしてみましょう。 通常のユーザーの資格情報を使用するように kubectl 構成のコンテキストを設定します。 このコンテキストは、Azure AD 経由ですべての認証要求を返します。

az aks get-credentials --resource-group myResourceGroup --name $aksname --overwrite-existing

今度は、kubectl get pods コマンドを使用して、すべての名前空間にわたってポッドを表示します。

kubectl get pods --all-namespaces

Web ブラウザーを使用して、Azure AD の資格情報を使用して認証するためのサインイン プロンプトが表示されます。 正常に認証を行うと、次の出力例に示されているように、kubectl コマンドによって AKS クラスター内のポッドが表示されます。

kubectl get pods --all-namespaces
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code BYMK7UXVD to authenticate.

NAMESPACE     NAME                                    READY   STATUS    RESTARTS   AGE
kube-system   coredns-754f947b4-2v75r                 1/1     Running   0          23h
kube-system   coredns-754f947b4-tghwh                 1/1     Running   0          23h
kube-system   coredns-autoscaler-6fcdb7d64-4wkvp      1/1     Running   0          23h
kube-system   heapster-5fb7488d97-t5wzk               2/2     Running   0          23h
kube-system   kube-proxy-2nd5m                        1/1     Running   0          23h
kube-system   kube-svc-redirect-swp9r                 2/2     Running   0          23h
kube-system   kubernetes-dashboard-847bb4ddc6-trt7m   1/1     Running   0          23h
kube-system   metrics-server-7b97f9cd9-btxzz          1/1     Running   0          23h
kube-system   tunnelfront-6ff887cffb-xkfmq            1/1     Running   0          23h

kubectl 用に受信した認証トークンがキャッシュされます。 トークンの有効期限が切れたとき、または Kubernetes の構成ファイルが再作成されたときにのみ、サインインを再び求められます。

Web ブラウザーを使用して正常にサインインした後に、次の出力例のような承認エラー メッセージが表示される場合は、次の考えられる問題を確認してくださいます。

error: You must be logged in to the server (Unauthorized)
  • ユーザー アカウントが同じ Azure AD テナント内にあるかどうかに応じて、適切なオブジェクト ID または UPN を定義した。
  • ユーザーが 200 を超えるグループのメンバーにはなっていない。
  • サーバーのアプリケーション登録に定義されているシークレットが、--aad-server-app-secret を使用して構成された値と一致する
  • コンピューターにインストールする kubectl のバージョンは必ず、一度に 1 つにしてください。 バージョンが競合すると、承認中に問題が発生する可能性があります。 最新バージョンをインストールするには、az aks install-cli を使用します。

次のステップ

この記事で示されているコマンドを含む完全なスクリプトについては、AKS サンプル リポジトリの Azure AD 統合スクリプトに関するページにある完全なスクリプトを参照してください。

Azure AD ユーザーとグループを使用してクラスター リソースへのアクセスを制御するには、AKS で Kubernetes のロールベースのアクセス制御と Azure AD の ID を使用してクラスター リソースへのアクセスを制限する方法に関するページを参照してください。

Kubernetes クラスターをセキュリティで保護する方法の詳細については、AKS でのアクセスと ID オプションに関するページを参照してください。

ID とリソース管理に関するベスト プラクティスについては、AKS での認証と承認のベスト プラクティスに関するページを参照してください。