Azure Kubernetes Service (AKS) でのアクセスと ID オプションAccess and identity options for Azure Kubernetes Service (AKS)

Kubernetes クラスターでの認証とセキュリティ保護には、さまざまな方法があります。There are different ways to authenticate with and secure Kubernetes clusters. ロールベースのアクセス制御 (RBAC) を使用して、ユーザーまたはグループに対して、ユーザーまたはグループが必要とするリソースのみへのアクセス権を付与できます。Using role-based access controls (RBAC), you can grant users or groups access to only the resources they need. Azure Kubernetes Service (AKS) では、Azure Active Directory を使用して、セキュリティとアクセス許可構造をさらに強化できます。With Azure Kubernetes Service (AKS), you can further enhance the security and permissions structure by using Azure Active Directory. これらの方法は、アプリケーションのワークロードと顧客データを保護するのに役立ちます。These approaches help you secure your application workloads and customer data.

この記事では、AKS で認証とアクセス許可の割り当てを行うために役立つ中心概念を紹介します。This article introduces the core concepts that help you authenticate and assign permissions in AKS:

Kubernetes サービス アカウントKubernetes service accounts

Kubernetes のプライマリ ユーザー タイプの 1 つは、"サービス アカウント" です。One of the primary user types in Kubernetes is a service account. サービス アカウントは、Kubernetes API 内に存在し、Kubernetes API によって管理されます。A service account exists in, and is managed by, the Kubernetes API. サービス アカウントの資格情報は Kubernetes シークレットとして格納され、承認されたポッドが API サーバーと通信するために使用できます。The credentials for service accounts are stored as Kubernetes secrets, which allows them to be used by authorized pods to communicate with the API Server. ほとんどの API 要求では、サービス アカウントまたは通常のユーザー アカウント用の認証トークンが提供されします。Most API requests provide an authentication token for a service account or a normal user account.

通常のユーザー アカウントでは、人間の管理者または開発者は、サービスとプロセスだけではなく、従来のアクセスも許可されます。Normal user accounts allow more traditional access for human administrators or developers, not just services and processes. Kubernetes 自体には、通常のユーザー アカウントとパスワードを格納する ID 管理ソリューションはありません。Kubernetes itself doesn't provide an identity management solution where regular user accounts and passwords are stored. 代わりに、外部 ID ソリューションを Kubernetes に統合できます。Instead, external identity solutions can be integrated into Kubernetes. AKS クラスターの場合、この統合される ID ソリューションは Azure Active Directory です。For AKS clusters, this integrated identity solution is Azure Active Directory.

Kubernetes における ID オプションの詳細については、Kubernetes の認証に関する記事を参照してください。For more information on the identity options in Kubernetes, see Kubernetes authentication.

Azure Active Directory の統合Azure Active Directory integration

Azure Active Directory (AD) の統合によって、AKS クラスターのセキュリティを拡張できます。The security of AKS clusters can be enhanced with the integration of Azure Active Directory (AD). 数十年に及ぶエンタープライズ ID 管理の上に構築された Azure AD は、マルチテナントに対応したクラウドベースのディレクトリであり、中核となるディレクトリ サービス、アプリケーションのアクセス管理機能、および ID 保護機能が統合された ID 管理サービスです。Built on decades of enterprise identity management, Azure AD is a multi-tenant, cloud-based directory, and identity management service that combines core directory services, application access management, and identity protection. Azure AD を使用してオンプレミスの ID を AKS クラスターに統合することで、アカウント管理とセキュリティのための単一のソースを提供できます。With Azure AD, you can integrate on-premises identities into AKS clusters to provide a single source for account management and security.

Azure Active Directory と AKS クラスターの統合

Azure AD が統合された AKS クラスターでは、名前空間内またはクラスター間での Kubernetes リソースへのアクセス権をユーザーまたはグループに付与できます。With Azure AD-integrated AKS clusters, you can grant users or groups access to Kubernetes resources within a namespace or across the cluster. kubectl 構成コンテキストを取得するには、ユーザーは、az aks get-credentials コマンドを実行します。To obtain a kubectl configuration context, a user can run the az aks get-credentials command. その後、ユーザーが kubectl を使用して AKS クラスターにアクセスすると、Azure AD 資格情報でサインインするように求められます。When a user then interacts with the AKS cluster with kubectl, they are prompted to sign in with their Azure AD credentials. このアプローチでは、ユーザー アカウントの管理とパスワードの資格情報のために 1 つのソースが提供されます。This approach provides a single source for user account management and password credentials. ユーザーは、クラスター管理者によって定義されているリソースにのみアクセスできます。The user can only access the resources as defined by the cluster administrator.

AKS クラスターでの Azure AD 認証では、OAuth 2.0 プロトコル上に構築された ID 層である OpenID Connect を使用します。Azure AD authentication in AKS clusters uses OpenID Connect, an identity layer built on top of the OAuth 2.0 protocol. OAuth 2.0 が保護されたリソースにアクセスするためのアクセス トークンの取得と使用を行うメカニズムを定義し、OpenID Connect が OAuth 2.0 承認プロセスの拡張機能として認証を実装します。OAuth 2.0 defines mechanisms to obtain and use access tokens to access protected resources, and OpenID Connect implements authentication as an extension to the OAuth 2.0 authorization process. OpenID Connect の詳細については、OpenID Connect のドキュメントを参照してください。For more information on OpenID Connect, see the Open ID Connect documentation. OpenID Connect を通して Azure AD から取得された認証トークンを検証するには、AKS クラスターでは Kubernetes Webhook トークン認証を使用します。To verify the authentication tokens obtained from Azure AD through OpenID Connect, AKS clusters use Kubernetes Webhook Token Authentication. 詳細については、Webhook トークン認証のドキュメントを参照してください。For more information, see the Webhook Token Authentication documentation.

ロールベースのアクセス制御Role-based access controls (RBAC)

ユーザーが実行できるアクションの詳細なフィルタ処理を行うには、Kubernetes ではロールベースのアクセス制御 (RBAC) を使用します。To provide granular filtering of the actions that users can perform, Kubernetes uses role-based access controls (RBAC). この制御メカニズムを使用して、ユーザーまたはユーザー グループに対して、リソースの作成または変更、実行中のアプリケーション ワークロードのログの表示などの操作を行うアクセス許可を割り当てることができます。This control mechanism lets you assign users, or groups of users, permission to do things like create or modify resources, or view logs from running application workloads. これらのアクセス許可は、付与するスコープを単一の名前空間にすることも、AKS クラスター全体にすることもできます。These permissions can be scoped to a single namespace, or granted across the entire AKS cluster. Kubernetes の RBAC では、アクセス許可を定義する "ロール" を作成し、それらのロールを "ロールのバインド" を使用してユーザーに割り当てます。With Kubernetes RBAC, you create roles to define permissions, and then assign those roles to users with role bindings.

詳細については、RBAC 認可の使用に関する記事を参照してください。For more information, see Using RBAC authorization.

Azure のロールベースのアクセス制御Azure role-based access controls (RBAC)

リソースへのアクセスを制御するために追加された 1 つのメカニズムが、Azure のロールベースのアクセス制御 (RBAC) です。One additional mechanism for controlling access to resources is Azure role-based access controls (RBAC). Kubernetes の RBAC は、AKS クラスター内のリソースに対して機能するように設計され、Azure の RBAC は、Azure サブスクリプション内のリソースに対して機能するように設計されています。Kubernetes RBAC is designed to work on resources within your AKS cluster, and Azure RBAC is designed to work on resources within your Azure subscription. Azure の RBAC では、適用されるアクセス許可の概要を説明するロール定義を作成します。With Azure RBAC, you create a role definition that outlines the permissions to be applied. その後、ユーザーまたはグループに特定の "スコープ" (個々のリソース、リソース グループ、またはサブスクリプション) で有効なロール定義が割り当てられます。A user or group is then assigned this role definition for a particular scope, which could be an individual resource, a resource group, or across the subscription.

