Azure Kubernetes Service (AKS) の認証と認可のベスト プラクティスBest practices for authentication and authorization in Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) でクラスターをデプロイし、保守管理するとき、リソースやサービスへのアクセスを管理する方法を実装する必要があります。As you deploy and maintain clusters in Azure Kubernetes Service (AKS), you need to implement ways to manage access to resources and services. このような制御がなければ、必要としないリソースやサービスへのアクセスがアカウントに与えられることがあります。Without these controls, accounts may have access to resources and services they don't need. また、変更を行う際に使用された資格情報セットを追跡することが難しくなる場合があります。It can also be hard to track which set of credentials were used to make changes.

このベスト プラクティス記事では、クラスター オペレーターが AKS クラスターのアクセスと ID を管理する方法について取り上げます。This best practices article focuses on how a cluster operator can manage access and identity for AKS clusters. この記事では、次のことについて説明します。In this article, you learn how to:

  • Azure Active Directory (AAD) を利用して AKS クラスター ユーザーを認証するAuthenticate AKS cluster users with Azure Active Directory
  • ロールベースのアクセス制御 (RBAC) を使用し、リソースへのアクセスを制御するControl access to resources with role-based access controls (RBAC)
  • マネージド ID を使用し、他のサービスで認証するUse a managed identity to authenticate themselves with other services

Azure Active Directory を使用するUse Azure Active Directory

ベスト プラクティス ガイダンス - Azure AD 統合で AKS クラスターをデプロイします。Best practice guidance - Deploy AKS clusters with Azure AD integration. Azure AD を使用することで、ID 管理コンポーネントが一元化されます。Using Azure AD centralizes the identity management component. ユーザー アカウントまたはグループの状態が変わると、AKS クラスターにアクセスしたとき、その変更内容が自動的に更新されます。Any change in user account or group status is automatically updated in access to the AKS cluster. ユーザーまたはグループに必要最低限のアクセス許可を与える場合、次のセクションで説明する Roles または ClusterRoles と Bindings を使用します。Use Roles or ClusterRoles and Bindings, as discussed in the next section, to scope users or groups to least amount of permissions needed.

お使いの Kubernetes クラスターの開発者とアプリケーション所有者はさまざまなリソースへのアクセスを必要とします。The developers and application owners of your Kubernetes cluster need access to different resources. Kubernetes からは、リソースを使用するユーザーとユーザーに使用されるリソースを制御する ID 管理ソリューションが提供されません。Kubernetes doesn't provide an identity management solution to control which users can interact with what resources. 代わりに、一般的には自分のクラスターと既存の ID ソリューションを統合します。Instead, you typically integrate your cluster with an existing identity solution. Azure Active Directory (AD) では企業対応の ID 管理ソリューションが提供されます。また、AD は AKS クラスターと統合できます。Azure Active Directory (AD) provides an enterprise-ready identity management solution, and can integrate with AKS clusters.

Azure AD 統合クラスターを AKS を使用するとき、リソースへのアクセス許可を定義する Roles または ClusterRoles を作成します。With Azure AD-integrated clusters in AKS, you create Roles or ClusterRoles that define access permissions to resources. 作成後、Azure AD のユーザーまたはグループにロールをバインドします。You then bind the roles to users or groups from Azure AD. このような Kubernetes のロールベースのアクセス制御 (RBAC) については、次のセクションで説明します。These Kubernetes role-based access controls (RBAC) are discussed in the next section. Azure AD の統合とリソースへのアクセスの制御方法をまとめたのが次の図です。The integration of Azure AD and how you control access to resources can be seen in the following diagram:

Azure Active Directory と AKS の統合のためのクラスターレベルの認証

  1. 開発者が Azure AD を利用して認証します。Developer authenticates with Azure AD.
  2. Azure AD トークン発行エンドポイントがアクセス トークンを発行します。The Azure AD token issuance endpoint issues the access token.
  3. 開発者は、kubectl create pod など、Azure AD トークンを使用して操作を実行します。The developer performs an action using the Azure AD token, such as kubectl create pod
  4. Kubernetes では Azure Active Directory を利用してトークンの有効性が検証され、開発者のグループ メンバーシップが取得されます。Kubernetes validates the token with Azure Active Directory and fetches the developer's group memberships.
  5. Kubernetes のロールベースのアクセス制御 (RBAC) とクラスター ポリシーが適用されます。Kubernetes role-based access control (RBAC) and cluster policies are applied.
  6. 先の Azure AD グループ メンバーシップの検証、Kubernetes RBAC、ポリシーに基づき、開発者の要求が通過するか、却下されます。Developer's request is successful or not based on previous validation of Azure AD group membership and Kubernetes RBAC and policies.

