この記事では、Azure Kubernetes Service (AKS) が、認証された呼び出し元が Kubernetes API に対して実行できる操作を決定する方法について説明します。 AKS がサポートする 2 つの承認モデルと、Azure ABAC 条件を使用したきめ細かなカスタム リソース制御について説明します。
最初に AKS が呼び出し元を 認証する 方法については、 クラスター認証の概念に関するページを参照してください。
4 つの AKS ID シナリオすべてに対する方向については、 AKS のアクセスと ID のオプションに関するページを参照してください。
Kubernetes API を承認する
呼び出し元が認証されると、AKS は、要求されたアクションの実行が呼び出し元に許可されているかどうかを評価します。 AKS では、Kubernetes API に対して次の 2 つの承認モデルがサポートされています。
- Kubernetes ロールベースのアクセス制御 (RBAC)。 ネイティブ Kubernetes 承認モデル。 権限は
RoleオブジェクトおよびClusterRoleオブジェクトとして定義され、各クラスターに格納されているRoleBindingオブジェクトとClusterRoleBindingオブジェクトを通じてサブジェクトに付与されます。 - Microsoft Entra ID の承認。 承認の決定を Microsoft Entra ID に委任する AKS 承認 Webhook。 アクセス許可は、Entra ID ID への Azure ロールの割り当てとして付与され、必要に応じて Azure ABAC 条件で調整できます。
同じクラスターで両方のモデルを使用できます。 既定として Microsoft Entra ID 承認を使用し、クラスター内のきめ細かいアクセス許可のために Kubernetes RBAC を予約することをお勧めします。 このセクションの残りの部分では、それぞれを使用する理由とタイミングについて説明します。
Kubernetes RBAC
Kubernetes RBAC は、アップストリームの Kubernetes 承認モデルです。 リソース (Role、ClusterRole など) に動詞 (get、list、createなど) を付与し、podsまたはdeployments オブジェクトを使用してサブジェクト (ユーザー、グループ、サービス アカウント) にバインドするRoleBindingまたはClusterRoleBindingオブジェクトを作成します。 Kubernetes API サーバーの組み込みの RBAC 承認者は、すべての要求でこれらのバインドを評価します。
必要な場合は、Kubernetes RBAC を使用します。
- 保護するワークロードと共に Kubernetes マニフェストとして作成された、きめ細かい、クラスター内の名前空間ごとのアクセス制御。
- GitOpsで管理される認証は、アプリケーション設定と同じ信頼できる情報源に存在しています。
- ワークロードが Kubernetes API の呼び出しに使用するクラスター内サービス アカウントのアクセス許可。
Kubernetes RBAC のアクセス許可のスコープは、1 つのクラスターです。 同じポリシーを多くのクラスターに適用するには、マニフェストを各クラスター (通常は GitOps を使用) に適用する必要があります。 Kubernetes の RoleBinding と ClusterRoleBinding の各オブジェクト内で Microsoft Entraのユーザーとグループを対象として使用し、お客様の中央ディレクトリから人間の ID を引き続き取得できるようにします。
Kubernetes RBAC モデルの背景については、 アップストリームの Kubernetes RBAC ドキュメントを参照してください。 AKS でのセットアップについては、 Microsoft Entra 統合での Kubernetes RBAC の使用に関するページを参照してください。
Kubernetes API の Microsoft Entra ID 承認
Entra ID 承認を使用すると、AKS は Kubernetes API の承認決定を Microsoft Entra ID に委任する承認 Webhook をデプロイします。 要求が API サーバーに到達すると、Webhook は Entra ID checkaccess API を呼び出して呼び出し元の Azure ロールの割り当て (およびアタッチされた ABAC 条件) を評価し、許可または拒否の決定を返します。
Entra ID 承認では、すべてのクラスターで Kubernetes RBAC マニフェストを管理するよりも、次のような利点があります。
- 単一識別平面。 Azure リソースへのアクセスを管理するのと同じ Microsoft Entra ユーザー、グループ、サービス プリンシパルも、Kubernetes API へのアクセスを管理します。 プロビジョニングまたはローテーションする別のユーザー ディレクトリはありません。
- 1 回割り当て、多数のクラスターを管理します。 Azure ロールの割り当ては 、サブスクリプション、管理グループ、またはリソース グループのスコープで行うことができます。 リソース グループ スコープでの 1 つのロールの割り当てにより、そのリソース グループ内のすべての現在および将来の AKS クラスターへのアクセスが許可されます。 Kubernetes RBAC では、マニフェストをすべてのクラスターに個別に適用する必要があります。
- 条件付きアクセスと特権 ID 管理 (PIM)。 クラスター アクセスは、組織の既存の Entra ID 条件付きアクセス ポリシー (多要素認証や場所ベースの制限など) を自動的に継承し、PIM を通じて Just-In-Time で昇格できます。
- 一元化された監査。 すべてのロールの割り当ての変更は、他の Azure リソースの変更と共に Azure アクティビティ ログに記録されるため、クラスター アクセス ガバナンスの監査証跡が 1 つ用意されています。
- きめ細かいカスタム リソース制約。 ABAC 条件を使用すると、クラスターごとの Kubernetes RBAC マニフェストを記述することなく、特定のカスタム リソース (CRD) グループと種類へのアクセスを制限できます。
AKS には、Entra ID 承認用に次の組み込みロールが用意されています。
| 役割 | 説明 |
|---|---|
| Azure Kubernetes Service RBAC 閲覧者 | 名前空間内のほとんどのオブジェクトへの読み取り専用アクセス。 ロール、ロール バインド、または Secretsの表示は許可されません。 |
| Azure Kubernetes Service RBAC ライター | 名前空間内のほとんどのオブジェクトに対する読み取り/書き込みアクセス。 ロールまたはロールバインドの表示または変更を許可しません。 |
| Azure Kubernetes Service RBAC 管理者 | 名前空間内のほとんどのリソースへの読み取り/書き込みアクセスと、名前空間内にロールとロール バインドを作成する機能。 |
| Azure Kubernetes Service RBAC クラスター管理者 | すべての名前空間にわたって、クラスター内のすべてのリソースを完全に制御します。 |
カスタム アクセス許可パターンの場合は、 Microsoft.ContainerService リソース プロバイダーのデータ アクションを使用して、特定の Kubernetes API グループを対象とするカスタム ロール定義を作成できます。 詳細なセットアップとカスタム ロールの例については、「 Kubernetes API に対する Microsoft Entra ID 承認の使用」を参照してください。
Comparison
| 能力 | Kubernetes RBAC | Entra ID の承認 |
|---|---|---|
| アイデンティティソース | Kubernetes ユーザー、グループ、サービス アカウント | Microsoft Entra ID アイデンティティー |
| 1 つの助成金の範囲 | 1 つのクラスター | リソース、リソース グループ、サブスクリプション、または管理グループ |
| マルチクラスター ガバナンス | 各クラスターにマニフェストを適用する (通常は GitOps) | より高いスコープで 1 つのロールの割り当てが多くのクラスターを管理する |
| 条件付きアクセス/PIM | サポートしていません | Entra ID から継承 |
| 監査証跡 | クラスター監査ログ | [Azure Activity Log (Azure アクティビティ ログ)] |
| CRD グループまたは種類でアクセスをフィルター処理する | CRD ごとの Role オブジェクトの作成 |
ロールの割り当てで ABAC 条件属性を使用する |
ABAC 条件を使用してカスタム リソース アクセスを制限する
Microsoft Entra ID 承認を通じて広範な読み取りアクセス権を付与するが、担当者が読み取ることができるカスタム リソース (CRD) を制限する場合は、ロールの割り当てに Azure ABAC 条件をアタッチします。
ABAC 条件がない場合、カスタム リソースの読み取りを許可するには、スコープ内のすべてのクラスター上のすべての CRD をカバーする、 Microsoft.ContainerService/managedClusters/*/readなどのワイルドカードが必要です。 ABAC を使用すると、クラスターごとの Kubernetes RBAC マニフェストを記述することなく、特定の CRD グループや種類へのアクセスを制限する条件 (たとえば、templates.gatekeeper.shをブロックしながらkyverno.ioを許可する) をアタッチできます。
Kubernetes API 承認の場合は、次の属性を使用して、API グループと種類によってカスタム リソースへのアクセスをフィルター処理できます。
Microsoft.ContainerService/managedClusters/customResources:groupMicrosoft.ContainerService/managedClusters/customResources:kind
Azure ABAC の背景については、「 Azure ロールの割り当て条件とは」を参照してください。 詳細な設定については、「 ABAC 条件を使用してカスタム リソース アクセスを制限する」を参照してください。