ID 管理の構成

このトピックでは、スタンドアローン管理クラスタを使用して、Tanzu Kubernetes Grid (TKG) で ID 管理を有効にして構成する方法について説明します。

ID 管理の有効化と構成について

LDAPS または OIDC の ID プロバイダを構成することで、管理クラスタの展開中または展開後に ID 管理を有効にできます。ID 管理を有効にした後に作成するワークロード クラスタは、管理クラスタと同じ ID プロバイダを使用するように自動的に構成されます。新たに有効にした ID 管理を使用して，既存のワークロード クラスタを遡って構成するには、「ワークロード クラスタでの ID 管理の有効化」の説明に従ってください。

ID 管理を有効にして構成するには、次の手順を実行します。管理クラスタおよびワークロード クラスタにアクセスするために、管理者以外の標準の kubeconfig ファイルを使用する場合は、このトピックの手順を完了した後、「RBAC の構成」の手順に従って、ロールベースのアクセス制御 (RBAC) を構成する必要があります。

（推奨）管理クラスタの展開中に ID 管理を有効にして構成するには：

1. ID プロバイダの詳細を取得します。
2. 取得した詳細を使用して、Tanzu Kubernetes Grid で LDAPS または OIDC を構成します。
3. 管理クラスタが作成されたら、認証サービスが正しく実行されていることを確認し、構成を完了します。

手順については、以下の「（推奨）管理クラスタの展開中の ID 管理の有効化と構成」を参照してください。

管理クラスタの展開後に ID 管理を有効にして構成するには：

1. ID プロバイダの詳細を取得します。
2. 管理クラスタの Pinniped アドオン シークレットを生成します。
3. 認証サービスが正しく実行されていることを確認し、構成を完了します。
4. 管理クラスタがワークロード クラスタを管理する場合は、ID 管理を有効にする前に作成されたワークロード クラスタごとに Pinniped アドオン シークレットを生成します。

手順については、以下の「既存の環境での ID 管理の有効化と構成」を参照してください。

（推奨）管理クラスタの展開中の ID 管理の有効化と構成

このセクションでは、管理クラスタの展開中に ID 管理を有効にして構成する方法について説明します。

ID プロバイダの詳細の取得

ID 管理を有効にするには、ID プロバイダが必要です。Tanzu Kubernetes Grid は、LDAPS および OIDC の ID プロバイダをサポートします。

• 会社の内部 LDAPS サーバを ID プロバイダとして使用するには、LDAP 管理者から LDAPS 情報を取得します。
• OIDC を ID プロバイダとして使用するには、OpenID Connect 標準をサポートする ID プロバイダのアカウント（Okta など）が必要です。

例：Okta での Tanzu Kubernetes Grid アプリケーションの登録

Okta を OIDC プロバイダとして使用するには、Okta でアカウントを作成し、アカウントに Tanzu Kubernetes Grid のアプリケーションを登録する必要があります。

1. Okta アカウントがない場合は、Okta アカウントを作成します。
2. [管理 (Admin)] ボタンをクリックして管理ポータルに移動します。
3. [アプリケーション (Applications)] に移動し、[アプリケーションの追加 (Add Application)] をクリックします。
4. [新しいアプリケーションの作成 (Create New App)] をクリックします。
5. [プラットフォーム (Platform)] で [Web] を選択し、[サインオン方法 (Sign on method)] で [OpenID Connect] を選択して、[作成 (Create)] をクリックします。
6. アプリケーションに名前を付けます。
7. プレースホルダ [ログイン リダイレクト URI (Login redirect URI)] を入力します。たとえば、「http://localhost:8080/callback」と入力します。管理クラスタを展開した後、実際の URL でこれを更新します。
8. 保存 をクリックします。
9. アプリケーションの [全般 (General)] タブで、[クライアント ID (Client ID)] および [クライアント シークレット (Client secret)] をコピーして保存します。これらの認証情報は、管理クラスタを展開するときに必要になります。
10. [割り当て (Assignments)] タブで、アプリケーションにユーザーとグループを割り当てます。アプリケーションに割り当てるユーザーとグループは、管理クラスタ、およびそれを使用して展開するワークロード クラスタにアクセスできるユーザーです。

Tanzu Kubernetes Grid での LDAPS または OIDC 設定の構成

上記で取得した詳細を使用して、Tanzu Kubernetes Grid で LDAPS または OIDC を構成します。

• インストーラ インターフェイスを使用して管理クラスタを展開する場合は、[ID 管理 (Identity Management)] セクションで [LDAPS] または [OIDC] を構成します。手順については、「インストーラ インターフェイスを使用した管理クラスタの展開」の「ID 管理の構成」を参照してください。

• 構成ファイルから管理クラスタを展開する場合は、構成ファイルで LDAP_* または OIDC_* 変数を設定します。

  例：

  LDAP：

  IDENTITY_MANAGEMENT_TYPE: ldap
  LDAP_BIND_DN: ""
  LDAP_BIND_PASSWORD: ""
  LDAP_GROUP_SEARCH_BASE_DN: dc=example,dc=com
  LDAP_GROUP_SEARCH_FILTER: (objectClass=posixGroup)
  LDAP_GROUP_SEARCH_GROUP_ATTRIBUTE: memberUid
  LDAP_GROUP_SEARCH_NAME_ATTRIBUTE: cn
  LDAP_GROUP_SEARCH_USER_ATTRIBUTE: uid
  LDAP_HOST: ldaps.example.com:636
  LDAP_ROOT_CA_DATA_B64: ""
  LDAP_USER_SEARCH_BASE_DN: ou=people,dc=example,dc=com
  LDAP_USER_SEARCH_FILTER: (objectClass=posixAccount)
  LDAP_USER_SEARCH_NAME_ATTRIBUTE: uid
  LDAP_USER_SEARCH_USERNAME: uid
  

  OIDC：

  IDENTITY_MANAGEMENT_TYPE: oidc
  OIDC_IDENTITY_PROVIDER_CLIENT_ID: 0oa2i[...]NKst4x7
  OIDC_IDENTITY_PROVIDER_CLIENT_SECRET: 331!b70[...]60c_a10-72b4
  OIDC_IDENTITY_PROVIDER_GROUPS_CLAIM: groups
  OIDC_IDENTITY_PROVIDER_ISSUER_URL: https://dev-[...].okta.com
  OIDC_IDENTITY_PROVIDER_SCOPES: openid,groups,email
  OIDC_IDENTITY_PROVIDER_USERNAME_CLAIM: email
  

  管理クラスタ構成ファイルの準備方法については、「管理クラスタ構成ファイルの作成」を参照してください。

注

Dex ポッドは、Dex TLS 証明書の有効期限が切れるたび（デフォルトは 90 日）に手動でローテーションする必要があります。CERT_DURATION を使用して、証明書の有効期間を延長できます。Dex ポッドを再起動するには、kubectl rollout restart deployments/dex -n tanzu-system-auth を実行します。

ID 管理の構成の完了

管理クラスタが展開されたら、次のセクションで説明する手順に従って ID 管理の構成を完了します。

1. kubectl を管理クラスタに接続します。
2. ステータスを確認して、認証サービスが正しく実行されていることを確認します。
   • OIDC：OIDC ID 管理サービスのステータスを確認します。
   • LDAP：LDAP ID 管理サービスのステータスを確認します。
3. OIDC：OIDC プロバイダにコールバック URI を指定します。
4. 管理クラスタにアクセスするための管理者以外の標準の kubeconfig ファイルの使用をサポートするには、管理クラスタ用の RBAC を構成してください。

管理クラスタへの kubectl の接続

ID 管理を構成するには、管理クラスタの admin コンテキストを取得して使用する必要があります。

1. 管理クラスタの admin コンテキストを取得します。このトピックの手順では、id-mgmt-test という名前の管理クラスタを使用します。

   tanzu mc kubeconfig get id-mgmt-test --admin
   

   管理クラスタの名前が id-mgmt-test の場合は、「Credentials of workload cluster 'id-mgmt-test' have been saved. You can now access the cluster by running 'kubectl config use-context id-mgmt-test-admin@id-mgmt-test'」という確認メッセージが表示されるはずです。クラスタの admin コンテキストを使用すると、IDP による認証を必要とせずにクラスタにフル アクセスできます。

2. kubectl を管理クラスタの admin コンテキストに設定します。

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

OIDC ID 管理サービスのステータスの確認

Tanzu Kubernetes Grid は、Pinniped を使用してクラスタを OIDC ID サービスと統合します。OIDC を有効にすると、Tanzu Kubernetes Grid は、pinniped-supervisor サービスを pinniped-supervisor 名前空間に作成し、pinniped-concierge を pinniped-concierge 名前空間に作成します。次の手順に従って Pinniped サービスのステータスを確認し、サービスが公開されている EXTERNAL-IP アドレスを書き留めます。

1. 管理クラスタで実行されているサービスに関する情報を取得します。ID 管理サービスは、pinniped-supervisor 名前空間で実行されます。

   kubectl get services -n pinniped-supervisor
   

   出力には次のエントリが表示されます。

   NSX Advanced Load Balancer (ALB) を使用する vSphere：

   NAME                          TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)          AGE
   service/pinniped-supervisor   LoadBalancer   100.70.70.12   20.52.230.18   5556:31234/TCP   84m
   

   Amazon Web Services (AWS)：

   NAME                          TYPE           CLUSTER-IP     EXTERNAL-IP                              PORT(S)         AGE
   service/pinniped-supervisor   LoadBalancer   100.69.13.66   ab1[...]71.eu-west-1.elb.amazonaws.com   443:30865/TCP   56m
   

   Azure：

   NAME                          TYPE           CLUSTER-IP       EXTERNAL-IP      PORT(S)         AGE
   service/pinniped-supervisor   LoadBalancer   100.69.169.220   20.54.226.44     443:30451/TCP   84m
   

   NSX ALB を使用しない vSphere：

   NAME                          TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
   service/pinniped-supervisor   NodePort   100.70.70.12   <none>        5556:31234/TCP   84m
   

2. 次の情報を書き留めてください。

   • NSX ALB を使用する vSphere、AWS、および Azure：EXTERNAL-IP にリストされている、pinniped-supervisor サービスの外部アドレスを書き留めます。
   • NSX ALB を使用しない vSphere：pinniped-supervisor サービスが実行されているポートを書き留めます。上記の例では、このポートは 31234 です。

3. 管理クラスタ内のすべてのサービスが実行されていることを確認します。

   kubectl get pods -A
   

   Pinniped サービスが起動して実行されるまで数分かかる場合があります。たとえば、AWS 環境と Azure 環境では、サービスは LoadBalancer の IP アドレスの準備が整うのを待つ必要があります。次の手順に進む前に、pinniped-post-deploy-job が完了したことを確認してください。

   NAMESPACE             NAME                                   READY  STATUS      RESTARTS  AGE
   [...]
   pinniped-supervisor   pinniped-post-deploy-job-hq8fc         0/1    Completed   0         85m
   

注

kubectl get pods を実行できるのは、管理クラスタの admin コンテキストを使用しているためです。通常のコンテキストを使用して管理クラスタに接続しようとするユーザーは、リソースにアクセスできません。これは、まだアクセスする権限がないためです。

LDAP ID 管理サービスのステータスの確認

Tanzu Kubernetes Grid は、Pinniped を使用してクラスタを LDAP ID サービスと統合し、Dex を使用してサービス エンドポイントを公開します。LDAP を有効にすると、Tanzu Kubernetes Grid は pinniped-supervisor サービスを pinniped-supervisor 名前空間に作成し、pinniped-concierge を pinniped-concierge 名前空間に作成し、dexsvc を tanzu-system-auth 名前空間に作成します。次の手順に従って LDAP サービスのステータスを確認し、サービスが公開されている EXTERNAL-IP アドレスを書き留めます。

1. tanzu-system-auth 名前空間の管理クラスタで実行されているサービスに関する情報を取得します。

   kubectl get services -n tanzu-system-auth
   

   出力には次のエントリが表示されます。

   NSX ALB を使用する vSphere：

   NAME             TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)          AGE
   service/dexsvc   LoadBalancer   100.70.70.12   20.52.230.18   443:30167/TCP   84m
   

   AWS：

   NAME             TYPE           CLUSTER-IP       EXTERNAL-IP                              PORT(S)         AGE
   service/dexsvc   LoadBalancer   100.65.184.107   a6e[...]74.eu-west-1.elb.amazonaws.com   443:32547/TCP   84m
   

   Azure：

   NAME             TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)         AGE
   service/dexsvc   LoadBalancer   100.69.169.220   20.54.226.44  443:30451/TCP   84m
   

   NSX ALB を使用しない vSphere：

   NAME             TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
   service/dexsvc   NodePort   100.70.70.12   <none>        5556:30167/TCP   84m
   

2. 管理クラスタ内のすべてのサービスが実行されていることを確認します。

   kubectl get pods -A
   

   Pinniped サービスが起動して実行されるまで数分かかる場合があります。たとえば、AWS 環境と Azure 環境では、サービスは LoadBalancer の IP アドレスの準備が整うのを待つ必要があります。次の手順に進む前に、pinniped-post-deploy-job が完了したことを確認してください。

   NAMESPACE             NAME                                   READY  STATUS      RESTARTS  AGE
   [...]
   pinniped-supervisor   pinniped-post-deploy-job-hq8fc         0/1    Completed   0         85m
   

   注

   kubectl get pods を実行できるのは、管理クラスタの admin コンテキストを使用しているためです。通常のコンテキストを使用して管理クラスタに接続しようとするユーザーは、リソースにアクセスできません。これは、まだアクセスする権限がないためです。

3. 「管理クラスタ用の RBAC の構成」に進みます。

（OIDC のみ）OIDC プロバイダへのコールバック URI の指定

OIDC 認証を使用するように管理クラスタを構成した場合は、その管理クラスタのコールバック URI を OIDC ID プロバイダに提供する必要があります。たとえば、OIDC を使用していて、IDP が Okta の場合は、次の手順を実行します。

1. Okta アカウントにログインします。
2. メイン メニューで、[アプリケーション (Applications)] に移動します。
3. Tanzu Kubernetes Grid 用に作成したアプリケーションを選択します。
4. [全般設定 (General Settings)] パネルで、[編集 (Edit)] をクリックします。

5. [ログイン (Login)] で、pinniped-supervisor が実行されているノードのアドレスを含めるように [ログイン リダイレクト URI (Login redirect URIs)] を更新します。

   • NSX ALB を使用する vSphere、AWS、および Azure：前の手順で書き留めた pinniped-supervisor サービスの外部 IP アドレスとポート番号を追加します。

     https://EXTERNAL-IP/callback
     

   • NSX ALB を使用しない vSphere：API エンドポイントとして設定した IP アドレスと、前の手順で書き留めた pinniped-supervisor ポート番号を追加します。

     https://API-ENDPOINT-IP:31234/callback
     

     いずれの場合も、httpではなく https を指定する必要があります。

6. 保存 をクリックします。

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

管理クラスタへのアクセスに管理者以外の標準の kubeconfig ファイルを使用するよう計画している場合は、ID 管理の構成が完了したら、「管理クラスタ用の RBAC の構成」の手順に従って RBAC を構成します。

既存の環境での ID 管理の有効化と構成

このセクションでは、既存の環境で ID 管理を有効にして構成する方法について説明します。

ID プロバイダの詳細の取得

上記の「ID プロバイダの詳細の取得」の説明に従ってください。

管理クラスタの Pinniped アドオン シークレットの生成

この手順では、Pinniped アドオンを構成し、管理クラスタに認証コンポーネントを展開します。Pinniped アドオンの Kubernetes シークレットを生成するには、次の手順を実行します。

1. kubectl のコンテキストを管理クラスタに設定します。たとえば、id-mgmt-test という名前の管理クラスタの場合は次のようになります。

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

2. 管理クラスタを展開したときに定義した構成設定を新しいファイルにコピーして、クラスタ構成ファイルを作成します。OIDC や LDAP などの ID プロバイダの詳細など、次の設定を管理クラスタ構成ファイルに追加します。

   注

   これらの変数は管理クラスタにのみ設定する必要があります。

   # Identity management type. This must be "oidc" or "ldap".
   
   IDENTITY_MANAGEMENT_TYPE:
   
   # Explicitly set the namespace, which for management clusters is "tkg-system".
   
   NAMESPACE: tkg-system
   
   # Set these variables if you want to configure OIDC.
   
   OIDC_IDENTITY_PROVIDER_CLIENT_ID:
   OIDC_IDENTITY_PROVIDER_CLIENT_SECRET:
   OIDC_IDENTITY_PROVIDER_GROUPS_CLAIM:
   OIDC_IDENTITY_PROVIDER_ISSUER_URL:
   OIDC_IDENTITY_PROVIDER_SCOPES: "email,profile,groups"
   OIDC_IDENTITY_PROVIDER_USERNAME_CLAIM:
   
   # Set these variables if you want to configure LDAP.
   
   LDAP_BIND_DN:
   LDAP_BIND_PASSWORD:
   LDAP_GROUP_SEARCH_BASE_DN:
   LDAP_GROUP_SEARCH_FILTER:
   LDAP_GROUP_SEARCH_GROUP_ATTRIBUTE:
   LDAP_GROUP_SEARCH_NAME_ATTRIBUTE: cn
   LDAP_GROUP_SEARCH_USER_ATTRIBUTE: DN
   LDAP_HOST:
   LDAP_ROOT_CA_DATA_B64:
   LDAP_USER_SEARCH_BASE_DN:
   LDAP_USER_SEARCH_EMAIL_ATTRIBUTE: DN
   LDAP_USER_SEARCH_FILTER:
   LDAP_USER_SEARCH_ID_ATTRIBUTE: DN
   LDAP_USER_SEARCH_NAME_ATTRIBUTE:
   LDAP_USER_SEARCH_USERNAME: userPrincipalName
   
   # Set these variables if you want to configure certificate duration
   
   CERT_DURATION: 2160h
   CERT_RENEW_BEFORE: 360h
   

   これらの変数のうちどれがオプションで省略可能かを確認するには、ID プロバイダを構成する際の変数（OIDC 用）および ID プロバイダを構成する際の変数（LDAP 用）を参照してください。

   管理クラスタがプロキシの背後にある場合は、新しい構成ファイルにプロキシ構成の詳細が含まれていることを確認します。

   TKG_HTTP_PROXY:
   TKG_HTTPS_PROXY:
   TKG_NO_PROXY:
   

   これらの変数の詳細については、プロキシ構成の説明を参照してください。

   vSphere：内部チェックに合格するためのダミー値として、VSPHERE_CONTROL_PLANE_ENDPOINT 構成設定を未使用の IP アドレスに変更します。

3. ローカル環境で、IDENTITY_MANAGEMENT_TYPE が oidc または ldap のいずれかに設定されており、none に設定されていないことを確認します。

   echo $IDENTITY_MANAGEMENT_TYPE
   

   この変数が none に設定されている場合は、export コマンドを実行して、oidc または ldap に設定し直します。

4. _TKG_CLUSTER_FORCE_ROLE 環境変数を management に設定します。

   export _TKG_CLUSTER_FORCE_ROLE="management"
   

   Windows で、SET コマンドを使用します。

5. FILTER_BY_ADDON_TYPE 環境変数を authentication/pinniped に設定して、tanzu cluster create が Pinniped 関連のオブジェクトでのみ動作するようにします。

   export FILTER_BY_ADDON_TYPE="authentication/pinniped"
   

6. Pinniped アドオンのシークレットを生成します。

   tanzu cluster create CLUSTER-NAME --dry-run -f CLUSTER-CONFIG-FILE > CLUSTER-NAME-example-secret.yaml
   

   ここで、

   • CLUSTER-NAME はターゲット管理クラスタの名前です。
   • CLUSTER-CONFIG-FILE は、上記で作成した構成ファイルです。

   環境変数の設定により、tanzu cluster create --dry-run が完全なクラスタ マニフェストではなく Kubernetes シークレットを生成します。

7. シークレットを確認してから、管理クラスタに適用します。例：

   kubectl apply -f CLUSTER-NAME-example-secret.yaml
   

8. シークレットを適用したら、kubectl get app コマンドを実行して、Pinniped アドオンのステータスを確認します。

   $ kubectl get app CLUSTER-NAME-pinniped -n tkg-system
   NAME           DESCRIPTION             SINCE-DEPLOY    AGE
   pinniped       Reconcile succeeded     3m23s           7h50m
   

   返されたステータスが Reconcile failed の場合は、次のコマンドを実行してエラーの詳細を取得します。

   kubectl get app CLUSTER-NAME-pinniped -n tkg-system -o yaml
   

ID 管理の構成の完了

上記の「ID 管理の構成の完了」の説明に従ってください。

ワークロード クラスタでの ID 管理の有効化

管理クラスタで ID 管理を有効にしたときに作成するワークロード クラスタは、同じ ID 管理サービスを使用するように自動的に構成されます。

ブラウザを使用しないマシンでのユーザー認証

ブートストラップ マシンがジャンプボックスなどのディスプレイのないマシンである場合は、ローカル マシンで実行されているブラウザからクラスタへの認証を行うことができます。これを行う方法は、クラスタの Pinniped バージョン（クラスタがベースとしている Tanzu Kubernetes リリースに基づく）によって異なります。

クラスタ TKr のバージョン	ブラウザレスの認証手順
TKr v1.23.10（Tanzu Kubernetes Grid v1.6.1 のデフォルト）以降	以下の手順を参照してください。
古い TKr に基づくクラスタ、または古いバージョンの Tanzu Kubernetes Grid によって作成されたクラスタ	Tanzu Kubernetes Grid v1.4 ドキュメントの「Authenticate Users on a Machine Without a Browser」の手順に従ってください。

注

Tanzu Kubernetes Grid v2.2 では、非インタラクティブなアカウントまたはパスワード付与に基づくブラウザレス CLI ログインはサポートされていません。

1. ローカル マシンのターミナル ウィンドウから ssh を実行して、ブートストラップ マシンにリモートでログインします。

2. TANZU_CLI_PINNIPED_AUTH_LOGIN_SKIP_BROWSER=true 環境変数を設定します。これにより、--skip-browser オプションがクラスタの kubeconfig に追加されます。

   # Linux
   export TANZU_CLI_PINNIPED_AUTH_LOGIN_SKIP_BROWSER=true
   # Windows
   set TANZU_CLI_PINNIPED_AUTH_LOGIN_SKIP_BROWSER=true
   

3. クラスタの標準の kubeconfig をローカル ファイルにエクスポートします。コマンドには --admin オプションが含まれていないため、エクスポートされる kubeconfig は、admin バージョンではなく、標準の kubeconfig です。たとえば、kubeconfig ファイルを /tmp/my-cluster-kubeconfig にエクスポートするには、次の手順を実行します。

   • 管理クラスタの場合は、次のコマンドを実行します。

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

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

   • ワークロード クラスタの場合は、次のコマンドを実行します。

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

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

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

   CLI は、ID プロバイダのログイン リンクを出力します。例：

   Log in by visiting this link:
   
      https://10.180.105.166:31234/oauth2/authorize?access_type=offline&client_id=pinniped-cli&code_challenge=-aJ617vJZXZeEnHPab1V2_VHPmc5VwspFig5QQKyTwg&code_challenge_method=S256&nonce=cafaf8f4d2cb714ef8fb3320c1b088ba&redirect_uri=http%3A%2F%2F127.0.0.1%3A33087%2Fcallback&response_mode=form_post&response_type=code&scope=offline_access+openid+pinniped%3Arequest-audience&state=fff3d4d46b36359d5ba2f24fad471dd8
   
      Optionally, paste your authorization code:
   

5. リンクをコピーし、ローカル マシンのブラウザに貼り付けます。

6. ブラウザで、ID プロバイダにログインします。認証コードを CLI に貼り付けるよう求めるページが表示されます。

   

7. 認証コードをコピーして、CLI の「Optionally, paste your authorization code:」プロンプトの後に貼り付けます。

8. 以前に使用したのと同じ kubeconfig ファイルを使用して、クラスタに再度接続します。

   kubectl get pods -A --kubeconfig FILE-PATH
   

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

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

     • 「管理クラスタでのロール バインドの作成」を参照してください。
     • 「ワークロード クラスタでのロール バインドの作成」を参照してください。

管理クラスタ展開後の Dex 設定の更新

Pinniped コンポーネントは、LDAP ID プロバイダに Dex を使用します。OIDC ID プロバイダの場合、Dex は使用されません。

管理クラスタ用の Pinniped シークレットの values.yaml セクションで、dex. から始まる設定を更新するには、次の手順を実行する必要があります。

1. 更新する dex. 設定を特定します。「Auto-Managed Package values.yaml Settings」の表を参照してください。
2. 「Auto-Managed Package values.yaml Settings」で説明するように、管理クラスタ用の Pinniped シークレットを取得します。

3. Pinniped シークレットで、上記で特定した dex. 設定を更新し、次の手順を実行します。

   1. dex.dns.INFRASTRUCTURE-PROVIDER.ipAddresses および dex.config.dns.INFRASTRUCTURE-PROVIDER.dnsNames 配列構成を設定します。これらのフィールドには、0.0.0.0 など、空でない単一のエントリの配列を設定できます（自動的に更新されるため）。
   2. pinniped.upstream_oidc_issuer_url 構成設定に、https で始まる空でない文字列を設定します。たとえば、https://0.0.0.0 などです。このフィールドは、後で自動的に更新されます。
   3. dex.config.staticClients 配列構成設定に単一のエントリを設定します。この設定には、{name: "example-name", id: "example-id", secret: "example-secret"} など、少なくとも name、id、secret キーを含む任意のマップを指定できます（自動的に更新されるため）。

   4. 次のオーバーレイを Pinniped シークレットに追加します。

      #@ load("@ytt:overlay", "overlay")
      #@overlay/match by=overlay.subset({"metadata": {"name" : "upstream-oidc-identity-provider"}})
      ---
      metadata:
        annotations:
          #@overlay/remove
          kapp.k14s.io/update-strategy: always-replace
      

4. Pinniped シークレットを適用します。

5. Pinniped シークレットを適用した後、管理クラスタ内の tanzu-system-auth 名前空間を再起動します。名前空間を再起動するには、Namespace を削除し、pinniped App が再作成されるまで待機します。Pinniped シークレットを適用した後、pinniped-supervisor Namespace の pinniped-post-deploy-job Job を再起動することが必要になる場合があります。これを行うには、Job を削除し、pinniped App が再作成されるまで待機します。

既存の展開での ID 管理の無効化

ID 管理が有効になっている既存の展開で ID 管理を無効化するには、次の手順を実行します。

1. kubectl のコンテキストを管理クラスタに設定します。たとえば、id-mgmt-test という名前の管理クラスタの場合は次のようになります。

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

2. 管理クラスタ構成ファイルを取得し、IDENTITY_MANAGEMENT_TYPE: none を設定するように編集します。

3. --dry-run を使用して tanzu management-cluster create を実行し、Pinniped 関連オブジェクトをフィルタリングして、Pinniped シークレット定義を生成します。

   FILTER_BY_ADDON_TYPE=authentication/pinniped tanzu management-cluster create --dry-run CLUSTER-CONFIG > PINNIPED-SECRET
   

   ここで、CLUSTER-CONFIG はクラスタ構成ファイルで、PINNIPED-SECRET は生成された Pinniped Secret 定義に付ける名前です（例：mc-no-idp.yaml）。

4. 新しいシークレットを適用して、管理クラスタで Pinniped を無効にします。

   kubectl apply -f PINNIPED-SECRET
   

5. 管理クラスタで Pinniped を無効にすると、そのクラスベースのクラスタは自動的に無効化されますが、レガシー クラスタは手動で無効にする必要があります。

   1. 管理クラスタ コンテキストに残っている Pinniped シークレットを一覧表示します。

      kubectl get secret -A | grep pinniped-addon
      

   2. リストされているシークレット名と名前空間を使用して、kubectl get secret 出力内のシークレット（存在する場合）を調べます。

      kubectl get secret SECRET-NAME -n SECRET-NAMESPACE -o yaml
      

   3. 次のいずれかを含むシークレットを削除します。

      • type: tkg.tanzu.vmware.com/addon - これらはレガシー クラスタのシークレットです
      • 任意の OIDC または LDAP 構成

      kubectl delete secret SECRET-NAME
      

      ここで、SECRET-NAME は Secret 仕様で設定された metadata.name の値です。

次の手順

管理者以外の標準の kubeconfig ファイルを使用して、ユーザーによる管理クラスタおよびワークロード クラスタへのアクセスを許可する場合は、RBAC 認可を構成する必要があります。

• 管理クラスタの RBAC を構成するには、「管理クラスタ用の RBAC の構成」の手順に従ってください。
• このトピックの手順を完了したら、ワークロード クラスタの作成を開始できます。ワークロード クラスタの RBAC を構成するには、「ワークロード クラスタ用の RBAC の構成」の手順に従ってください。