詳細については、「Azure RBAC とは」を参照してください。For more information, see What is Azure RBAC?

ロールと ClusterRoleRoles and ClusterRoles

Kubernetes の RBAC を使用してアクセス許可をユーザーに割り当てる前に、これらのアクセス許可を "ロール" として先に定義します。Before you assign permissions to users with Kubernetes RBAC, you first define those permissions as a Role. Kubernetes のロールは、アクセス許可を "付与" します。Kubernetes roles grant permissions. "拒否" というアクセス許可の概念はありません。There is no concept of a deny permission.

ロールは、名前空間内にアクセス許可を付与するために使用されます。Roles are used to grant permissions within a namespace. クラスター全体または特定の名前空間の外部のクラスター リソースへのアクセス許可を付与する必要がある場合は、代わりに ClusterRole を使用できます。If you need to grant permissions across the entire cluster, or to cluster resources outside a given namespace, you can instead use ClusterRoles.

ClusterRole は、リソースへのアクセス許可を付与するのと同じように機能しますが、特定の名前空間ではなく、クラスター全体のリソースに適用できます。A ClusterRole works in the same way to grant permissions to resources, but can be applied to resources across the entire cluster, not a specific namespace.

RoleBinding と ClusterRoleBindingRoleBindings and ClusterRoleBindings

リソースへのアクセス許可を付与するロールを定義したら、RoleBinding を使用して、これらの Kubernetes の RBAC アクセス許可を割り当てます。Once roles are defined to grant permissions to resources, you assign those Kubernetes RBAC permissions with a RoleBinding. AKS クラスターが Azure Active Directory と統合されている場合、バインドは、Azure AD ユーザーが、クラスター内でアクションを実行するためのアクセス許可がどのように付与されるかを示します。If your AKS cluster integrates with Azure Active Directory, bindings are how those Azure AD users are granted permissions to perform actions within the cluster.

ロールのバインドを使用して、特定の名前空間に対してロールを割り当てます。Role bindings are used to assign roles for a given namespace. このアプローチによって、1 つの AKS クラスターを論理的に分離でき、ユーザーは各自に割り当てられた名前空間内のアプリケーション リソースにのみアクセスが可能になります。This approach lets you logically segregate a single AKS cluster, with users only able to access the application resources in their assigned namespace. クラスター全体または特定の名前空間の外部のクラスター リソースにロールをバインドする必要がある場合は、代わりに ClusterRoleBinding を使用できます。If you need to bind roles across the entire cluster, or to cluster resources outside a given namespace, you can instead use ClusterRoleBindings.

ClusterRoleBinding は、ユーザーにロールをバインドするのと同じように機能しますが、特定の名前空間ではなく、クラスター全体のリソースに適用できます。A ClusterRoleBinding works in the same way to bind roles to users, but can be applied to resources across the entire cluster, not a specific namespace. このアプローチでは、管理者またはサポートエンジニアに対して、AKS クラスター内のすべてのリソースへのアクセス許可を付与できます。This approach lets you grant administrators or support engineers access to all resources in the AKS cluster.

次の手順Next steps

Azure AD と Kubernetes の RBAC の使用を開始するには、Azure Active Directory と AKS の統合に関する記事を参照してください。To get started with Azure AD and Kubernetes RBAC, see Integrate Azure Active Directory with AKS.

関連するベスト プラクティスについては、AKS の認証と認可のベスト プラクティスに関する記事を参照してください。For associated best practices, see Best practices for authentication and authorization in AKS.

Kubernetes と AKS の中心概念の追加情報については、次の記事を参照してください。For additional information on core Kubernetes and AKS concepts, see the following articles: