Azure Kubernetes Service (AKS) の認証と認可のベスト プラクティス

Azure Kubernetes Service (AKS) でクラスターをデプロイし、保守管理するとき、リソースやサービスへのアクセスを管理する方法を実装します。 このような制御がなければ:

• 必要としないリソースやサービスへのアクセス許可がアカウントに付与されることがあります。
• 変更を行う際に使用された資格情報を追跡することは難しい場合があります。

この記事では、AKS クラスターのアクセスと ID を管理するためにクラスター オペレーターが従うことができる推奨されるプラクティスについて説明します。 学習内容は次のとおりです。

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 のユーザーまたはグループにロールをバインドします。 これらの Kubernetes RBAC の詳細については、次のセクションを参照してください。 Microsoft Entra の統合とリソースへのアクセスの制御方法をまとめたのが次の図です。

1. Microsoft Entra ID を使用した開発者認証。
2. Microsoft Entra トークン発行エンドポイントがアクセス トークンを発行します。
3. 開発者は、kubectl create pod などの Microsoft Entra トークンを使用して操作を実行します。
4. Kubernetes では Microsoft Entra ID を利用してトークンの有効性が検証され、開発者のグループ メンバーシップが取得されます。
5. Kubernetes RBAC とクラスター ポリシーが適用されます。
6. 前述の Microsoft Entra グループ メンバーシップの検証、Kubernetes RBAC、ポリシーに基づき、開発者の要求が通過するかが決まります。

Microsoft Entra ID を使用する AKS クラスターを作成するには、「Microsoft Entra ID と AKS を統合する」を参照してください。

Kubernetes のロールベースのアクセス制御 (Kubernetes RBAC) を使用する

ベスト プラクティスのガイダンス

Kubernetes RBAC を使用して、ユーザーまたはグループに付与されるクラスター リソースへのアクセス許可を定義します。 必要最低限のアクセス許可を割り当てるロールとバインディングを作成します。 Microsoft Entra ID と統合して、ユーザーの状態またはグループ メンバーシップの変更を自動的に更新し、クラスター リソースへのアクセス許可を最新の状態に保ちます。

Kubernetes では、クラスター リソースへのアクセスを細かく制御できます。 アクセス許可は、クラスター レベルで、または特定の名前空間に対して定義します。 管理できるリソースと、その際付与するアクセス許可の種類を決定します。 その後、これらのロールをバインディングが与えられているユーザーまたはグループに適用します。 Roles、ClusterRoles、Bindings に関する詳細については、「Azure Kubernetes Service (AKS) でのアクセスと ID オプション」を参照してください。

たとえば、finance-app という名前の名前空間にあるリソースに完全アクセスできるロールを作成します。次のサンプル YAML マニフェストをご覧ください。

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role
  namespace: finance-app
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["*"]

次に、RoleBinding を作成し、Microsoft Entra ユーザー developer1@contoso.com をそれにバインドします。次の YAML マニフェストをご覧ください。

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role-binding
  namespace: finance-app
subjects:
- kind: User
  name: developer1@contoso.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: finance-app-full-access-role
  apiGroup: rbac.authorization.k8s.io

developer1@contoso.com が AKS クラスターに対して認証されると、それらのクラスターには finance-app 名前空間のリソースに対する完全なアクセス権が与えられます。 このように、リソースへのアクセスが論理的に分離されて制御されます。 Microsoft Entra ID 統合で Kubernetes RBAC を使用する

Kubernetes RBAC と Microsoft Entra グループを使用して Kubernetes クラスター リソースへのアクセスを制御するには、AKS でロールベースのアクセス制御と Microsoft Entra の ID を使用してクラスター リソースへのアクセスを制御する方法に関するページを参照してください。

Azure RBAC を使用する

ベスト プラクティスのガイダンス

Azure RBAC を使用して、ユーザーまたはグループが 1 つ以上のサブスクリプションの AKS リソースに対して持つ必要最小限のアクセス許可を定義します。

AKS クラスターを完全に運用するには、次の 2 つのレベルのアクセスが必要です。

• Azure サブスクリプションの AKS リソースへのアクセス。

  このアクセス レベルでは、次のことができます。

  • AKS API を使用してクラスターのスケーリングまたはアップグレードを制御する
  • 設定した kubeconfig をプルする。

  AKS リソースと kubeconfig へのアクセスを制御する方法については、クラスター構成ファイルへのアクセスの制限に関する記事を参照してください。

• Kubernetes API へのアクセス。

  このアクセス レベルは、次のいずれかによって制御されます。

  • Kubernetes RBAC (従来)
  • Kubernetes の認可のための Azure RBAC と AKS の統合

  Azure RBAC を使用して Kubernetes API にアクセス許可を細かく付与する方法については、「Kubernetes 認可に Azure RBAC を使用する」を参照してください。

ポッドマネージド ID を使用する

ポッドやコンテナー イメージ内で固定の資格情報を使用しないでください。開示や悪用の危険にさらされます。 代わりに、ポッド ID を使用し、Microsoft Entra ID によるアクセスを自動要求してください。

Azure Cosmos DB、Key Vault、Blob Storage などの他の Azure リソースへアクセスするには、ポッドに認証資格情報が付与されている必要があります。 認証資格情報は、コンテナー イメージを使用して定義したり、Kubernetes シークレットとして挿入したりできます。 どちらの方法でも、手動で作成して割り当てる必要があります。 通常、資格情報はポッド全体で再利用されます。定期的なローテーションはありません。

Azure リソース用ポッドマネージド ID (プレビュー) を利用すると、Microsoft Entra ID 経由でサービスにアクセスすることを自動要求できます。 ポッドマネージド ID は、AKS では現在プレビュー段階にあります。 使用を開始するには、「Azure Kubernetes Service で Microsoft Entra ポッドマネージド 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 テナントからトークンをフェッチします。

• マネージド モード: このモードにあるのは NMI のみです。 ID は、ユーザーが手動で割り当て、管理する必要があります。 詳細については、マネージド モードのポッド ID に関するページをご覧ください。 このモードでは、az aks pod-identity add コマンドを使用して Azure Kubernetes Service (AKS) クラスターにポッド ID を追加すると、AzureIdentity と AzureIdentityBinding が --namespace パラメーターで指定された名前空間に作成され、AKS リソース プロバイダーは --identity-resource-id パラメーターで指定されたマネージド ID を AKS クラスター内の各ノード プールの仮想マシン スケール セットに割り当てます。

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 サーバーにリダイレクトされます。

1. NMI サーバー:

   • Azure リソースへのアクセスの要求が行われているポッドを、そのリモート アドレスに基づいて識別します。
   • Azure リソース プロバイダーにクエリを実行します。

2. Azure リソース プロバイダーによって、AKS クラスターに Azure ID マッピングが存在するかどうかが確認されます。

3. NMI サーバーから、ポッドの ID マッピングに基づいて Microsoft Entra ID にアクセス トークンが要求されます。

4. Microsoft Entra ID が与える NMI サーバーへのアクセスがポッドに返されます。

   • このアクセス トークンがポッドで使用され、Azure のリソースへのアクセスの要求が行われます。

次の例では、開発者はマネージド ID を利用して Azure SQL Database へのアクセスを要求するポッドを作成しています。

1. クラスター オペレーターによって、ポッドからリソースへのアクセスが要求される際に、ID をマッピングするためのサービス アカウントが作成されます。
2. NMI サーバーは、アクセス トークンのためのポッド要求を、Azure リソース プロバイダーと共に Microsoft Entra ID に中継するためにデプロイされます。
3. 開発者は、NMI サーバー経由でアクセス トークンを要求するポッドをマネージド ID と共にデプロイします。
4. トークンがポッドに返され、Azure SQL Database にアクセスするために使用されます

ポッドマネージド ID を使用するには、「Azure Kubernetes Service で Microsoft Entra ポッドマネージド ID を使用する (プレビュー)」を参照してください。

次のステップ

このベスト プラクティスの記事では、クラスターとリソースの認証と認可について取り上げました。 これらのベスト プラクティスのいくつかを実装する場合は、次の記事を参照してください。

• Microsoft Entra ID を AKS と統合する
• Azure Kubernetes Service で Microsoft Entra ポッドマネージド ID を使用する (プレビュー)

AKS でのクラスター操作の詳細については、次のベスト プラクティスを参照してください。

• マルチ テナントとクラスター分離
• Kubernetes スケジューラの基本的な機能
• Kubernetes スケジューラの高度な機能