Azure Arc で有効になっている AKS のアクセスと ID のオプション

適用対象: AKS on Azure Stack HCI 23H2

Kubernetes クラスターへのアクセスは、さまざまな方法で認証、承認、セキュリティ保護、および制御できます。

• Kbernetes ロールベースのアクセス制御 (Kubernetes RBAC)を使用すると、ユーザー、グループ、およびサービス アカウントに、必要な Kubernetes リソースにのみアクセス権を付与できます。
• AKS クラスターが Azure RBAC で有効になっている場合、Microsoft Entra ID と Azure RBAC を使用してセキュリティとアクセス許可の構造をさらに強化できます。

Kubernetes RBAC と Azure RBAC は、クラスター アクセスをセキュリティで保護し、開発者とオペレーターに最低限必要なアクセス許可のみを提供するのに役立ちます。

この記事では、AKS で認証とアクセス許可の割り当てを行うために役立つ中心概念を紹介します。

Kubernetes RBAC

Kubernetes RBAC は、ユーザー操作の詳細なフィルター処理を提供します。 この制御メカニズムより、以下を行います。

• ユーザーまたはユーザー グループに対して、リソースの作成および変更、実行中のアプリケーション ワークロードのログの表示などの操作を行う権限を割り当てます。
• 権限のスコープを、単一の名前空間または AKS クラスター全体に設定できます。
• 権限を定義する "ロール" を作成し、それらのロールを "ロールのバインド" を使用してユーザーに割り当てます。

詳細については、Kubernetes RBAC 認可の使用に関するページをご覧ください。

ロールと ClusterRole

ロール

Kubernetes RBAC を使用してユーザーにアクセス許可を割り当てる前に、ユーザーのアクセス許可を role として定義します。 ロールを使用して Kubernetes 名前空間内のアクセス許可を付与します。

Kubernetes ロールは権限を "付与" します。権限は "拒否" されません。 クラスター全体または特定の名前空間の外部にあるクラスター リソースにアクセス許可を付与するには、 ClusterRolesを使用できます。

ClusterRole

ClusterRole は、特定の名前空間ではなく、クラスター全体のリソースへの権限を付与して適用します。

RoleBinding と ClusterRoleBinding

リソースにアクセス許可を付与するロールを定義したら、 RoleBinding を使用してそれらの Kubernetes RBAC アクセス許可を割り当てます。 AKS クラスターが Microsoft Entra ID と統合されている場合、RoleBinding により、クラスター内でアクションを実行するためのアクセス許可が Microsoft Entra ユーザーに付与されます。 Microsoft Entra ID と Kubernetes RBAC を使用したアクセスの制御に関するページを参照してください

RoleBindings

RoleBindings を使用して、指定した名前空間のユーザーにロールを割り当てます。 RoleBindings を使用すると、1 つの AKS クラスターを論理的に分離でき、ユーザーは各自に割り当てられた名前空間内のアプリケーション リソースにのみアクセスが可能になります。

クラスター全体または特定の名前空間の外部にあるクラスター リソースにロールをバインドするには、 ClusterRoleBindingsを使用します。

ClusterRoleBinding

ClusterRoleBinding では、ロールをユーザーにバインドし、特定の名前空間ではなく、クラスター全体のリソースに適用します。 このアプローチでは、管理者またはサポートエンジニアに対して、AKS クラスター内のすべてのリソースへのアクセス許可を付与できます。

Kubernetes サービス アカウント

"サービス アカウント" は、Kubernetes のプライマリ ユーザー タイプの 1 つです。 Kubernetes API により、サービス アカウントが保持および管理されます。 サービス アカウントの資格情報は Kubernetes シークレットとして格納され、承認されたポッドが API サーバーと通信するために使用できます。 ほとんどの API 要求では、サービス アカウントまたは通常のユーザー アカウント用の認証トークンが提供されします。

通常のユーザー アカウントでは、人間の管理者または開発者は、サービスとプロセスだけではなく、従来のアクセスも許可されます。 Kubernetes は、通常のユーザー アカウントとパスワードを格納するための ID 管理ソリューションを提供していませんが、外部の ID ソリューションを Kubernetes に統合することができます。 AKS クラスターの場合、この統合される ID ソリューションは Microsoft Entra ID です。

Kubernetes の ID オプションの詳細については、「 Kbernetes 認証」を参照してください。

Azure ロールベースのアクセス制御

Azure ロールベースのアクセス制御 (RBAC) は、 Azure Resource Manager 上に構築された承認システムであり、Azure リソースのきめ細かいアクセス管理を提供します。

Azure の RBAC では、適用されるアクセス許可の概要を説明するロール定義を作成します。 次に、特定の "スコープ" の "ロールの割り当て" を使用して、ユーザーまたはグループにこのロール定義を割り当てます。 スコープは、個々のリソース、リソース グループ、またはサブスクリプション全体にすることができます。

詳細については、「Azure ロールベースのアクセス制御 (Azure RBAC) とは」

AKS Arc クラスターを完全に動作させるために必要なアクセス レベルは 2 つあります。

• Azure サブスクリプションの AKS リソースへのアクセス。
  • Azure Arc API で有効になっている AKS を使用して、クラスターのスケーリングまたはアップグレードを制御します。
  • admin の証明書ベースの kubeconfig をプルします。
  • Entra ID が有効な kubeconfig をプルします。
• Kubernetes API へのアクセス。 このアクセスは、次のいずれかによって制御されます。
  • Kubernetes RBAC、または
  • Kubernetes の認可のための Azure RBAC と AKS の統合。

AKS リソースへのアクセスを認可するための Azure RBAC

Azure RBAC を使用すると、ユーザー (または ID) に、1 つ以上のサブスクリプションの AKS リソースに対するきめ細かいアクセスを提供できます。 このコントロール プレーン アクションには、 Azure Kubernetes Service Arc クラスター管理者ロール、 Azure Kubernetes Service Arc クラスター ユーザー ロール、 Azure Kubernetes Service Arc 共同作成者ロールの 3 つのロールがあります。 コンテナーのAzure 組み込みロール 説明されているように、各ロールには異なるアクセス許可スコープ。 たとえば、 Azure Kubernetes Service Arc Contributor ロールを使用して、クラスターを作成、スケーリング、アップグレードできます。 一方、 Azure Kubernetes Service Arc Cluster Admin ロールを持つ別のユーザーには、 admin kubeconfig をプルするアクセス許可しかありません。

Kubernetes 認可用 Azure RBAC

Azure RBAC 統合では、AKS は Kubernetes 承認 Webhook サーバーを使用するため、Azure ロールの定義とロールの割り当てを使用して、Microsoft Entra 統合 Kubernetes クラスターリソースのアクセス許可と割り当てを管理できます。

この図に示すように、Azure RBAC 統合を使用する場合、Kubernetes API に対するすべての要求は、 Microsoft Entra 統合で説明されているのと同じ認証フローに従います。

要求を行う ID が Microsoft Entra ID に存在する場合、Azure は Kubernetes RBAC を使用して要求を承認します。 Id が Microsoft Entra ID (Kubernetes サービス アカウントなど) の外部に存在する場合、承認は通常の Kubernetes RBAC に延期されます。

このシナリオでは、Kubernetes ロールの場合と同じように、Azure RBAC のメカニズムと API を使用してユーザーに組み込みロールを割り当てるか、カスタム ロールを作成します。

この機能を使用すると、サブスクリプション間で AKS リソースへの権限をユーザーに付与するだけでなく、Kubernetes API アクセスを制御する各クラスター内でもロールと権限が構成されます。 このデータ プレーン アクションには、それぞれ独自のアクセス許可スコープを持つ 4 つの組み込みロールがあります 組み込みロール セクションで説明します。

組み込みのロール

Arc で有効になっている AKS には、次の 5 つの組み込みロールが用意されています。 これらは Kubernetes 組み込みロールに似ていますが CRD のサポートなど、いくつかの違いがあります。 各 Azure 組み込みロールで許可されるアクションの完全な一覧をご覧ください。

Microsoft Entra の統合

Microsoft Entra 統合を使って AKS クラスターのセキュリティを強化します。 エンタープライズ ID 管理エクスペリエンスに基づいて構築された Microsoft Entra ID は、コア ディレクトリ サービス、アプリケーション アクセス管理、ID 保護を組み合わせたマルチテナントのクラウドベースのディレクトリおよび ID 管理サービスです。 Microsoft Entra ID を使ってオンプレミスの ID を AKS クラスターに統合することで、アカウント管理とセキュリティのための単一のソースを提供できます。

Microsoft Entra 統合 AKS クラスターを使用すると、名前空間内またはクラスター全体の Kubernetes リソースへのアクセス権をユーザーまたはグループに付与できます。

• kubectl構成コンテキストを取得するには、az aksarc get-credentials コマンドを実行します。
• ユーザーが kubectl を使用して AKS クラスターと対話すると、Microsoft Entra 資格情報を使用してサインインするように求められます。

このアプローチでは、ユーザー アカウントの管理とパスワードの資格情報のために 1 つのソースが提供されます。 ユーザーは、Kubernetes クラスター管理者によって定義されているリソースにのみアクセスできます。

Microsoft Entra 認証は、 OpenID Connect を使用して AKS クラスターに提供されます。 OpenID Connect は、OAuth 2.0 プロトコル上に構築された ID レイヤーです。 OpenID Connect の詳細については、 OpenID Connect のドキュメントを参照してください。 Kubernetes クラスター内から、 Webhook トークン認証 を使用して認証トークンを検証します。 webhook トークン認証は、AKS クラスターの一部として構成および管理されます。

まとめ

次の表に、Microsoft Entra 統合が有効な場合にユーザーが Kubernetes に対して認証する方法の概要を示します。 いずれの場合も、コマンドのシーケンスは次のとおりです。

1. az login を実行して Azure に対して認証を行います。
2. az aksarc get-credentialsを実行して、Kubernetes クラスターの資格情報を.kube/configにダウンロードします。
3. kubectl コマンドを実行します。
   • 最初のコマンドは、次の表に示すように、ブラウザーベースの認証をトリガーして Kubernetes クラスターに対して認証できます。

次のステップ

• Kubernetes の承認のための Kubernetes RBAC の使用を開始するには、Microsoft Entra ID と Kubernetes RBAC を使用した Control アクセスに関するページを参照してください
• Kubernetes 承認用の Azure RBAC の使用を開始するには、「 Kubernetes 承認に Azure RBAC を使用する」を参照してください。