Azure AD を使用する AKS クラスターを作成する方法については、「Azure Active Directory と Azure Kubernetes Service を統合する」を参照してください。To create an AKS cluster that uses Azure AD, see Integrate Azure Active Directory with AKS.

ロールベースのアクセス制御 (RBAC) を使用するUse role-based access controls (RBAC)

ベスト プラクティス ガイダンス - Kubernetes RBAC を使用し、クラスターのリソースに対するユーザーまたはグループのアクセス許可を定義します。Best practice guidance - Use Kubernetes RBAC to define the permissions that users or groups have to resources in the cluster. 必要最低限のアクセス許可を割り当てるロールとバインディングを作成します。Create roles and bindings that assign the least amount of permissions required. ユーザーの状態やグループ メンバーシップが変わったとき、それが自動的に更新されるように、また、クラスター リソースへのアクセスが最新の状態になるように、Azure AD と統合します。Integrate with Azure AD so any change in user status or group membership is automatically updated and access to cluster resources is current.

Kubernetes では、クラスターのリソースへのアクセスを細かく制御できます。In Kubernetes, you can provide granular control of access to resources in the cluster. アクセス許可はクラスター レベルで定義するか、特定の名前空間に定義できます。Permissions can be defined at the cluster level, or to specific namespaces. 管理できるリソースとアクセス許可の種類を定義できます。You can define what resources can be managed, and with what permissions. このようなロールは、バインディングが与えられているユーザーまたはグループに適用されます。These roles are the applied to users or groups with a binding. RolesClusterRolesBindings に関する詳細については、「Azure Kubernetes Service (AKS) でのアクセスと ID オプション」を参照してください。For more information about Roles, ClusterRoles, and Bindings, see Access and identity options for Azure Kubernetes Service (AKS).

たとえば、finance-app という名前の名前空間にあるリソースに完全アクセスできる Role を作成できます。次のサンプル YAML マニフェストをご覧ください。As an example, you can create a Role that grants full access to resources in the namespace named finance-app, as shown in the following example YAML manifest:

kind: Role
  name: finance-app-full-access-role
  namespace: finance-app
- apiGroups: [""]
  resources: ["*"]
  verbs: ["*"]

次に、Azure AD ユーザー を RoleBinding にバインドする RoleBinding が作成されます。次の YAML マニフェストをご覧ください。A RoleBinding is then created that binds the Azure AD user to the RoleBinding, as shown in the following YAML manifest:

kind: RoleBinding
  name: finance-app-full-access-role-binding
  namespace: finance-app
- kind: User
  kind: Role
  name: finance-app-full-access-role
  apiGroup: が AKS クラスターに対して認証されると、finance-app 名前空間に対する完全アクセスが与えられます。When is authenticated against the AKS cluster, they have full permissions to resources in the finance-app namespace. このように、リソースへのアクセスが論理的に分離されて制御されます。In this way, you logically separate and control access to resources. Kubernetes RBAC は、前のセクションで説明したように、Azure AD 統合との連動で使用してください。Kubernetes RBAC should be used in conjunction with Azure AD-integration, as discussed in the previous section.

RBAC で Azure AD グループを使用して Kubernetes クラスター リソースへのアクセスを制御するには、「Control access to cluster resources using role-based access controls and Azure Active Directory identities in AKS」 (AKS でロールベースのアクセス制御と Azure AD の ID を使用してクラスター リソースへのアクセス制御する) を参照してください。To see how to use Azure AD groups to control access to Kubernetes resources using RBAC, see Control access to cluster resources using role-based access controls and Azure Active Directory identities in AKS.

ポッド ID を使用するUse pod identities

ベスト プラクティス ガイダンス - ポッドやコンテナー イメージ内で固定の資格情報を使用しないでください。開示や悪用の危険にさらされます。Best practice guidance - Don't use fixed credentials within pods or container images, as they are at risk of exposure or abuse. 代わりに、ポッド ID を使用し、中央の Azure AD ID ソリューションによるアクセスを自動要求してください。Instead, use pod identities to automatically request access using a central Azure AD identity solution. ポッド ID は、Linux のポッドおよびコンテナー イメージのみでの使用を目的としています。Pod identities is intended for use with Linux pods and container images only.

Cosmos DB、Key Vault、Blob Storage など、他の Azure サービスへのアクセスをポッドが必要とするとき、ポッドはアクセス資格情報を必要とします。When pods need access to other Azure services, such as Cosmos DB, Key Vault, or Blob Storage, the pod needs access credentials. このような資格情報はコンテナー イメージで定義されたり、Kubernetes シークレットとして挿入されたりできますが、手動で作成し、割り当てる必要があります。These access credentials could be defined with the container image or injected as a Kubernetes secret, but need to be manually created and assigned. 多くの場合、資格情報はポッド全体で再利用されます。定期的なローテーションはありません。Often, the credentials are reused across pods, and aren't regularly rotated.

