Azure CLI を使用して Azure Active Directory と Azure Kubernetes Service を統合するIntegrate Azure Active Directory with Azure Kubernetes Service using the Azure CLI

Azure Kubernetes Service (AKS) は、ユーザー認証に Azure Active Directory (AD) を使うように構成することができます。Azure Kubernetes Service (AKS) can be configured to use Azure Active Directory (AD) for user authentication. この構成では、Azure AD 認証トークンを使って AKS クラスターにログインできます。In this configuration, you can log into an AKS cluster using an Azure AD authentication token. また、クラスター オペレーターが、ユーザーの ID またはディレクトリ グループ メンバーシップに基づいて、Kubernetes のロールベースのアクセス制御 (RBAC) を構成することもできます。Cluster operators can also configure Kubernetes role-based access control (RBAC) based on a user's identity or directory group membership.

この記事では、必要な Azure AD コンポーネントを作成してから、Azure AD 対応クラスターをデプロイして AKS クラスターで基本的な RBAC ロールを作成する方法について説明します。This article shows you how to create the required Azure AD components, then deploy an Azure AD-enabled cluster and create a basic RBAC role in the AKS cluster. これらの手順は、Azure portal を使用して完了することもできます。You can also complete these steps using the Azure portal.

この記事で使用されているサンプル スクリプトの完成版については、Azure CLI のサンプルの AKS と Azure AD の統合に関するページを参照してください。For the complete sample script used in this article, see Azure CLI samples - AKS integration with Azure AD.

次の制限事項が適用されます。The following limitations apply:

  • Azure AD は、RBAC が有効なクラスターを新しく作成するときにのみ有効にできます。Azure AD can only be enabled when you create a new, RBAC-enabled cluster. 既存の AKS クラスターで Azure AD を有効にすることはできません。You can't enable Azure AD on an existing AKS cluster.

開始する前にBefore you begin

Azure CLI バージョン 2.0.61 以降がインストールされて構成されている必要があります。You need the Azure CLI version 2.0.61 or later installed and configured. バージョンを確認するには、az --version を実行します。Run az --version to find the version. インストールまたはアップグレードする必要がある場合は、Azure CLI のインストールに関するページを参照してください。If you need to install or upgrade, see Install Azure CLI.

一貫性を保ち、この記事のコマンドを実行するのに役立てるため、目的の AKS クラスター名に変数を作成します。For consistency and to help run the commands in this article, create a variable for your desired AKS cluster name. 次の例では、myakscluster という名前を使用しています。The following example uses the name myakscluster:

aksname="myakscluster"

Azure AD 認証の概要Azure AD authentication overview

Azure AD 認証は、OpenID Connect によって AKS クラスターに提供されます。Azure AD authentication is provided to AKS clusters with OpenID Connect. OpenID Connect は、OAuth 2.0 プロトコル上に構築された ID レイヤーです。OpenID Connect is an identity layer built on top of the OAuth 2.0 protocol. OpenID Connect の詳細については、OpenID Connect のドキュメントを参照してください。For more information on OpenID Connect, see the Open ID connect documentation.

Kubernetes クラスターの内部からは、webhook トークン認証を使って認証トークンが確認されます。From inside of the Kubernetes cluster, Webhook Token Authentication is used to verify authentication tokens. webhook トークン認証は、AKS クラスターの一部として構成および管理されます。Webhook token authentication is configured and managed as part of the AKS cluster. Webhook トークン認証の詳細については、Webhook 認証のドキュメントを参照してください。For more information on Webhook token authentication, see the webhook authentication documentation.

注意

AKS 認証用に Azure AD を構成すると、2 つの Azure AD アプリケーションが構成されます。When configuring Azure AD for AKS authentication, two Azure AD applications are configured. この操作は、Azure テナント管理者が行う必要があります。This operation must be completed by an Azure tenant administrator.

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

AKS と統合するには、ID 要求のエンドポイントとして機能する Azure AD アプリケーションを作成して使用します。To integrate with AKS, you create and use an Azure AD application that acts as an endpoint for the identity requests. 必要な最初の Azure AD アプリケーションが、ユーザーの Azure AD グループ メンバーシップを取得します。The first Azure AD application you need gets Azure AD group membership for a user.

az ad app create コマンドを使用してサーバー アプリケーション コンポーネントを作成してから、az ad app update コマンドを使用してそのグループ メンバーシップの要求を更新します。Create the server application component using the az ad app create command, then update the group membership claims using the az ad app update command. 次の例では、「開始する前に」セクションで定義した aksname 変数を使用して変数を作成します。The following example uses the aksname variable defined in the Before you begin section, and creates a variable

# 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 memebership claims
az ad app update --id $serverApplicationId --set groupMembershipClaims=All

ここで、az ad sp create コマンドを使用して、サーバー アプリのサービス プリンシパルを作成します。Now create a service principal for the server app using the az ad sp create command. このサービス プリンシパルは、Azure プラットフォーム内で自身を認証するために使用されます。This service principal is used to authenticate itself within the Azure platform. 次に、az ad sp credential reset コマンドを使用してサービス プリンシパルのシークレットを取得し、次のいずれかのステップで使用するために serverApplicationSecret という名前の変数に割り当てます。Then, get the service principal secret using the az ad sp credential reset command and assign to the variable named serverApplicationSecret for use in one of the following steps:

# 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 には、次のアクションを実行するためのアクセス許可が必要です。The Azure AD needs permissions to perform the following actions:

  • ディレクトリ データの読み取りRead directory data
  • サインインとユーザー プロファイルの読み取りSign in and read user profile

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

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 コマンドを使用して、前の手順で割り当てたアクセス許可をサーバー アプリケーションに付与します。Finally, grant the permissions assigned in the previous step for the server application using the az ad app permission grant command. 現在のアカウントがテナント管理者ではない場合、このステップは失敗します。また、az ad app permission admin-consent を使用して、管理者の同意を別途必要とする可能性のある情報を Azure AD アプリケーションが要求するためのアクセス許可を追加する必要もあります。This step fails if the current account is not a tenant admin. You also need to add permissions for Azure AD application to request information that may otherwise require administrative consent using the az ad app permission admin-consent:

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

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

2 つ目の Azure AD アプリケーションは、Kubernetes CLI (kubectl) を使用してユーザーが AKS クラスターにログインするときに使われます。The second Azure AD application is used when a user logs to the AKS cluster with the Kubernetes CLI (kubectl). このクライアント アプリケーションでは、認証要求をユーザーから取得して、その資格情報とアクセス許可を確認します。This client application takes the authentication request from the user and verifies their credentials and permissions. az ad app create コマンドを使用して、クライアント コンポーネント用に Azure AD アプリを作成します。Create the Azure AD app for the client component using the az ad app create command:

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

az ad sp create コマンドを使用して、クライアント アプリケーション用にサービス プリンシパルを作成します。Create a service principal for the client application using the az ad sp create command:

az ad sp create --id $clientApplicationId

az ad app show コマンドを使用して、サーバー アプリの oAuth2 ID を取得して、2 つのアプリ コンポーネント間の認証フローを許可します。Get the oAuth2 ID for the server app to allow the authentication flow between the two app components using the az ad app show command. この oAuth2 ID は、次のステップで使用されます。This oAuth2 ID is used in the next step.

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

az ad app permission add コマンドを使用して、クライアント アプリケーションおよびサーバー アプリケーション コンポーネントが oAuth2 通信フローを使用するためのアクセス許可を追加します。Add the permissions for the client application and server application components to use the oAuth2 communication flow using the az ad app permission add command. 次に、az ad app permission grant コマンドを使用して、サーバー アプリケーションと通信するためのアクセス許可をクライアント アプリケーションに付与します。Then, grant permissions for the client application to communication with the server application using the az ad app permission grant command:

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

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

2 つの Azure AD アプリケーションが作成されたので、今度は AKS クラスターそのものを作成します。With the two Azure AD applications created, now create the AKS cluster itself. 最初に、az group create コマンドを使用して、リソース グループを作成します。First, create a resource group using the az group create command. 次の例では、米国東部リージョンにリソース グループを作成します。The following example creates the resource group in the EastUS region:

クラスター用にリソース グループを作成します。Create a resource group for the cluster:

az group create --name myResourceGroup --location EastUS

az account show コマンドを使用して Azure サブスクリプションのテナント ID を取得します。Get the tenant ID of your Azure subscription using the az account show command. 次に、az aks create コマンドを使用して AKS クラスターを作成します。Then, create the AKS cluster using the az aks create command. AKS クラスターを作成するコマンドは、サーバーとクライアント アプリケーションの ID、サーバー アプリケーション サービス プリンシパルのシークレット、およびテナント ID を提供します。The command to create the AKS cluster provides the server and client application IDs, the server application service principal secret, and your tenant 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 コマンドを使用して、クラスター管理者資格情報を取得します。Finally, get the cluster admin credentials using the az aks get-credentials command. 次のいずれかのステップで、通常の user クラスターの資格情報を取得して、Azure AD 認証のフローの動作を確認します。In one of the following steps, you get the regular user cluster credentials to see the Azure AD authentication flow in action.

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

RBAC のバインドを作成するCreate RBAC binding

Azure Active Directory アカウントを AKS クラスターで使用できるようにするには、その前にまず、ロールのバインドまたはクラスター ロールのバインドを作成する必要があります。Before an Azure Active Directory account can be used with the AKS cluster, a role binding or cluster role binding needs to be created. 付与するアクセス許可を "ロール" によって定義し、それらを "バインド" によって目的のユーザーに適用します。Roles define the permissions to grant, and bindings apply them to desired users. これらの割り当ては、特定の名前空間に適用することも、クラスター全体に適用することもできます。These assignments can be applied to a given namespace, or across the entire cluster. 詳細については、RBAC 承認の使用に関するページを参照してください。For more information, see Using RBAC authorization.

az ad signed-in-user show コマンドを使用して、現在ログインしているユーザーのユーザー プリンシパル名 (UPN) を取得します。Get the user principal name (UPN) for the user currently logged in using the az ad signed-in-user show command. このユーザー アカウントは、次のステップで Azure AD の統合に対して有効化されます。This user account is enabled for Azure AD integration in the next step.

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

重要

RBAC のバインドを付与するユーザーが同じ Azure AD テナント内にいる場合、userPrincipalName に基づいてアクセス許可を割り当てます。If the user you grant the RBAC binding for is in the same Azure AD tenant, assign permissions based on the userPrincipalName. ユーザーが別の Azure AD テナント内にいる場合、代わりに objectId プロパティをクエリして使用します。If the user is in a different Azure AD tenant, query for and use the objectId property instead.

basic-azure-ad-binding.yaml という名前の YAML マニフェストを作成し、次の内容を貼り付けます。Create a YAML manifest named basic-azure-ad-binding.yaml and paste the following contents. 最後の行で、userPrincipalName_or_objectId を前のコマンドで出力された UPN またはオブジェクト ID に置き換えます。On the last line, replace userPrincipalName_or_objectId with the UPN or object ID output from the previous command:

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 マニフェストのファイル名を指定します。Create the ClusterRoleBinding using the kubectl apply command and specify the filename of your YAML manifest:

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

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

ここで、AKS クラスターの Azure AD 認証の統合をテストしてみましょう。Now let's test the integration of Azure AD authentication for the AKS cluster. 通常のユーザーの資格情報を使用するように kubectl 構成のコンテキストを設定します。Set the kubectl config context to use regular user credentials. このコンテキストは、Azure AD 経由ですべての認証要求を返します。This context passes all authentication requests back through Azure AD.

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

今度は、kubectl get pods コマンドを使用して、すべての名前空間にわたってポッドを表示します。Now use the kubectl get pods command to view pods across all namespaces:

kubectl get pods --all-namespaces

Web ブラウザーを使用して、Azure AD の資格情報を使用して認証するためのサインイン プロンプトが表示されます。You receive a sign in prompt to authenticate using Azure AD credentials using a web browser. 正常に認証を行うと、次の出力例に示されているように、kubectl コマンドによって AKS クラスター内のポッドが表示されます。After you've successfully authenticated, the kubectl command displays the pods in the AKS cluster, as shown in the following example output:

$ 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 用に受信した認証トークンがキャッシュされます。The authentication token received for kubectl is cached. トークンの有効期限が切れたとき、または Kubernetes の構成ファイルが再作成されたときにのみ、サインインを再び求められます。You are only reprompted to sign in when the token has expired or the Kubernetes config file is re-created.

Web ブラウザーを使用して正常にサインインした後に、次の出力例のような承認エラー メッセージが表示される場合は、次の考えられる問題を確認してくださいます。If you see an authorization error message after you've successfully signed in using a web browser as in the following example output, check the following possible issues:

error: You must be logged in to the server (Unauthorized)
  • ユーザー アカウントが同じ Azure AD テナント内にあるかどうかに応じて、適切なオブジェクト ID または UPN を定義した。You defined the appropriate object ID or UPN, depending on if the user account is in the same Azure AD tenant or not.
  • ユーザーが 200 を超えるグループのメンバーにはなっていない。The user is not a member of more than 200 groups.
  • サーバーのアプリケーション登録に定義されているシークレットが、--aad-server-app-secret を使用して構成された値と一致するSecret defined in the application registration for server matches the value configured using --aad-server-app-secret

次の手順Next steps

この記事で示されているコマンドを含む完全なスクリプトについては、AKS サンプル リポジトリの Azure AD 統合スクリプトに関するページを参照してください。For the complete script that contains the commands shown in this article, see the Azure AD integration script in the AKS samples repo.

Azure AD ユーザーとグループを使用してクラスター リソースへのアクセスを制御するには、AKS でロールベースのアクセス制御と Azure AD の ID を使用してクラスター リソースへのアクセスを制限する方法に関するページを参照してください。To use Azure AD users and groups to control access to cluster resources, see Control access to cluster resources using role-based access control and Azure AD identities in AKS.

Kubernetes クラスターをセキュリティで保護する方法の詳細については、AKS でのアクセスと ID オプションに関するページを参照してください。For more information about how to secure Kubernetes clusters, see Access and identity options for AKS).

ID とリソース管理に関するベスト プラクティスについては、AKS での認証と承認のベスト プラクティスに関するページを参照してください。For best practices on identity and resource control, see Best practices for authentication and authorization in AKS.