ID 管理の構成

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

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

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

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

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

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

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

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

ID プロバイダの詳細を取得します。
管理クラスタの Pinniped アドオンシークレットを生成します。
認証サービスが正しく実行されていることを確認し、構成を完了します。
管理クラスタがワークロードクラスタを管理する場合は、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 のアプリケーションを登録する必要があります。

Okta アカウントがない場合は、Okta アカウントを作成します。
[管理 (Admin)] ボタンをクリックして管理ポータルに移動します。
[アプリケーション (Applications)] に移動し、[アプリケーション統合の作成 (Create App Integration)] をクリックします。
[ログイン方法 (Sign-in method)] で [OIDC - OpenID Connect] を選択し、[アプリケーションタイプ (Application type)] で [Web アプリケーション (Web Application)] を選択して、[次へ (Next)] をクリックします。
アプリケーションに名前を付けます。
[認証タイプ (Grant Type)] の [ユーザーに代わって動作するクライアント (Client acting on behalf of a user)] で、[認証コード (Authorization Code)] と [リフレッシュトークン (Refresh Token)] の両方が選択されていることを確認します。
プレースホルダの [ログインリダイレクト URI (Sign-in redirect URI)] を入力します。たとえば、「http://localhost:8080/authorization-code/callback」と入力します。管理クラスタを展開した後、実際の URL でこれを更新します。
[割り当て (Assignments)] で、アプリケーションにユーザーとグループを割り当てます。アプリケーションに割り当てるユーザーとグループは、管理クラスタ、およびそれを使用して展開するワークロードクラスタにアクセスできるユーザーです。
保存をクリックします。
アプリケーションの [全般 (General)] タブで、[クライアント ID (Client ID)] および [クライアントシークレット (Client secret)] をコピーして保存します。これらの認証情報は、管理クラスタを展開するときに必要になります。

重要
TKG 2.3 以降を使用するには、すべての OIDC プロバイダがリフレッシュトークンを発行するように構成する必要があります。

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: "cn=bind-user,ou=people,dc=example,dc=com"
LDAP_BIND_PASSWORD: "example-password"
LDAP_GROUP_SEARCH_BASE_DN: dc=example,dc=com
LDAP_GROUP_SEARCH_FILTER: &(objectClass=posixGroup)(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)(uid={})
LDAP_USER_SEARCH_NAME_ATTRIBUTE: 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,offline_access
OIDC_IDENTITY_PROVIDER_USERNAME_CLAIM: email

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

ID 管理の構成の完了

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

kubectl を管理クラスタに接続します。
「ID 管理サービスのステータスの確認」の説明に従って、認証サービスのステータスを確認して、正しく実行されていることを確認します。
（OIDC のみ）OIDC プロバイダへのコールバック URI を指定します。
管理クラスタにアクセスするための管理者以外の標準の kubeconfig ファイルの使用をサポートするには、管理クラスタ用の RBAC を構成してください。

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

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

管理クラスタの 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 による認証を必要とせずにクラスタにフルアクセスできます。
kubectl を管理クラスタの admin コンテキストに設定します。
```
kubectl config use-context id-mgmt-test-admin@id-mgmt-test
```

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

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

管理クラスタで実行されているサービスに関する情報を取得します。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

次の情報を書き留めてください。
- NSX ALB を使用する vSphere、AWS、および Azure：EXTERNAL-IP にリストされている、pinniped-supervisor サービスの外部アドレスを書き留めます。
- NSX ALB を使用しない vSphere：pinniped-supervisor サービスが実行されているポートを書き留めます。上記の例では、このポートは 31234 です。
管理クラスタ内のすべてのサービスが実行されていることを確認します。
```
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 サービスと統合して、サービスエンドポイントを公開します。LDAP を有効にすると、Tanzu Kubernetes Grid は、pinniped-supervisor サービスを pinniped-supervisor 名前空間に作成し、pinniped-concierge サービスを pinniped-concierge 名前空間に作成します。

管理クラスタ内のすべてのサービスが実行されていることを確認します。
```
kubectl get services -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 コンテキストを使用しているためです。通常のコンテキストを使用して管理クラスタに接続しようとするユーザーは、リソースにアクセスできません。これは、まだアクセスする権限がないためです。
「管理クラスタ用の RBAC の構成」に進みます。

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

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