Azure リソース (関連付けられた AKS オープン ソース プロジェクトとして現在実装されている) 用のマネージド ID によって、Azure AD を介してサービスへのアクセスを自動的に要求できます。Managed identities for Azure resources (currently implemented as an associated AKS open source project) let you automatically request access to services through Azure AD. ポッドの資格情報は手動定義しません。代わりに、アクセス トークンをリアルタイムで要求します。アクセス トークンを利用し、割り当てられたサービスにのみアクセスできます。You don't manually define credentials for pods, instead they request an access token in real time, and can use it to access only their assigned services. AKS では、2 つのコンポーネントがクラスター オペレーターによってデプロイされ、ポッドはマネージド ID を利用できます。In AKS, two components are deployed by the cluster operator to allow pods to use managed identities:

  • Node Management Identity (NMI) サーバーは、AKS クラスターの各ノードで DaemonSet として実行されるポッドです。The Node Management Identity (NMI) server is a pod that runs as a DaemonSet on each node in the AKS cluster. NMI サーバーは、Azure サービスへのポッド要求を待ち受けます。The NMI server listens for pod requests to Azure services.
  • Managed Identity Controller (MIC) は Kubernetes API サーバーにクエリを実行する許可が与えられた中央ポッドであり、ポッドに該当する Azure ID マッピングの存在を確認します。The Managed Identity Controller (MIC) is a central pod with permissions to query the Kubernetes API server and checks for an Azure identity mapping that corresponds to a pod.

ポッドが Azure サービスへのアクセスを要求すると、ネットワーク ルールによって Node Management Identity (NMI) サーバーにトラフィックがリダイレクトされます。When pods request access to an Azure service, network rules redirect the traffic to the Node Management Identity (NMI) server. NMI サーバーはリモート アドレスに基づいて Azure サービスへのアクセスを要求するポッドであり、Managed Identity Controller (MIC) にクエリを実行します。The NMI server identifies pods that request access to Azure services based on their remote address, and queries the Managed Identity Controller (MIC). MIC は AKS クラスターで Azure ID マッピングの存在を確認し、NMI サーバーはポッドの ID マッピングに基づいて Azure Active Directory (AD) にアクセス トークンを要求します。The MIC checks for Azure identity mappings in the AKS cluster, and the NMI server then requests an access token from Azure Active Directory (AD) based on the pod's identity mapping. Azure AD が与える NMI サーバーへのアクセスがポッドに返されます。Azure AD provides access to the NMI server, which is returned to the pod. ポッドはこのアクセス トークンを利用し、Azure のサービスへのアクセスを要求できます。This access token can be used by the pod to then request access to services in Azure.

次の例では、開発者はマネージド ID を利用して Azure SQL Server インスタンスへのアクセスを要求するポッドを作成しています。In the following example, a developer creates a pod that uses a managed identity to request access to an Azure SQL Server instance:

ポッド ID によって、他のサービスへのアクセスをポッドは自動要求できます。

  1. クラスター オペレーターはまず、ポッドがサービスへのアクセスを要求するとき、ID のマッピングに使用できるサービス アカウントを作成します。Cluster operator first creates a service account that can be used to map identities when pods request access to services.
  2. NMI サーバーと MIC がデプロイされ、アクセス トークンのポッド要求を Azure AD に中継します。The NMI server and MIC are deployed to relay any pod requests for access tokens to Azure AD.
  3. 開発者は、NMI サーバー経由でアクセス トークンを要求するポッドをマネージド ID と共にデプロイします。A developer deploys a pod with a managed identity that requests an access token through the NMI server.
  4. トークンがポッドに返され、Azure SQL Server インスタンスにアクセスするために使用されます。The token is returned to the pod and used to access an Azure SQL Server instance.


マネージド ポッド ID はオープン ソース プロジェクトです。これは Azure テクニカル サポートではサポートされません。Managed pod identities is an open source project, and is not supported by Azure technical support.

ポッド ID を使用する方法については、Kubernetes アプリケーションのための Azure Active Directory ID に関するページを参照してください。To use pod identities, see Azure Active Directory identities for Kubernetes applications.

次の手順Next steps

このベスト プラクティスの記事では、クラスターとリソースの認証と認可について取り上げました。This best practices article focused on authentication and authorization for your cluster and resources. これらのベスト プラクティスのいくつかを実装する場合は、次の記事を参照してください。To implement some of these best practices, see the following articles:

AKS でのクラスター操作の詳細については、次のベスト プラクティスを参照してください。For more information about cluster operations in AKS, see the following best practices: