AKS の ID およびアクセス管理に関する考慮事項
この記事では、Azure Kubernetes Service (AKS) を使用するときの ID およびアクセス管理に関する設計上の考慮事項と推奨事項について説明します。 ID とアクセス管理には、クラスター ID、ワークロード ID、オペレーター アクセスなど、複数の側面があります。
設計上の考慮事項
- 使用するクラスター ID (マネージド ID または サービス プリンシパル) を決定します。
- クラスター アクセスの認証方法を決定します。クライアント証明書に基づくか、Microsoft Entra ID を使用します。
- マルチテナント クラスターと、Kubernetes でロールベースのアクセス制御 (RBAC) を設定する方法を決定します。
- 分離メソッドを選択します。 メソッドには、名前空間、ネットワーク ポリシー (Azure CNI でのみ許可)、コンピューティング (ノード プール)、クラスターが含まれます。
- アプリケーション チームごとに、分離するための Kubernetes RBAC ロールとコンピューティング割り当てを決定します。
- アプリケーション チームが自身のクラスターまたはその他のクラスター内の他のワークロードを読み取ることができるかどうかを決定します。
- AKS ランディング ゾーン のカスタム Azure RBAC ロールのアクセス許可を決定します。
- サイト信頼性エンジニアリング (SRE) ロールに必要なアクセス許可を決定し、そのロールがクラスター全体を管理し、トラブルシューティングができるようにします。
- SecOps にどのようなアクセス許可が必要かを決定します。
- ランディング ゾーンの所有者にどのようなアクセス許可が必要かを決定します。
- クラスターにデプロイするために、アプリケーション チームに必要となるアクセス許可を決定します。
- ワークロード ID (Microsoft Entra ワークロード ID) が必要かどうかを決定します。 Azure Key Vault の統合や Azure Cosmos DB などのサービスに必要になる場合があります。
設計の推奨事項
- クラスター ID。
- AKS クラスターに独自のマネージド ID を使用します。
- クラスター マネージド ID に必要なアクセス許可の管理を簡略化するには、AKS ランディング ゾーン用のカスタム Azure RBAC ロールを定義します。
- クラスターへのアクセス。
- Microsoft Entra ID で Kubernetes RBAC を使い、権限を制限し、管理者の特権を最小化します。 これは、構成とシークレット アクセスの保護に役立ちます。
- 認証やオペレーターおよび開発者のアクセスに Microsoft Entra ID を使用できるように、AKS マネージド Microsoft Entra 統合を使用します。
- Kubernetes で、必要な RBAC ロールとロール バインディングを定義します。
- サイト信頼性エンジニアリング (SRE)、SecOps、開発者のアクセスのために、Microsoft Entra グループに対して Kubernetes のロールとロール バインディングを使用します。
- Kubernetes 用の Azure RBAC の使用を検討してください。これにより、Azure リソース、AKS、Kubernetes リソース全体で統合された管理とアクセス制御が可能になります。 Kubernetes 用の Azure RBAC が有効になっている場合、Kubernetes のユーザー ID と資格情報を個別に管理する必要はありません。 Microsoft Entra プリンシパルは Azure RBAC のみで検証されますが、通常の Kubernetes ユーザーとサービス アカウントは Kubernetes RBAC のみで検証されます。
- 必要に応じて、SRE フル アクセスを Just-In-Time に付与します。
- Kubernetes 用の Microsoft Entra ワークロード ID を使用します。このフェデレーションを実装すると、開発者はネイティブの Kubernetes サービス アカウントとフェデレーションを使用して、Azure や Microsoft Graph などの Microsoft Entra ID によって管理されるリソースにアクセスできます。