Okta アカウントにログインします。
メインメニューで、[アプリケーション (Applications)] に移動します。
Tanzu Kubernetes Grid 用に作成したアプリケーションを選択します。
[全般設定 (General Settings)] パネルで、[編集 (Edit)] をクリックします。
[ログイン (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 を指定する必要があります。
保存をクリックします。

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

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

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

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

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

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

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

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

kubectl のコンテキストを管理クラスタに設定します。たとえば、id-mgmt-test という名前の管理クラスタの場合は次のようになります。
```
kubectl config use-context id-mgmt-test-admin@id-mgmt-test
```
管理クラスタを展開したときに定義した構成設定を新しいファイルにコピーして、クラスタ構成ファイルを作成します。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,offline_access"
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_NAME_ATTRIBUTE: dn
LDAP_GROUP_SEARCH_USER_ATTRIBUTE: dn
LDAP_HOST:
LDAP_ROOT_CA_DATA_B64:
LDAP_USER_SEARCH_BASE_DN:
LDAP_USER_SEARCH_FILTER:
LDAP_USER_SEARCH_ID_ATTRIBUTE: dn
LDAP_USER_SEARCH_NAME_ATTRIBUTE:

# 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 アドレスに変更します。
ローカル環境で、IDENTITY_MANAGEMENT_TYPE が oidc または ldap のいずれかに設定されており、none に設定されていないことを確認します。
```
echo $IDENTITY_MANAGEMENT_TYPE
```
この変数が none に設定されている場合は、export コマンドを実行して、oidc または ldap に設定し直します。
FILTER_BY_ADDON_TYPE 環境変数を authentication/pinniped に設定して、tanzu management-cluster create が Pinniped 関連のオブジェクトでのみ動作するようにします。
```
export FILTER_BY_ADDON_TYPE="authentication/pinniped"
```
Pinniped アドオンのシークレットを生成します。
```
tanzu management-cluster create CLUSTER-NAME --dry-run -f CLUSTER-CONFIG-FILE > CLUSTER-NAME-example-secret.yaml
```
ここで、
- CLUSTER-NAME はターゲット管理クラスタの名前です。
- CLUSTER-CONFIG-FILE は、上記で作成した構成ファイルです。
環境変数の設定により、tanzu management-cluster create --dry-run が完全なクラスタマニフェストではなく Kubernetes シークレットを生成します。
シークレットを確認してから、管理クラスタに適用します。例：
```
kubectl apply -f CLUSTER-NAME-example-secret.yaml
```
シークレットを適用したら、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.3 では、非インタラクティブなアカウントまたはパスワード付与に基づくブラウザレス CLI ログインはサポートされていません。

ローカルマシンのターミナルウィンドウから ssh を実行して、ブートストラップマシンにリモートでログインします。
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
```
クラスタの標準の 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
```

新しく作成した 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:

リンクをコピーし、ローカルマシンのブラウザに貼り付けます。
ブラウザで、ID プロバイダにログインします。認証コードを CLI に貼り付けるよう求めるページが表示されます。
認証コードをコピーして、CLI の「Optionally, paste your authorization code:」プロンプトの後に貼り付けます。
以前に使用したのと同じ 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 を構成する必要があります。
  - 「管理クラスタでのロールバインドの作成」を参照してください。
  - 「ワークロードクラスタでのロールバインドの作成」を参照してください。

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

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

kubectl のコンテキストを管理クラスタに設定します。たとえば、id-mgmt-test という名前の管理クラスタの場合は次のようになります。
```
kubectl config use-context id-mgmt-test-admin@id-mgmt-test
```
管理クラスタ構成ファイルを取得し、IDENTITY_MANAGEMENT_TYPE: none を設定するように編集します。
--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）。
新しいシークレットを適用して、管理クラスタで Pinniped を無効にします。
```
kubectl apply -f PINNIPED-SECRET
```
管理クラスタで 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 の構成」の手順に従ってください。

ID 管理の構成

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

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

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

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

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

ID 管理の構成の完了

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

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

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

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

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

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

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

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

ID 管理の構成の完了

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

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

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

次の手順

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

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

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