RBAC の構成

このトピックでは、Tanzu Kubernetes Grid でロールベースのアクセス制御 (RBAC) を構成する方法について説明します。

RBAC の構成について

クラスタ アクセスに管理者以外の標準の kubeconfig ファイルを使用する場合は、ID 管理を有効にして構成した後に RBAC 認可を構成する必要があります。kubeconfig ファイルの詳細については、以下の「管理者および管理者以外の kubeconfig ファイル」を参照してください。

RBAC 認可を構成するには、管理者以外の標準の kubeconfig ファイルを使用する管理クラスタおよびワークロード クラスタごとに 1 つ以上のロール バインドを作成します。

1. 「ID 管理の構成」で説明するように、ID 管理を有効にして構成したら、管理クラスタに対して 1 つ以上のロール バインドを作成します。手順については、以下の「管理クラスタ用の RBAC の構成」を参照してください。
2. ワークロード クラスタごとに 1 つ以上のロール バインドを作成します。手順については、以下の「ワークロード クラスタ用の RBAC の構成」を参照してください。

ロール バインドの詳細については、以下の「ロールおよびロール バインド」を参照してください。

管理者および管理者以外の kubeconfig ファイル

ユーザーが管理クラスタまたはワークロード クラスタにアクセスできるようにするには、kubeconfig ファイルを生成してから、それらのユーザーとファイルを共有します。クラスタについての管理者の kubeconfig をユーザーに提供すると、ユーザーにはそのクラスタへのフル アクセス権が付与され、認証が必要なくなります。しかし、管理者以外の標準の kubeconfig をユーザーに提供した場合、ユーザーには OIDC または LDAP の ID プロバイダにユーザー アカウントが必要になります。また、指定したユーザーにアクセス権限を付与するため、クラスタで RBAC を構成する必要があります。

管理クラスタまたはワークロード クラスタの kubeconfig ファイルを生成するには、管理クラスタに対して tanzu mc kubeconfig get を実行するか、ワークロード クラスタに対して tanzu cluster kubeconfig get を実行します。--admin オプションの有無にかかわらず、これらのコマンドのいずれかを実行すると、コマンドは次のように動作します。

• --admin を指定した場合、コマンドは、組み込みの認証情報を含む、管理者の kubeconfig を生成します。この admin バージョンの kubeconfig を使用すると、これを共有するユーザーはクラスタへのフル アクセス権を持ち、ID プロバイダ (IdP) の認証はバイパスされます。
• --admin を指定しない場合、コマンドは、管理者以外の標準の kubeconfig を生成し、外部 ID プロバイダを使用した認証をユーザーに促します。その後、ID プロバイダがユーザーの ID を確認すると、ユーザーはクラスタのリソースにアクセスできるようになります。

これらのコマンドの詳細については、次を参照してください。

• 管理クラスタの取得 (kubeconfig)
• ワークロード クラスタ kubeconfig の取得

ロールおよびロール バインド

ロールは一連の権限を定義します。ロールの定義は、特定の名前空間内で、Role を作成するか、クラスタ全体のロールの場合は ClusterRole を作成することで行えます。対象のロールで定義されている権限をユーザーまたはユーザー グループに付与するには、ロール バインドを作成する必要があります。

リソース	範囲	説明
Role	名前空間	名前空間固有の RoleBinding で使用できる権限を定義します。
ClusterRole	Cluster	ClusterRoleBinding または名前空間固有の RoleBinding で使用できる権限を定義します。
RoleBinding	名前空間	特定の名前空間内で権限を付与します。Role または ClusterRole を参照できます。
ClusterRoleBinding	Cluster	クラスタ内のすべての名前空間で権限を付与します。ClusterRole のみを参照できます。

デフォルトのユーザー ロールは次のとおりです。

• cluster-admin：クラスタへのフル アクセス。RoleBinding で使用する場合、このロールは、バインドで指定された名前空間内の任意のリソースへのフル アクセスを提供します。
• admin：名前空間内のほとんどのリソースへの管理者アクセス。名前空間内でロールとロール バインドを作成および変更できます。
• edit：環境、サービス、ポッドなど、名前空間内のほとんどのオブジェクトへの読み取り/書き込みアクセス。ロールおよびロール バインドを表示、作成、または変更することはできません。
• view：名前空間内のほとんどのオブジェクトへの読み取り専用アクセス。ロールおよびロール バインドを表示、作成、または変更することはできません。

これらのロールの詳細については、Kubernetes ドキュメントの「RBAC 認可を使用する」を参照してください。

管理クラスタ用の RBAC の構成

このセクションでは、次の方法について説明します。

1. 管理クラスタ用の管理者以外の kubeconfig ファイルの生成およびテスト
2. 管理クラスタでのロール バインドの作成

管理クラスタ用の管理者以外の kubeconfig ファイルの生成およびテスト

この手順では、tanzu および kubectl コマンドを実行しているマシンにブラウザがある場合に、認証プロセスのログイン手順をテストできます。マシンにブラウザがない場合は、「ブラウザを使用しないマシンでのユーザー認証」を参照してください。

1. 管理クラスタの標準の kubeconfig をローカル ファイルにエクスポートします（例：/tmp/id_mgmt_test_kubeconfig）。コマンドには --admin オプションが含まれていないため、エクスポートされる kubeconfig は、admin バージョンではなく、標準の kubeconfig です。

   tanzu mc kubeconfig get --export-file /tmp/id_mgmt_test_kubeconfig
   

   「You can now access the cluster by specifying '--kubeconfig /tmp/id_mgmt_test_kubeconfig' flag when using 'kubectl' command」という確認メッセージが表示されるはずです。

2. 新しく作成した kubeconfig ファイルを使用して、管理クラスタに接続します。

   kubectl get pods -A --kubeconfig /tmp/id_mgmt_test_kubeconfig
   

   認証プロセスでは、ユーザーがクラスタへの接続に使用するマシンにブラウザがあることが必須です。これは、kubectl コマンドを実行すると、ユーザーがクラスタにログインするための IdP ログイン ページが自動的に開くためです。ブラウザが開き、OIDC プロバイダのログイン ページまたは LDAPS ログイン ページが表示されます。

   LDAPS：

   

   OIDC：

   

   OIDC または LDAP サーバに存在するユーザー アカウントの認証情報を入力します。ログインに成功すると、ブラウザに次の情報が表示されます。

   

3. tanzu および kubectl コマンドを実行するターミナルに戻ります。

   • 認証済みユーザーのクラスタでロール バインドをすでに構成している場合は、kubectl get pods -A の出力が表示され、ポッド情報が示されます。

   • クラスタでロール バインドを構成していない場合は、ポッドへのユーザー アカウント アクセスを拒否するメッセージが表示されます。Error from server (Forbidden): pods is forbidden: User "[email protected]" cannot list resource "pods" in API group "" at the cluster scope。これは、ユーザーが正常に認証されたが、クラスタ上のリソースにアクセスする権限がまだないことが原因で発生します。ユーザーによるクラスタ リソースへのアクセスを許可するには、次に説明するように、管理クラスタでロール バインドを作成する必要があります。

管理クラスタでのロール バインドの作成

管理者以外のユーザーに管理クラスタへのアクセス権を付与するには、上記の「管理クラスタ用の管理者以外の kubeconfig ファイルの生成およびテスト」の説明に従って、kubeconfig ファイルを生成して配布します。この kubeconfig を機能させるには、まず管理クラスタにロール バインドを作成して RBAC を設定する必要があります。このロール バインドは、認証された個々のユーザーまたはユーザー グループにロールベースの権限を割り当てます。

ロール バインドを作成するには、次の手順を実行します。

