Azure Arc で有効になっている AKS のアクセスと ID のオプション
適用対象: AKS on Azure Stack HCI 23H2
Kubernetes クラスターへのアクセスは、さまざまな方法で認証、承認、セキュリティ保護、および制御できます。
- Kbernetes ロールベースのアクセス制御 (Kubernetes RBAC)を使用すると、ユーザー、グループ、およびサービス アカウントに、必要な Kubernetes リソースにのみアクセス権を付与できます。
- AKS クラスターが Azure RBAC で有効になっている場合、Microsoft Entra ID と Azure RBAC を使用してセキュリティとアクセス許可の構造をさらに強化できます。
Kubernetes RBAC と Azure RBAC は、クラスター アクセスをセキュリティで保護し、開発者とオペレーターに最低限必要なアクセス許可のみを提供するのに役立ちます。
この記事では、AKS で認証とアクセス許可の割り当てを行うために役立つ中心概念を紹介します。
Kubernetes RBAC
Kubernetes RBAC は、ユーザー操作の詳細なフィルター処理を提供します。 この制御メカニズムより、以下を行います。
- ユーザーまたはユーザー グループに対して、リソースの作成および変更、実行中のアプリケーション ワークロードのログの表示などの操作を行う権限を割り当てます。
- 権限のスコープを、単一の名前空間または AKS クラスター全体に設定できます。
- 権限を定義する "ロール" を作成し、それらのロールを "ロールのバインド" を使用してユーザーに割り当てます。
詳細については、Kubernetes RBAC 認可の使用に関するページをご覧ください。
ロールと ClusterRole
ロール
Kubernetes RBAC を使用してユーザーにアクセス許可を割り当てる前に、ユーザーのアクセス許可を role として定義します。 ロールを使用して Kubernetes 名前空間内のアクセス許可を付与します。
Kubernetes ロールは権限を "付与" します。権限は "拒否" されません。 クラスター全体または特定の名前空間の外部にあるクラスター リソースにアクセス許可を付与するには、 ClusterRolesを使用できます。
ClusterRole
ClusterRole は、特定の名前空間ではなく、クラスター全体のリソースへの権限を付与して適用します。
RoleBinding と ClusterRoleBinding
リソースにアクセス許可を付与するロールを定義したら、 RoleBinding を使用してそれらの Kubernetes RBAC アクセス許可を割り当てます。 AKS クラスターが Microsoft Entra ID と統合されている場合、RoleBinding により、クラスター内でアクションを実行するためのアクセス許可が Microsoft Entra ユーザーに付与されます。 Microsoft Entra ID と Kubernetes RBAC を使用したアクセスの制御に関するページを参照してください
RoleBindings
RoleBindings を使用して、指定した名前空間のユーザーにロールを割り当てます。 RoleBindings を使用すると、1 つの AKS クラスターを論理的に分離でき、ユーザーは各自に割り当てられた名前空間内のアプリケーション リソースにのみアクセスが可能になります。
クラスター全体または特定の名前空間の外部にあるクラスター リソースにロールをバインドするには、 ClusterRoleBindingsを使用します。
ClusterRoleBinding
ClusterRoleBinding では、ロールをユーザーにバインドし、特定の名前空間ではなく、クラスター全体のリソースに適用します。 このアプローチでは、管理者またはサポートエンジニアに対して、AKS クラスター内のすべてのリソースへのアクセス許可を付与できます。
Kubernetes サービス アカウント
"サービス アカウント" は、Kubernetes のプライマリ ユーザー タイプの 1 つです。 Kubernetes API により、サービス アカウントが保持および管理されます。 サービス アカウントの資格情報は Kubernetes シークレットとして格納され、承認されたポッドが API サーバーと通信するために使用できます。 ほとんどの API 要求では、サービス アカウントまたは通常のユーザー アカウント用の認証トークンが提供されします。
通常のユーザー アカウントでは、人間の管理者または開発者は、サービスとプロセスだけではなく、従来のアクセスも許可されます。 Kubernetes は、通常のユーザー アカウントとパスワードを格納するための ID 管理ソリューションを提供していませんが、外部の ID ソリューションを Kubernetes に統合することができます。 AKS クラスターの場合、この統合される ID ソリューションは Microsoft Entra ID です。
Kubernetes の ID オプションの詳細については、「 Kbernetes 認証」を参照してください。
Azure ロールベースのアクセス制御
Azure ロールベースのアクセス制御 (RBAC) は、 Azure Resource Manager 上に構築された承認システムであり、Azure リソースのきめ細かいアクセス管理を提供します。
| RBAC システム | 説明 |
|---|---|
| Kubernetes RBAC | AKS クラスター内の Kubernetes リソースに対して機能するように設計されています。 |
| Azure RBAC | Azure サブスクリプション内のリソースに対して機能するように設計されています。 |
Azure の RBAC では、適用されるアクセス許可の概要を説明するロール定義を作成します。 次に、特定の "スコープ" の "ロールの割り当て" を使用して、ユーザーまたはグループにこのロール定義を割り当てます。 スコープは、個々のリソース、リソース グループ、またはサブスクリプション全体にすることができます。
詳細については、「Azure ロールベースのアクセス制御 (Azure RBAC) とは」
AKS Arc クラスターを完全に動作させるために必要なアクセス レベルは 2 つあります。
- Azure サブスクリプションの AKS リソースへのアクセス。
- Azure Arc API で有効になっている AKS を使用して、クラスターのスケーリングまたはアップグレードを制御します。
- admin の証明書ベースの kubeconfig をプルします。
- Entra ID が有効な kubeconfig をプルします。
- Kubernetes API へのアクセス。 このアクセスは、次のいずれかによって制御されます。
- Kubernetes RBAC、または
- Kubernetes の認可のための Azure RBAC と AKS の統合。
AKS リソースへのアクセスを認可するための Azure RBAC
Azure RBAC を使用すると、ユーザー (または ID) に、1 つ以上のサブスクリプションの AKS リソースに対するきめ細かいアクセスを提供できます。 このコントロール プレーン アクションには、 Azure Kubernetes Service Arc クラスター管理者ロール、 Azure Kubernetes Service Arc クラスター ユーザー ロール、 Azure Kubernetes Service Arc 共同作成者ロールの 3 つのロールがあります。 コンテナーのAzure 組み込みロール 説明されているように、各ロールには異なるアクセス許可スコープ。 たとえば、 Azure Kubernetes Service Arc Contributor ロールを使用して、クラスターを作成、スケーリング、アップグレードできます。 一方、 Azure Kubernetes Service Arc Cluster Admin ロールを持つ別のユーザーには、 admin kubeconfig をプルするアクセス許可しかありません。
Kubernetes 認可用 Azure RBAC
Azure RBAC 統合では、AKS は Kubernetes 承認 Webhook サーバーを使用するため、Azure ロールの定義とロールの割り当てを使用して、Microsoft Entra 統合 Kubernetes クラスターリソースのアクセス許可と割り当てを管理できます。
この図に示すように、Azure RBAC 統合を使用する場合、Kubernetes API に対するすべての要求は、 Microsoft Entra 統合で説明されているのと同じ認証フローに従います。
要求を行う ID が Microsoft Entra ID に存在する場合、Azure は Kubernetes RBAC を使用して要求を承認します。 Id が Microsoft Entra ID (Kubernetes サービス アカウントなど) の外部に存在する場合、承認は通常の Kubernetes RBAC に延期されます。
このシナリオでは、Kubernetes ロールの場合と同じように、Azure RBAC のメカニズムと API を使用してユーザーに組み込みロールを割り当てるか、カスタム ロールを作成します。
この機能を使用すると、サブスクリプション間で AKS リソースへの権限をユーザーに付与するだけでなく、Kubernetes API アクセスを制御する各クラスター内でもロールと権限が構成されます。 このデータ プレーン アクションには、それぞれ独自のアクセス許可スコープを持つ 4 つの組み込みロールがあります 組み込みロール セクションで説明します。
重要
ロールの割り当てを行う前に、Kubernetes 承認に対して Azure RBAC を有効にする必要があります。 詳細と詳細な手順については、「 Azure RBAC for Kubernetes 承認の使用を参照してください。
組み込みのロール
Arc で有効になっている AKS には、次の 5 つの組み込みロールが用意されています。 これらは Kubernetes 組み込みロールに似ていますが CRD のサポートなど、いくつかの違いがあります。 各 Azure 組み込みロールで許可されるアクションの完全な一覧をご覧ください。
| Role | 説明 |
|---|---|
| Azure Arc 対応 Kubernetes クラスター ユーザー | クラスター接続ベースの kubeconfig ファイルを取得して、どこからでもクラスターを管理できます。 |
| Azure Arc Kubernetes ビューアー | 名前空間内のほとんどのオブジェクトを表示するための読み取り専用アクセスが許可されます。 シークレットに対する read アクセス許可により、名前空間内の ServiceAccount 資格情報にアクセスできるため、シークレットの表示は許可されません。 これらの資格情報により、その ServiceAccount 値 (特権エスカレーションの形式) を介した API アクセスが許可されます。 |
| Azure Arc Kubernetes ライター | 名前空間内のほとんどのオブジェクトに対する読み取りと書き込みのアクセスが許可されます。 ロールまたはロールバインドの表示または変更を許可しません。 ただし、このロールを使用すると、名前空間内の任意の ServiceAccount 値としてシークレットにアクセスし、ポッドを実行できるため、名前空間内の ServiceAccount 値の API アクセス レベルを取得するために使用できます。 |
| Azure Arc Kubernetes 管理者 | 管理者アクセスを許可します。 これは、 RoleBinding を介して名前空間内で付与されることを目的としています。 RoleBinding で使用すると、名前空間内でロールとロール バインドを作成する機能など、名前空間内のほとんどのリソースへの読み取り/書き込みアクセスが許可されます。 このロールでは、リソース クォータまたは名前空間自体への書き込みアクセスは許可されません。 |
| Azure Arc Kubernetes クラスター管理者 | 任意のリソースに対して任意のアクションを実行する "スーパーユーザー" アクセスを許可します。 ClusterRoleBinding で使用すると、クラスター内のすべてのリソースとすべての名前空間を完全に制御できます。 RoleBinding で使用すると、名前空間自体を含め、ロール バインド名前空間内のすべてのリソースを完全に制御できます。 |
Microsoft Entra の統合
Microsoft Entra 統合を使って AKS クラスターのセキュリティを強化します。 エンタープライズ ID 管理エクスペリエンスに基づいて構築された Microsoft Entra ID は、コア ディレクトリ サービス、アプリケーション アクセス管理、ID 保護を組み合わせたマルチテナントのクラウドベースのディレクトリおよび ID 管理サービスです。 Microsoft Entra ID を使ってオンプレミスの ID を AKS クラスターに統合することで、アカウント管理とセキュリティのための単一のソースを提供できます。
Microsoft Entra 統合 AKS クラスターを使用すると、名前空間内またはクラスター全体の Kubernetes リソースへのアクセス権をユーザーまたはグループに付与できます。
- kubectl構成コンテキストを取得するには、az aksarc get-credentials コマンドを実行します。
- ユーザーが kubectl を使用して AKS クラスターと対話すると、Microsoft Entra 資格情報を使用してサインインするように求められます。
このアプローチでは、ユーザー アカウントの管理とパスワードの資格情報のために 1 つのソースが提供されます。 ユーザーは、Kubernetes クラスター管理者によって定義されているリソースにのみアクセスできます。
Microsoft Entra 認証は、 OpenID Connect を使用して AKS クラスターに提供されます。 OpenID Connect は、OAuth 2.0 プロトコル上に構築された ID レイヤーです。 OpenID Connect の詳細については、 OpenID Connect のドキュメントを参照してください。 Kubernetes クラスター内から、 Webhook トークン認証 を使用して認証トークンを検証します。 webhook トークン認証は、AKS クラスターの一部として構成および管理されます。
まとめ
次の表に、Microsoft Entra 統合が有効な場合にユーザーが Kubernetes に対して認証する方法の概要を示します。 いずれの場合も、コマンドのシーケンスは次のとおりです。
az loginを実行して Azure に対して認証を行います。az aksarc get-credentialsを実行して、Kubernetes クラスターの資格情報を.kube/configにダウンロードします。kubectlコマンドを実行します。- 最初のコマンドは、次の表に示すように、ブラウザーベースの認証をトリガーして Kubernetes クラスターに対して認証できます。
| 説明 | ロール付与が必要 | クラスター管理者 Microsoft Entra グループ | いつ使用するか |
|---|---|---|---|
| クライアント証明書を使用した管理者ログイン | Azure Kubernetes Service Arc クラスター管理者ロール。 このロールを使用すると、 az aksarc get-credentials を --admin フラグと共に使用できます。これにより、Microsoft Entra 以外のクラスター管理者証明書がユーザーの .kube/config にダウンロードされます。これは、Azure Kubernetes 管理者ロールの唯一の目的です。 |
該当なし | お使いのクラスターへのアクセス権を持つ有効な Microsoft Entra グループへのアクセス権がないため、永続的にブロックされている場合。 |
| 手動 (クラスター) RoleBindings を使用した Microsoft Entra ID | Azure Kubernetes Service Arc クラスターのユーザー ロール。 User ロールを使用すると、--admin フラグなしでaz aksarc get-credentialsを使用できます。 これは、 Azure Kubernetes Service クラスター ユーザー ロールの唯一の目的です。 その結果、Microsoft Entra ID 対応クラスターでは、 .kube/config に空のエントリがダウンロードされ、 kubectl で初めて使用されたときにブラウザー ベースの認証がトリガーされます。 |
ユーザーはどのクラスター管理者グループにも含まれていないため、ユーザーの権限は、クラスター管理者によって設定された RoleBindings または ClusterRoleBindings によって完全に制御されます。 (クラスター) RoleBindings サブジェクトとして、Microsoft Entra ユーザーまたは Microsoft Entra グループ を示します。 このようなバインドが設定されていない場合、ユーザーは kubectl コマンドを実行できません。 | きめ細かなアクセス制御が必要で、Kubernetes 認可に Azure RBAC を使用しない場合。 バインディングを設定するユーザーは、この表に示されている他の方法のいずれかを使用してサインインする必要があることに注意してください。 |
クラスター管理者 Microsoft Entra グループのメンバー別の Microsoft Entra ID (Azure CLI で --aad-admin-group-object-ids フラグを使用して設定) |
前と同じ。 | ユーザーは、こちらに一覧表示されているいずれかのグループのメンバーです。 一覧表示されているすべてのグループを cluster-admin Kubernetes ロールにバインドする ClusterRoleBinding が自動的に生成されます。 そのため、これらのグループのユーザーは、すべての kubectl コマンドを cluster-adminとして実行できます。 |
ユーザーに完全な管理者権限を付与し、Kubernetes 承認に Azure RBAC を使用していない場合。 |
| Kubernetes 承認のための Azure RBAC を使用した Microsoft Entra ID | 2 つのロール: Azure Kubernetes Service Arc クラスターのユーザー ロール (前述)。 前に説明した Azure Arc Kubernetes ロールの 1 つ、または独自のカスタム代替ロール。 |
Azure RBAC for Kubernetes 承認が有効になっている場合、 Configuration タブの管理者ロール フィールドは関係ありません。 | Kubernetes の承認には Azure RBAC を使用します。 この方法を使用すると、RoleBindings バインドや ClusterRoleBindings を設定することなく、きめ細かく制御できます。 |
次のステップ
- Kubernetes の承認のための Kubernetes RBAC の使用を開始するには、Microsoft Entra ID と Kubernetes RBAC を使用した Control アクセスに関するページを参照してください
- Kubernetes 承認用の Azure RBAC の使用を開始するには、「 Kubernetes 承認に Azure RBAC を使用する」を参照してください。