AKS では、5 つの異なるシナリオで ID が使用されます。 各シナリオは異なる質問に回答し、独自の構成モデルを持っています。 この記事では、それぞれについて簡単に紹介し、詳細なドキュメントへのリンクを示しています。
AKS の 5 つの ID シナリオ
| Scenario | これが回答する質問 | 詳細なドキュメント |
|---|---|---|
| A. Kubernetes コントロールプレイン認証 | Kubernetes API を呼び出しているのは誰ですか? | クラスター認証の概念、 外部 ID プロバイダー |
| B. Kubernetes コントロール プレーンの承認 | Kubernetes API に対して認証されると、呼び出し元は何を実行できますか? | クラスター承認の概念 |
| C. AKS リソース承認 (Azure Resource Manager) | AKS リソースに対して、kubeconfigのプルなどの Azure レベルの操作を実行できるのは誰ですか？ |
クラスター構成ファイル、Azure 組み込みロールへのアクセスを制限する |
| D: クラスター ID (Azure →クラスター) | AKS クラスターは、ユーザーに代わってリソースを管理するために Azure でどのように動作しますか? | AKS のマネージド アイデンティティ |
| E. ワークロード ID (ポッド → Azure) | ポッドは、Key Vault や Storage などの Azure サービスに対してどのように認証されますか? | Microsoft Entra Workload IDの概要 |
この記事の残りの部分では、各シナリオについて簡単に説明します。
A. Kubernetes コントロール プレーン認証
Kubernetes コントロール プレーン認証は、Kubernetes API サーバーを呼び出すユーザーまたはサービス プリンシパルの ID を確立します。 AKS では、次の機能がサポートされます。
- Microsoft Entra ID (推奨)。 クラスターにサインインするには、Entra ID ID とグループを使用します。 Microsoft Entra 統合は、お客様に代わって統合をプロビジョニングし、ローテーションします。 有効にするには、「 Microsoft Entra 統合を使用する」を参照してください。
- ローカル アカウント。 Entra ID をバイパスする組み込みのクラスター管理者証明書。 運用環境ではローカル アカウントを無効にすることをお勧めします。 「ローカル アカウントの管理」を参照してください。
- 外部 ID プロバイダー。 Microsoft Entra ID 以外の OIDC 準拠 ID プロバイダーを使用します。 外部 ID プロバイダー認証を参照してください。
AKS が Kubernetes API 要求を認証する方法の詳細については、「 クラスター認証の概念」を参照してください。
B. Kubernetes コントロールプレーンの承認
呼び出し元が Kubernetes API に対して認証されると、AKS は 2 つのモデルの 1 つ (または両方) を使用して要求を承認します。
- Kubernetes RBAC。 Kubernetes のネイティブモデルは、API サーバーによって評価されます。 アクセス許可は、Kubernetes オブジェクトとしてクラスターに格納されます。
- Microsoft Entra ID の承認。 AKS 認可 Webhook は、Azure ロールの割り当てを利用して、認可の決定を Microsoft Entra ID に委任します。
dataActionsを使用した Azure RBAC ロールの割り当ては、すべての標準 Kubernetes API リソースでサポートされ、Azure ABAC 条件を使用したロールの割り当てはカスタム リソースでサポートされます。 アクセス許可は Microsoft Entra ID で一元的に管理され、サブスクリプション、管理グループ、またはリソース グループのスコープで 1 つのロールの割り当てから多くのクラスターを管理できます。
各モデルを使用するタイミングに関するサイド バイ サイドの比較とガイダンスについては、「 クラスター承認の概念」を参照してください。
C. AKS リソース承認 (Azure Resource Manager)
Kubernetes API の呼び出しを承認するだけでなく、AKS リソース自体に対する Azure レベルの操作を承認する必要もあります。 最も一般的な例は、クラスターの kubeconfigをプルできるユーザーを制御することです。これは、Azure RBAC を使用してきめ細かく管理できるスタンドアロンの Azure Resource Manager 操作です。 これは、Kubernetes API の承認とは別に、 Microsoft.ContainerService リソース プロバイダーに対する標準的な Azure RBAC です。
「Azure 組み込みロールのクラスター構成ファイルと組み込みロールへのアクセスを制限する」を参照してください。
D: クラスター ID (Azure →クラスター)
AKS クラスターでは、Azure マネージド ID を使用して、ロード バランサーの作成、ディスクのアタッチ、Azure Container Registry からのイメージのプルなど、ユーザーに代わって Azure リソースに対して動作します。 主な ID は次のとおりです。
- コントロール プレーン ID。 クラスターの Azure リソースを管理するためにクラスター コントロール プレーンによって使用されます。
- Kubelet ID。 Azure Container Registry などのサービスに対する認証を行うために、各ノードの kubelet によって使用されます。
- アドオン/拡張機能 ID。 一部の AKS アドオンと拡張機能では、独自のマネージド ID が使用されます。
各 ID の種類と、システム割り当て ID とユーザー割り当て ID の使用方法の詳細については、 AKS のマネージド ID に関するページを参照してください。
E. ワークロード ID (ポッド → Azure)
ワークロード ID を使用すると、AKS クラスターで実行されているポッドは、クラスターにシークレットを格納することなく、Microsoft Entra で保護された Azure サービス (Key Vault、ストレージ、Cosmos DB など) に対して認証を行うことができます。 AKS では 、Microsoft Entra ワークロード ID を使用します。この ID は、Microsoft Entra アプリケーションまたはユーザー割り当てマネージド ID にフェデレーションされた Kubernetes サービス アカウント トークンを投影します。
新しいワークロードには、非推奨の Microsoft Entra ポッドマネージド ID を 使用しないでください。
意思決定ガイド
| ゴール | これらのドキュメントを使用する |
|---|---|
| Microsoft Entra ID を使用してクラスターにユーザーをサインインさせる | Microsoft Entra 統合を有効にする |
| 多くのクラスターにわたって Kubernetes API での権限を管理する | Kubernetes API に Microsoft Entra ID 承認を使用する |
| 特定のカスタム リソースの種類へのアクセスを制限する | Entra ID 認証の ABAC 条件 |
| クラスターごと、名前空間ごとのアクセス許可を Kubernetes オブジェクトとして作成する | Entra 統合で Kubernetes RBAC を使用する |
| クラスターが ACR からプルするか、ディスクを接続できるようにする | AKS のマネージド アイデンティティ |
| ポッドがシークレットなしで Key Vault またはストレージに到達できるようにする | Microsoft Entra Workload IDの概要 |
クラスターをダウンロードできるユーザーを制限する kubeconfig |
クラスター構成ファイルへのアクセスを制限する |
AKS サービスのアクセス許可のリファレンス
AKS によって使用される Azure アクセス許可 (クラスターを作成する ID、実行時のクラスター ID、追加のクラスター ID アクセス許可、および AKS ノード アクセス) については、 AKS サービスのアクセス許可のリファレンスを参照してください。
次のステップ
- クラスター認証の概念
- クラスター承認の概念
- Kubernetes API に Microsoft Entra ID 承認を使用する
- AKS のマネージド アイデンティティ
- Microsoft Entra Workload IDの概要
Kubernetes と AKS の中心概念の詳細については、次の記事を参照してください。