1. 管理クラスタの admin コンテキストを使用していることを確認します。

   kubectl config current-context
   

   コンテキストが管理クラスタの admin コンテキストでない場合は、そのコンテキストを使用するように kubectl を設定します。例：

   kubectl config use-context id-mgmt-test-admin@id-mgmt-test
   

2. 既存のロールを一覧表示します。

   • 名前空間の範囲内にあるロールの完全なリストを表示するには、次のコマンドを実行します。

     kubectl get roles --all-namespaces
     

   • クラスタの範囲内にあるロールの完全なリストを表示するには、次のコマンドを実行します。

     kubectl get clusterroles
     

3. 特定のユーザーをロールに関連付けるには、ロール バインドを作成します。

   • RoleBinding は、Role または ClusterRole を参照できます。
   • ClusterRoleBinding は ClusterRole のみ参照できます。

   次の例では、id-mgmt-test-rb という名前のクラスタ ロール バインドを作成し、クラスタ ロール cluster-admin をユーザー [email protected] にバインドします。

   kubectl create clusterrolebinding id-mgmt-test-rb --clusterrole cluster-admin --user [email protected]
   

   --user の場合は、ユーザーの OIDC または LDAP ユーザー名を指定します。username 属性およびその他の ID プロバイダの詳細は、Tanzu Kubernetes Grid インストーラ インターフェイスの ID 管理セクションで構成したか、LDAP_* または OIDC_* 変数を設定して構成済みです。

   • OIDC：username 属性は、インストーラ インターフェイスの [OIDC ID 管理ソース (OIDC Identity Management Source)] にある [ユーザー名の要求 (Username Claim)] フィールド、または OIDC_IDENTITY_PROVIDER_USERNAME_CLAIM 構成変数で設定されます。
   • LDAPS：username 属性は、インストーラ インターフェイスの [LDAPS ID 管理ソース (LDAPS Identity Management Source)] -> [ユーザー検索属性 (User Search Attributes)] にある [ユーザー名 (Username)] フィールド、または LDAP_USER_SEARCH_NAME_ATTRIBUTE 構成変数で設定されます。

   たとえば、OIDC の場合、ユーザー名は通常、ユーザーのメール アドレスです。LDAPS の場合、これは LDAP ユーザー名であり、メール アドレスではありません。

4. 前の手順で作成した kubeconfig ファイルを使用して、管理クラスタへの接続を再試行します。

   kubectl get pods -A --kubeconfig /tmp/id_mgmt_test_kubeconfig
   

   今回は、ユーザーがこの管理クラスタの cluster-admin ロールにバインドされているため、ポッドのリストが表示されます。生成された kubeconfig ファイルは、管理クラスタでロール バインドを構成したすべてのユーザーと共有できます。

ワークロード クラスタ用の RBAC の構成

このセクションでは、次の方法について説明します。

• ワークロード クラスタ用の管理者以外の kubeconfig ファイルの生成およびテスト
• ワークロード クラスタでのロール バインドの作成

ワークロード クラスタ用の管理者以外の kubeconfig ファイルの生成およびテスト

この手順では、tanzu および kubectl コマンドを実行しているマシンにブラウザがある場合に、認証プロセスのログイン手順をテストできます。マシンにブラウザがない場合は、「ブラウザを使用しないマシンでのユーザー認証」を参照してください。

ワークロード クラスタでユーザーを認証するには、次の手順を実行します。

1. ワークロード クラスタの管理者以外の標準の kubeconfig を取得し、ファイルにエクスポートします。次の例では、クラスタ my-cluster の kubeconfig を my-cluster-kubeconfig ファイルにエクスポートします。

   tanzu cluster kubeconfig get my-cluster --export-file /tmp/my-cluster-kubeconfig
   

