適用対象: ✔️ AKS 自動 ✔️ AKS Standard
AKS では、5 つの異なるシナリオで ID が使用されます。 各シナリオは異なる質問に回答し、独自の構成モデルを持っています。
ほとんどの実稼働 AKS ワークロードでは、AKS Automatic は、この記事で説明する同じ AKS ID モデルを保持しながら、ID 関連の既定値を含む運用対応のプラットフォーム ベースラインから始まるため、推奨される既定値です。
この記事では、各シナリオの簡単な概要について説明し、ガイダンスが AKS Automatic と AKS Standard にどのようにマップされるかについて説明し、詳細なドキュメントを示します。
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 ワークロード ID の概要 |
AKS Automatic と AKS Standard における ID セキュリティ体制
この記事の 5 つの ID シナリオは、AKS Automatic と AKS Standard の両方に適用されます。 主な違いは、運用体制です。
- AKS Automatic では、事前構成済みの ID とセキュリティの既定値が提供されます。
- AKS Standard は、より多くの手動制御を提供し、より多くのセットアップの選択肢を必要とします。
ほとんどの運用ワークロードの既定の開始点として AKS Automatic を使用し、より深いカスタム プラットフォーム構成が必要な場合は AKS Standard を使用します。
AKS Automatic の概要については、「Azure Kubernetes Service (AKS) Automatic の概要」を参照してください。
AKS Automatic および AKS Standard の ID セキュリティ体制の比較
| 識別領域 | AKS 自動姿勢 | AKS の標準態勢 | 詳細情報 |
|---|---|---|---|
| Kubernetes API 認証 | Microsoft Entra との統合を推奨モデルとする本番運用向けの既定設定 | ローカル アカウントや Entra 統合の選択肢など、構成可能 | クラスター認証の概念 |
| Kubernetes API の承認 | Kubernetes 承認のAZURE RBAC が事前に構成されている | クラスター構成によって選択されたローカル アカウント優先および承認モデル | クラスター承認の概念 |
| AKS リソースの承認 | AKS リソース操作で標準Azure RBAC モデルを使用する | AKS リソース操作で標準Azure RBAC モデルを使用する | kubeconfig アクセスの制御 |
| クラスター ID | 運用ベースラインの既定値でマネージド ID モデルを使用する | オペレーターが選択したセットアップでマネージド ID モデルを使用する | AKS のマネージド アイデンティティ |
| ワークロード識別子 | ワークロード ID と OIDC 発行者が事前に構成されている | 省略可能で、オペレーターによって構成されている | ワークロード 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 の自動統合とMicrosoft Entra統合から始めます。
AKS が Kubernetes API 要求を認証する方法の詳細については、「 クラスター認証の概念」を参照してください。
B. Kubernetes コントロール プレーンの承認
呼び出し元が Kubernetes API に対して認証されると、AKS は 2 つのモデルの 1 つ (または両方) を使用して要求を承認します。
-
Kubernetes RBAC: API サーバーによって評価されるネイティブ Kubernetes
Role、ClusterRole、RoleBindingモデル。 アクセス許可は、Kubernetes オブジェクトとしてクラスターに格納されます。 -
Microsoft Entra ID 認可: AKS 認証 Webhook は、Azure のロール割り当てを使用して、認証の決定を Microsoft Entra ID に委任します。
dataActionsを使用した Azure RBAC ロールの割り当ては、すべての標準 Kubernetes API リソースでサポートされ、Azure ABAC 条件を使用したロールの割り当てはカスタム リソースでサポートされます。 サブスクリプション、管理グループ、またはリソース グループ スコープで 1 つのロールの割り当てから多数のクラスターを管理するために、Microsoft Entra IDでアクセス許可を一元的に管理します。
AKS 自動では、Kubernetes 承認のAzure RBAC は、運用準備完了の既定の体制の一部として事前構成されています。
各モデルを使用するタイミングの比較とガイダンスについては、「 クラスター承認の概念」を参照してください。
C. AKS リソース承認 (Azure Resource Manager)
Kubernetes API の呼び出しを承認するだけでなく、AKS リソース自体に対する Azure レベルの操作を承認する必要もあります。 最も一般的な例は、クラスターの kubeconfigをプルできるユーザーを制御することです。これは、Azure RBAC を使用してきめ細かく管理できるスタンドアロンの Azure Resource Manager 操作です。 この操作では、Microsoft.ContainerService リソース プロバイダーに対して標準のAzure RBAC が使用され、Kubernetes API の承認とは別であり、AKS Automatic と AKS Standard にも同じ方法が適用されます。 詳細については、クラスター構成ファイルへのアクセスを制限するおよびAzure の組み込みロール内の組み込みロールを参照してください。
D: クラスター ID (Azure →クラスター)
AKS クラスターでは、Azure マネージド ID を使用して、ロード バランサーの作成、ディスクのアタッチ、Azure Container Registry からのイメージのプルなど、ユーザーに代わって Azure リソースに対して動作します。 主な ID は次のとおりです。
- コントロール プレーン ID: クラスターのリソースAzure管理するためにクラスター コントロール プレーンによって使用されます。
- Kubelet ID: Azure Container Registryなどのサービスに対する認証を行うために、各ノードの kubelet によって使用されます。
- アドオン/拡張機能 ID: 一部の AKS アドオンと拡張機能では、独自のマネージド ID が使用されます。
AKS Automatic はこの同じ 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 サービス アカウント トークンを投影します。
AKS Automatic には、事前構成済みの既定値としてワークロード ID と OIDC 発行者が含まれます。 AKS Standard では、これらの機能は省略可能であり、オペレーターによって構成されます。
新しいワークロードには、非推奨の Microsoft Entra ポッドマネージド ID を 使用しないでください。
意思決定ガイド
| ゴール | これらのドキュメントを使用する |
|---|---|
| ほとんどのワークロードで運用準備完了の ID ベースラインから開始する | AKS Automatic の概要 |
| 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 ワークロード ID の概要 |
クラスターをダウンロードできるユーザーを制限する kubeconfig |
クラスター構成ファイルへのアクセスを制限する |
| 既定の ID ポスチャを使用して運用対応クラスターを作成する | AKS 自動クラスターを作成する |
AKS サービスのアクセス許可のリファレンス
AKS が使用するAzureアクセス許可 (クラスターを作成する ID、実行時のクラスター ID、追加のクラスター ID アクセス許可、および AKS ノード アクセス) については、AKS サービスのアクセス許可のリファレンスを参照してください。
関連するコンテンツ
- Azure Kubernetes Service (AKS) Automatic の概要
- Azure Kubernetes Service (AKS) 自動クラスターを作成します
- クラスター認証の概念
- クラスター承認の概念
- Kubernetes API に Microsoft Entra ID 承認を使用する
- AKS のマネージド アイデンティティ
- Microsoft Entra ワークロード ID の概要
Kubernetes と AKS の中心概念の詳細については、次の記事を参照してください。