Azure Kubernetes Service の認証を構成する
Azure Kubernetes Service (AKS) でクラスターをデプロイし、保守管理するとき、リソースやサービスへのアクセスを管理する方法を実装します。 このような制御がなければ:
- 必要としないリソースやサービスへのアクセス許可がアカウントに付与されることがあります。
- 変更を行う際に使用された資格情報を追跡することは難しい場合があります。
Microsoft Entra ID を使用する
ベスト プラクティスのガイダンス: Microsoft Entra 統合を使用して AKS クラスターをデプロイします。 Microsoft Entra ID を使うと、ID 管理レイヤーが一元化されます。 ユーザー アカウントまたはグループの状態が変わると、AKS クラスターにアクセスしたとき、その変更内容が自動的に更新されます。 Roles、ClusterRoles、Bindings を使用して、ユーザーまたはグループに最低限のアクセス許可を付与します。
お使いの Kubernetes クラスターの開発者とアプリケーション所有者はさまざまなリソースへのアクセスを必要とします。 Kubernetes には、ユーザーがどのリソースを操作できるかを制御するための ID 管理ソリューションがありません。 代わりに、クラスターを、エンタープライズ対応の ID 管理ソリューションである Microsoft Entra ID などの既存の ID ソリューションと統合できます。
Microsoft Entra 統合クラスターを AKS で使用する際は、リソースへのアクセス許可を定義する Roles または ClusterRoles を作成します。 作成後、Microsoft Entra ID のユーザーまたはグループにロールをバインドします。
Microsoft Entra の統合とリソースへのアクセスの制御方法をまとめたのが次の図です。
Microsoft Entra ID を使用した開発者認証。
Microsoft Entra トークン発行エンドポイントがアクセス トークンを発行します。
開発者は、
kubectl create podなどの Microsoft Entra トークンを使用して操作を実行します。Kubernetes では Microsoft Entra ID を利用してトークンの有効性が検証され、開発者のグループ メンバーシップが取得されます。
Kubernetes RBAC とクラスター ポリシーが適用されます。
先ほどの Microsoft Entra グループ メンバーシップの検証と、Kubernetes RBAC およびポリシーに基づいて、開発者の要求が正常に行われます。
Kubernetes のロールベースのアクセス制御 (Kubernetes RBAC) を使用する
ベスト プラクティスのガイダンス: Kubernetes RBAC を使用して、クラスター リソースに対するユーザーまたはグループのアクセス許可を定義します。 必要最低限のアクセス許可を割り当てるロールとバインディングを作成します。 Microsoft Entra ID と統合して、ユーザーの状態またはグループ メンバーシップの変更を自動的に更新し、クラスター リソースへのアクセス許可を最新の状態に保ちます。
Kubernetes では、クラスター リソースへのアクセスを細かく制御できます。 アクセス許可は、クラスター レベルで、または特定の名前空間に対して定義します。 管理できるリソースと、その際付与するアクセス許可の種類を決定します。 その後、これらのロールをバインディングが与えられているユーザーまたはグループに適用します。
developer1@contoso.com が AKS クラスターに対して認証されると、finance-app 名前空間のリソースへの完全アクセス許可が与えられます。 このように、リソースへのアクセスが論理的に分離されて制御されます。 Microsoft Entra ID 統合で Kubernetes RBAC を使用する
Azure RBAC を使用する
ベスト プラクティスのガイダンス: Azure RBAC を使用して、1 つ以上のサブスクリプションの AKS リソースに対して最低限必要なユーザーとグループのアクセス許可を定義します。
AKS クラスターを完全に運用するには、次の 2 つのレベルのアクセスが必要です。
- Azure サブスクリプションの AKS リソースへのアクセス。
- このアクセス レベルを使用すると、次のことができます。
- AKS API を使用してクラスターのスケーリングまたはアップグレードを制御する
- kubeconfig をプルします。
- Kubernetes API へのアクセス。
- このアクセス レベルは、次のいずれかの方法で制御されます。
- Kubernetes RBAC (従来)
- Kubernetes の認可のための Azure RBAC と AKS の統合
ポッドマネージド ID を使用する
ポッドやコンテナー イメージ内で固定の資格情報を使用しないでください。開示や悪用の危険にさらされます。 代わりに、ポッド ID を使用し、Microsoft Entra ID によるアクセスを自動要求してください。
Azure Cosmos DB、Key Vault、Blob Storage などの他の Azure リソースへアクセスするには、ポッドに認証資格情報が付与されている必要があります。 認証資格情報は、コンテナー イメージを使用して定義したり、Kubernetes シークレットとして挿入したりできます。 どちらの方法でも、手動で作成して割り当てる必要があります。 通常、資格情報はポッド全体で再利用されます。定期的なローテーションはありません。
Azure リソース用ポッドマネージド ID (プレビュー) を利用すると、Microsoft Entra ID 経由でサービスにアクセスすることを自動要求できます。 現在、AKS では、ポッドマネージド ID はプレビュー段階です。
Microsoft Entra ポッドマネージド ID (プレビュー) は、次の 2 つの操作モードに対応しています。
- 標準モード:このモードでは、次の 2 つのコンポーネントが AKS クラスターにデプロイされます。
- Managed Identity Controller (MIC): Kubernetes API サーバーを介してポッド、AzureIdentity、および AzureIdentityBinding の変更を監視する Kubernetes コントローラー。 MIC は関連する変更を検出すると、必要に応じて AzureAssignedIdentity を追加または削除します。 具体的には、ポッドがスケジュールされている場合、MIC は、作成フェーズ中にノード プールによって使用される基になる仮想マシン スケール セットに Azure 上のマネージド ID を割り当てます。 ID を使用しているすべてのポッドが削除された場合、同じマネージド ID が他のポッドによって使用されていない限り、ノード プールの仮想マシン スケール セットから ID が削除されます。 MIC は、AzureIdentity または AzureIdentityBinding が作成または削除された場合にも同様のアクションを実行します。
- Node Management Identity (NMI) は、AKS クラスターの各ノードで DaemonSet として実行されるポッドです。 NMI によって、各ノードの Azure Instance Metadata Service に対するセキュリティ トークン要求がインターセプトされます。 要求をそれ自体にリダイレクトし、トークンを要求している ID にポッドからアクセス可能であるかを検証し、アプリケーションに代わって Microsoft Entra テナントからトークンをフェッチします。
- Managed Identity Controller (MIC): Kubernetes API サーバーを介してポッド、AzureIdentity、および AzureIdentityBinding の変更を監視する Kubernetes コントローラー。 MIC は関連する変更を検出すると、必要に応じて AzureAssignedIdentity を追加または削除します。 具体的には、ポッドがスケジュールされている場合、MIC は、作成フェーズ中にノード プールによって使用される基になる仮想マシン スケール セットに Azure 上のマネージド ID を割り当てます。 ID を使用しているすべてのポッドが削除された場合、同じマネージド ID が他のポッドによって使用されていない限り、ノード プールの仮想マシン スケール セットから ID が削除されます。 MIC は、AzureIdentity または AzureIdentityBinding が作成または削除された場合にも同様のアクションを実行します。
- マネージド モード: このモードにあるのは NMI のみです。 ID は、ユーザーが手動で割り当て、管理する必要があります。 このモードでは、az aks pod-identity add コマンドを使ってポッド ID を Azure Kubernetes Service (AKS) クラスターに追加すると、
--namespaceパラメーターで指定した名前空間に AzureIdentity と AzureIdentityBinding が作成されます。一方、リソース プロバイダーにより、--identity-resource-idパラメーターで指定したマネージド ID が AKS クラスター内の各ノード プールの仮想マシン スケール セットに割り当てられます。
Note
そうではなく AKS クラスター アドオンを使って Microsoft Entra ポッドマネージド ID をインストールした場合は、セットアップにマネージド モードが使われます。
managed モードには、standard に比べて次の利点があります。
- ノード プールの仮想マシン スケール セットに対する ID の割り当てには 40 秒から 60 秒かかる場合があります。 ID へのアクセスが必要で、割り当ての遅延を許容できない cronjobs またはアプリケーションの場合は、ノード プールの仮想マシン スケール セットに ID が事前に割り当てられる
managedモードを使用するのが最善です。 手動、または az aks pod-identity add コマンドを使用します。 standardモードでは、MIC には、AKS クラスターによって使用される仮想マシン スケール セットに対する書き込みアクセス許可と、ユーザー割り当てマネージド ID に対するManaged Identity Operatorアクセス許可が必要です。managed modeで実行している間、MIC は使用されないので、ロールの割り当ては必要ありません。
ポッドの資格情報を手動で定義する代わりに、ポッドマネージド ID によってアクセス トークンがリアルタイムで要求され、それが割り当てられているリソースにのみアクセスするために使用されます。 AKS には、ポッドでマネージド ID を使用できるようにする操作を処理するコンポーネントが 2 つあります。
- Node Management Identity (NMI) サーバーは、AKS クラスターの各ノードで DaemonSet として実行されるポッドです。 NMI サーバーは、Azure サービスへのポッド要求を待ち受けます。
- Azure リソース プロバイダーは、Kubernetes API サーバーに対してクエリを実行し、ポッドに対応する Azure ID マッピングを確認します。
ポッドで Azure サービスにアクセスするために Microsoft Entra ID からセキュリティ トークンが要求されると、ネットワーク ルールによってトラフィックが NMI サーバーにリダイレクトされます。
NMI サーバー:
- Azure リソースへのアクセスの要求が行われているポッドを、そのリモート アドレスに基づいて識別します。
- Azure リソース プロバイダーにクエリを実行します。
Azure リソース プロバイダーによって、AKS クラスターに Azure ID マッピングが存在するかどうかが確認されます。
NMI サーバーから、ポッドの ID マッピングに基づいて Microsoft Entra ID にアクセス トークンが要求されます。
Microsoft Entra ID が与える NMI サーバーへのアクセスがポッドに返されます。
- このアクセス トークンがポッドで使用され、Azure のリソースへのアクセスの要求が行われます。
次の例では、開発者はマネージド ID を利用して Azure SQL Database へのアクセスを要求するポッドを作成しています。
- クラスター オペレーターによって、ポッドからリソースへのアクセスが要求される際に、ID をマッピングするためのサービス アカウントが作成されます。
- NMI サーバーは、アクセス トークンのためのポッド要求を、Azure リソース プロバイダーと共に Microsoft Entra ID に中継するためにデプロイされます。
- 開発者は、NMI サーバー経由でアクセス トークンを要求するポッドをマネージド ID と共にデプロイします。
- トークンがポッドに返され、Azure SQL Database にアクセスするために使用されます