2. 生成されたファイルを使用して、クラスタで操作を実行します。たとえば、次を実行します。

   kubectl get pods -A --kubeconfig /tmp/my-cluster-kubeconfig
   

   ID プロバイダのログイン ページにリダイレクトされます。認証済みユーザーのクラスタでロール バインドをすでに構成している場合は、ID プロバイダのユーザー アカウントを使用して正常にログインした後、出力にポッド情報が表示されます。

   クラスタでロール バインドを構成していない場合は、「Error from server (Forbidden): pods is forbidden: User "<user>" cannot list resource "pods" in API group "" at the cluster scope」というメッセージが表示されます。これは、このユーザーがまだクラスタに対する権限を持っていないために発生します。クラスタ リソースへのアクセスをユーザーに許可するには、ワークロード クラスタでロール バインドを作成する必要があります。

ワークロード クラスタでのロール バインドの作成

ワークロード クラスタの ID 管理構成を完了するには、前の手順で生成した kubeconfig を使用するユーザーのロール バインドを作成する必要があります。

1. kubectl コンテキストをワークロード クラスタの admin kubeconfig に設定します。ロール バインドを作成するには、ワークロード クラスタの admin コンテキストに切り替える必要があります。たとえば、次の 2 つのコマンドを実行して、admin コンテキストに変更します。

   1. kubeconfig を取得します。

      tanzu cluster kubeconfig get my-cluster --admin
      

   2. コンテキストを切り替えます。

      kubectl config use-context my-cluster-admin@my-cluster
      

2. 既存のロールを表示するには、次を実行します。

   • 名前空間の範囲内にあるロールの完全なリストを表示するには、次のコマンドを実行します。

     kubectl get roles --all-namespaces
     

   • クラスタの範囲内にあるロールの完全なリストを表示するには、次のコマンドを実行します。

     kubectl get clusterroles
     

3. 特定のユーザーをロールに関連付けるには、ロール バインドを作成します。

   • RoleBinding は、Role または ClusterRole を参照できます。
   • ClusterRoleBinding は ClusterRole のみ参照できます。

   次の例では、workload-test-rb という名前のクラスタ ロール バインドを作成し、クラスタ ロール cluster-admin をユーザー [email protected] にバインドします。

   kubectl create clusterrolebinding workload-test-rb --clusterrole cluster-admin --user [email protected]
   

   --user の場合は、ユーザーの OIDC または LDAP ユーザー名を指定します。username 属性およびその他の ID プロバイダの詳細は、Tanzu Kubernetes Grid インストーラ インターフェイスの ID 管理セクションで構成したか、LDAP_* または OIDC_* 変数を設定して構成済みです。

   • OIDC：username 属性は、インストーラ インターフェイスの [OIDC ID 管理ソース (OIDC Identity Management Source)] にある [ユーザー名の要求 (Username Claim)] フィールド、または OIDC_IDENTITY_PROVIDER_USERNAME_CLAIM 構成変数で設定されます。
   • LDAPS：username 属性は、インストーラ インターフェイスの [LDAPS ID 管理ソース (LDAPS Identity Management Source)] -> [ユーザー検索属性 (User Search Attributes)] にある [ユーザー名 (Username)] フィールド、または LDAP_USER_SEARCH_NAME_ATTRIBUTE 構成変数で設定されます。

   たとえば、OIDC の場合、ユーザー名は通常、ユーザーのメール アドレスです。LDAPS の場合、これは LDAP ユーザー名であり、メール アドレスではありません。

4. 上記で生成した標準の kubeconfig ファイルを使用して、クラスタで操作を再実行します。たとえば、次を実行します。

   kubectl get pods -A --kubeconfig /tmp/my-cluster-kubeconfig
   

   今回は、ワークロード クラスタで実行されているポッドのリストが表示されます。これは、my-cluster-kubeconfig ファイルのユーザーが ID プロバイダによって認証され、さらに、クラスタに対して必要な権限を持っているためです。my-cluster-kubeconfig ファイルは、クラスタでロール バインドを構成したすべてのユーザーと共有できます。

次の手順

生成された kubeconfig ファイルを他のユーザーと共有して、クラスタへのアクセスを許可します。