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

Kubernetes クラスターに対する認証の実行、アクセス制御と認可、セキュリティ保護には、さまざまな方法があります。There are different ways to authenticate, control access/authorize and secure Kubernetes clusters. Kubernetes のロールベースのアクセス制御 (Kubernetes RBAC) を使用して、ユーザー、グループ、サービス アカウントに対し、必要とするリソースのみへのアクセス権を付与できます。Using Kubernetes role-based access control (Kubernetes RBAC), you can grant users, groups, and service accounts access to only the resources they need. Azure Kubernetes Service (AKS) では、Azure Active Directory と Azure RBAC を使用して、セキュリティとアクセス許可構造をさらに強化できます。With Azure Kubernetes Service (AKS), you can further enhance the security and permissions structure by using Azure Active Directory and Azure RBAC. これらの方法を使用すると、クラスターへのアクセスをセキュリティで保護し、開発者やオペレーターに必要最低限のアクセス許可のみを与えることができます。These approaches help you secure your cluster access and provide only the minimum required permissions to developers and operators.

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

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

ユーザーが行うことのできるアクションの詳細なフィルター処理を提供するために、Kubernetes では Kubernetes ロールベースのアクセス制御 (Kubernetes RBAC) が使用されます。To provide granular filtering of the actions that users can do, Kubernetes uses Kubernetes role-based access control (Kubernetes 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.

詳細については、Kubernetes RBAC 認可の使用に関するページをご覧ください。For more information, see Using Kubernetes RBAC authorization.

ロールと 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's 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 ユーザーにどのように付与されるかを示します。方法については、Kubernetes ロールベースのアクセス制御と Azure Active Directory ID を使用したクラスター リソースへのアクセスの制限に関する記事をご覧ください。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, see how in Control access to cluster resources using Kubernetes role-based access control and Azure Active Directory identities.

ロールのバインドを使用して、特定の名前空間に対してロールを割り当てます。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.

注意

Microsoft/AKS によって実行されるクラスター アクションはすべて、ユーザーの同意を得たうえで、組み込みの Kubernetes ロール aks-service と組み込みのロール バインド aks-service-rolebinding に基づいて行われます。Any cluster actions taken by Microsoft/AKS are made with user consent under a built-in Kubernetes role aks-service and built-in role binding aks-service-rolebinding. このロールにより、AKS はクラスターの問題のトラブルシューティングや診断を行うことができますが、アクセス許可の変更や、ロールやロール バインドの作成など、高い特権を必要とする操作を行うことはできません。This role enables AKS to troubleshoot and diagnose cluster issues, but can't modify permissions nor create roles or role bindings, or other high privilege actions. ロールによるアクセスは、アクティブなサポート チケットで Just-In-Time (JIT) アクセスを使用する場合にのみ有効になります。Role access is only enabled under active support tickets with just-in-time (JIT) access. 詳細については、AKS サポート ポリシーに関する記事を参照してください。Read more about AKS support policies.

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're 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.

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 と API サーバーWebhook and API server

Webhook と API サーバーの認証フロー

上の図に示すように、API サーバーでは、AKS Webhook サーバーが呼び出されて、次の手順が実行されます。As shown in the graphic above, the API server calls the AKS webhook server and performs the following steps:

  1. OAuth 2.0 デバイス承認許可フローでユーザーをサインインさせるため、kubectl では Azure AD クライアント アプリケーションが使用されます。The Azure AD client application is used by kubectl to sign in users with OAuth 2.0 device authorization grant flow.
  2. Azure AD では、access_token、id_token、refresh_token が提供されます。Azure AD provides an access_token, id_token, and a refresh_token.
  3. ユーザーは、kubeconfig からの access_token を使用して kubectl に対する要求を行います。The user makes a request to kubectl with an access_token from kubeconfig.
  4. kubectl では、APIServer に access_token が送信されます。Kubectl sends the access_token to APIServer.
  5. API サーバーは、検証を実行するように Auth Webhook サーバーで構成されます。The API Server is configured with the Auth WebHook Server to perform validation.
  6. 認証 Webhook サーバーでは、Azure AD の公開署名キーをチェックすることによって、JSON Web トークン署名が有効であることが確認されます。The authentication webhook server confirms the JSON Web Token signature is valid by checking the Azure AD public signing key.
  7. サーバー アプリケーションでは、ユーザーが指定した資格情報を使用して、MS Graph API からログインしたユーザーのグループ メンバーシップが照会されます。The server application uses user-provided credentials to query group memberships of the logged-in user from the MS Graph API.
  8. 応答は、アクセス トークンのユーザー プリンシパル名 (UPN) 要求や、オブジェクト ID に基づくユーザーのグループ メンバーシップなどのユーザー情報と共に APIServer に送信されます。A response is sent to the APIServer with user information such as the user principal name (UPN) claim of the access token, and the group membership of the user based on the object ID.
  9. API では、Kubernetes のロールと RoleBinding に基づいて認可の決定が実行されます。The API performs an authorization decision based on the Kubernetes Role/RoleBinding.
  10. 認可されると、API サーバーから kubectl に応答が返されます。Once authorized, the API server returns a response to kubectl.
  11. kubectl からユーザーにフィードバックが提供されます。Kubectl provides feedback to the user.

AKS と AAD を統合する方法については、こちらを参照してください。Learn how to integrate AKS with AAD here.

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

Azure RBAC は Azure Resource Manager 上に構築された承認システムであり、Azure リソースに対するアクセスをきめ細かく管理できます。Azure RBAC is an authorization system built on Azure Resource Manager that provides fine-grained access management of Azure resources.

Azure の RBAC が Azure サブスクリプション内のリソースに対して機能するように設計されているのに対し、Kubernetes の RBAC は AKS クラスター内の Kubernetes リソースに対して機能するように設計されています。Azure RBAC is designed to work on resources within your Azure subscription while Kubernetes RBAC is designed to work on Kubernetes resources within your AKS cluster.

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 via a role assignment for a particular scope, which could be an individual resource, a resource group, or across the subscription.

詳細については、「Azure ロールベースのアクセス制御 (Azure RBAC) とはFor more information, see What is Azure role-based access control (Azure RBAC)?

AKS クラスターを完全に運用するには、次の 2 つのレベルのアクセスが必要です。There are two levels of access needed to fully operate an AKS cluster:

  1. Azure サブスクリプションの AKS リソースへのアクセスAccess the AKS resource in your Azure subscription. このプロセスでは、AKS API を使用してクラスターのスケーリングやアップグレードを制御したり、kubeconfig をプルしたりすることができます。This process allows you to control things scaling or upgrading your cluster using the AKS APIs as well as pull your kubeconfig.
  2. Kubernetes API へのアクセス。Access to the Kubernetes API. このアクセスは、Kubernetes RBAC (従来) によって、または Kubernetes の認可のための Azure RBAC と AKS の統合によって制御されますThis access is controlled either by Kubernetes RBAC (traditionally) or by integrating Azure RBAC with AKS for Kubernetes authorization

AKS リソースへのアクセスを認可するための Azure RBACAzure RBAC to authorize access to the AKS resource

Azure RBAC を使用すると、ユーザー (または ID) に、1 つ以上のサブスクリプションの AKS リソースに対するきめ細かいアクセスを提供できます。With Azure RBAC, you can provide your users (or identities) with granular access to AKS resources across one or more subscriptions. たとえば、Azure Kubernetes Service 共同作成者ロールを使用すると、クラスターのスケーリングやアップグレードなどの操作を実行できます。For example, you could have the Azure Kubernetes Service Contributor role that allows you to do actions like scale and upgrade your cluster. 別のユーザーには Azure Kubernetes Service クラスター管理者ロールを割り当てて、管理者の kubeconfig をプルするアクセス許可のみを付与できます。While another user could have the Azure Kubernetes Service Cluster Admin role that only gives permission to pull the Admin kubeconfig.

または、ユーザーに一般的な共同作成者ロールを付与することもできます。これには、アクセス許可自体の管理を除き、上記のアクセス許可および AKS リソースで可能なすべての操作が含まれます。Alternatively you could give your user the general Contributor role, which would encompass the above permissions and every action possible on the AKS resource with the exception of managing permissions itself.

Kubernetes API へのアクセスを提供する kubeconfig ファイルへのアクセスを、Azure RBAC を使用してセキュリティで保護する方法の詳細については、こちらを参照してください。See more how to use Azure RBAC to secure the access to the kubeconfig file that gives access to the Kubernetes API here.

Kubernetes 認可に対する Azure RBAC (プレビュー)Azure RBAC for Kubernetes Authorization (Preview)

Azure RBAC 統合では、AKS で Kubernetes 認可 Webhook サーバーが使用されることにより、ユーザーは、Azure ロールの定義とロールの割り当てを使用して、Azure AD と統合された K8s クラスター リソースのアクセス許可と割り当てを管理できます。With the Azure RBAC integration, AKS will use a Kubernetes Authorization webhook server to enable you to manage permissions and assignments of Azure AD-integrated K8s cluster resources using Azure role definition and role assignments.

Kubernetes 認可に対する Azure RBAC のフロー

上の図で示されているように、Azure RBAC 統合を使用すると、Kubernetes API に対するすべての要求は、「Azure Active Directory の統合」セクションで説明されているものと同じ認証フローに従います。As shown on the above diagram, when using the Azure RBAC integration all requests to the Kubernetes API will follow the same authentication flow as explained on the Azure Active integration section.

ただし、その後は、認可を Kubernetes RBAC だけに依存するのではなく、要求を行った ID が AAD に存在する限り、要求は Azure によって認可されます。But after that, instead of solely relying on Kubernetes RBAC for Authorization, the request is actually going to be authorized by Azure, as long as the identity that made the request exists in AAD. ID が AAD に存在しない場合 (たとえば、Kubernetes サービス アカウント)、Azure RBAC は開始されず、通常の Kubernetes RBAC になります。If the identity doesn't exist in AAD, for example a Kubernetes service account, then the Azure RBAC won't kick in, and it will be the normal Kubernetes RBAC.

このシナリオでは、4 つの組み込みロールのいずれかをユーザーに付与できます。または、Kubernetes ロールの場合と同じようにカスタム ロールを作成することもできますが、この場合は Azure RBAC のメカニズムと API を使用します。In this scenario you could give users one of the four built-in roles, or create custom roles as you would do with Kubernetes roles but in this case using the Azure RBAC mechanisms and APIs.

この機能を使用すると、たとえば、サブスクリプション間で AKS リソースへのアクセス許可をユーザーに付与するだけでなく、Kubernetes API へのアクセスを制御する各クラスター内でのロールとアクセス許可を設定してユーザーに付与することができます。This feature will allow you to, for example, not only give users permissions to the AKS resource across subscriptions but set up and give them the role and permissions that they will have inside each of those clusters that controls the access to the Kubernetes API. たとえば、Azure Kubernetes Service RBAC Viewer ロールをサブスクリプションのスコープで付与することができ、それを受け取ったユーザーは、すべてのクラスターのすべての Kubernetes オブジェクトを一覧表示して取得することができますが、変更することはできません。For example, you can grant the Azure Kubernetes Service RBAC Viewer role on the subscription scope and its recipient will be able to list and get all Kubernetes objects from all clusters, but not modify them.

組み込みのロールBuilt-in roles

AKS には、次の 4 つの組み込みロールがあります。AKS provides the following four built-in roles. これらは、Kubernetes の組み込みロールに似ていますが、CRD のサポートなど、いくつかの違いがあります。They are similar to the Kubernetes built-in roles but with a few differences like supporting CRDs. 各組み込みロールで許可されるアクションの完全な一覧については、こちらを参照してください。For the full list of actions allowed by each built in role please see here.

RoleRole 説明Description
Azure Kubernetes Service RBAC ビューアーAzure Kubernetes Service RBAC Viewer 名前空間内のほとんどのオブジェクトを表示するための読み取り専用アクセスが許可されます。Allows read-only access to see most objects in a namespace. ロールまたはロールのバインドを表示することはできません。It doesn't allow viewing roles or role bindings. このロールでは、Secrets の表示は許可されません。これは、Secrets の内容を読み取ると、名前空間の ServiceAccount 資格情報にアクセスでき、それにより名前空間の任意の ServiceAccount として API にアクセスできるようになるためです (特権エスカレーションの形式)This role doesn't allow viewing Secrets, since reading the contents of Secrets enables access to ServiceAccount credentials in the namespace, which would allow API access as any ServiceAccount in the namespace (a form of privilege escalation)
Azure Kubernetes Service RBAC ライターAzure Kubernetes Service RBAC Writer 名前空間内のほとんどのオブジェクトに対する読み取りと書き込みのアクセスが許可されます。Allows read/write access to most objects in a namespace. このロールでは、ロールまたはロールのバインドを表示または変更することはできません。This role doesn't allow viewing or modifying roles or role bindings. ただし、このロールを使用すると、Secrets にアクセスし、名前空間内の任意の ServiceAccount としてポッドを実行できるので、名前空間内の任意の ServiceAccount の API アクセス レベルを取得するために使用できます。However, this role allows accessing Secrets and running Pods as any ServiceAccount in the namespace, so it can be used to gain the API access levels of any ServiceAccount in the namespace.
Azure Kubernetes Service RBAC 管理者Azure Kubernetes Service RBAC Admin 名前空間内で付与されることが意図された、管理者アクセスが許可されます。Allows admin access, intended to be granted within a namespace. 名前空間内でロールおよびロール バインドを作成する能力など、名前空間 (またはクラスター スコープ) 内のほとんどのリソースへの読み取りおよび書き込みアクセスが許可されます。Allows read/write access to most resources in a namespace (or cluster scope), including the ability to create roles and role bindings within the namespace. このロールでは、リソース クォータまたは名前空間自体への書き込みアクセスは許可されません。This role doesn't allow write access to resource quota or to the namespace itself.
Azure Kubernetes Service RBAC クラスター管理者Azure Kubernetes Service RBAC Cluster Admin 任意のリソースに対して任意のアクションを実行できるスーパー ユーザー アクセスが許可されます。Allows super-user access to perform any action on any resource. これにより、クラスター内およびすべての名前空間内のすべてのリソースを完全に制御できます。It gives full control over every resource in the cluster and in all namespaces.

Kubernetes 認可に Azure RBAC を有効にする方法については、こちらを参照してくださいTo learn how to enable Azure RBAC for Kubernetes authorization, read here.

次のステップNext steps

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