ID 관리 구성

이 항목에서는 독립형 관리 클러스터를 사용하여 TKG(Tanzu Kubernetes Grid)에서 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 계정을 생성합니다.
관리자 버튼을 클릭하여 관리 포털로 이동합니다.
애플리케이션으로 이동하고 애플리케이션 추가를 클릭합니다.
새 애플리케이션 생성을 클릭합니다.
플랫폼인 경우 웹을 선택하고, 메서드에 서명인 경우 OpenID Connect를 선택한 다음 생성을 클릭합니다.
애플리케이션에 이름을 지정합니다.
자리 표시자 로그인 리디렉션 URI을 입력합니다. 예를 들어 http://localhost:8080/callback를 입력합니다. 관리 클러스터를 배포한 후 실제 URL로 업데이트합니다.
저장을 클릭합니다.
애플리케이션의 일반 탭에서 클라이언트 ID와 클라이언트 암호를 복사하여 저장합니다. 관리 클러스터를 배포할 때 이러한 자격 증명이 필요합니다.
할당 탭에서 사용자와 그룹을 애플리케이션에 할당합니다. 애플리케이션에 할당하는 사용자와 그룹은 관리 클러스터 및 배포에 사용하는 워크로드 클러스터에 액세스할 수 있는 사용자가 됩니다.

Tanzu Kubernetes Grid LDAPS 또는 OIDC 설정 구성

위에서 가져온 세부 정보를 사용하여 Tanzu Kubernetes Grid LDAPS 또는 OIDC를 구성합니다.

설치 관리자 인터페이스를 사용하여 관리 클러스터를 배포하는 경우 ID 관리 섹션에서 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 TLS 인증서가 만료될 때마다 Dex 포드를 수동으로 순환해야 합니다(기본적으로 90일). CERT_DURATION을 사용하여 인증서 기간을 늘릴 수 있습니다. Dex 포드를 다시 시작하려면 kubectl rollout restart deployments/dex -n tanzu-system-auth를 실행합니다.

ID 관리 구성 완료

관리 클러스터가 배포된 후 아래 섹션에 설명된 다음 절차에 따라 ID 관리 구성을 완료합니다.

kubectl을 관리 클러스터에 연결합니다.
상태를 확인하여 인증 서비스가 올바르게 실행되고 있는지 확인합니다.
- OIDC: OIDC ID 관리 서비스의 상태를 확인합니다.
- LDAP: LDAP ID 관리 서비스의 상태를 확인합니다.
OIDC: 콜백 URI를 OIDC 제공자에 제공합니다.
관리 클러스터에 액세스하기 위해 표준 비-관리자 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
```

OIDC ID 관리 서비스의 상태 확인

Tanzu Kubernetes Grid Pinniped를 사용하여 클러스터를 OIDC ID 서비스와 통합합니다. OIDC를 사용하도록 설정하면 Tanzu Kubernetes Grid는 pinniped-concierge 네임스페이스에 pinniped-supervisor 서비스를, pinniped-concierge 네임스페이스에 pinniped-supervisor를 생성합니다. 아래 단계에 따라 Pinniped 서비스의 상태를 확인하고 서비스가 노출되는 EXTERNAL-IP 주소를 기록해 둡습니다.

관리 클러스터에서 실행 중인 서비스에 대한 정보를 가져옵니다. ID 관리 서비스는 pinniped-supervisor 네임스페이스에서 실행됩니다.

kubectl get services -n pinniped-supervisor

출력에 다음 항목이 표시됩니다.

vSphere with NSX Advanced Load Balancer(ALB):

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

AWS(Amazon Web Services):

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

vSphere without NSX ALB:

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

다음 정보를 기록합니다.
- vSphere with NSX ALB, AWS, Azure: EXTERNAL-IP 아래에 있는 pinniped-supervisor 서비스의 외부 주소를 확인합니다.
- vSphere without NSX ALB: 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
```

참고
관리 클러스터에 admin 컨텍스트를 사용 중이므로 kubectl get pods를 실행할 수 있습니다. 일반 컨텍스트를 사용하여 관리 클러스터에 연결하려고 하는 사용자는 아직 권한이 없기 때문에 해당 리소스에 액세스할 수 없습니다.

LDAP ID 관리 서비스의 상태 확인

Tanzu Kubernetes Grid Pinniped를 사용하여 Dex와 함께 클러스터를 LDAP ID 서비스와 통합하여 서비스 끝점을 노출합니다. LDAP를 사용하도록 설정하면 Tanzu Kubernetes Grid는 pinniped-supervisor 네임스페이스에 pinniped-supervisor 서비스를, pinniped-concierge 네임스페이스에 pinniped-concierge를, tanzu-system-auth 네임스페이스에 dexsvc를 생성합니다. 아래 단계에 따라 LDAP 서비스의 상태를 확인하고 서비스가 노출되는 EXTERNAL-IP 주소를 기록해 둡습니다.

tanzu-system-auth 네임스페이스의 관리 클러스터에서 실행 중인 서비스에 대한 정보를 가져옵니다.

kubectl get services -n tanzu-system-auth

출력에 다음 항목이 표시됩니다.

vSphere with NSX ALB:

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

vSphere without NSX ALB:

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

관리 클러스터의 모든 서비스가 실행되고 있는지 확인합니다.
```
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
```
참고
관리 클러스터에 admin 컨텍스트를 사용 중이므로 kubectl get pods를 실행할 수 있습니다. 일반 컨텍스트를 사용하여 관리 클러스터에 연결하려고 하는 사용자는 아직 권한이 없기 때문에 해당 리소스에 액세스할 수 없습니다.
관리 클러스터용 RBAC 구성으로 진행합니다.

(OIDC만 해당) OIDC 제공자에 콜백 URI 제공

OIDC 인증을 사용하도록 관리 클러스터를 구성한 경우 해당 관리 클러스터에 대한 콜백 URI를 OIDC ID 제공자에 제공해야 합니다. 예를 들어 OIDC를 사용 중이고 IDP가 Okta인 경우 다음 단계를 수행합니다.

Okta 계정에 로그인합니다.
기본 메뉴에서 애플리케이션으로 이동합니다.
Tanzu Kubernetes Grid에 대해 생성한 애플리케이션을 선택합니다.
[일반 설정] 패널에서 편집을 클릭합니다.
로그인에서 pinniped-supervisor가 실행 중인 노드의 주소를 포함하도록 로그인 리디렉션 URI를 업데이트합니다.
- vSphere with NSX ALB, AWS, Azure: 이전 절차에서 적어 둔 pinniped-supervisor 서비스의 외부 IP 주소와 포트 번호를 추가합니다.
```
https://EXTERNAL-IP/callback
```
- vSphere without NSX ALB: 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"
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 주소로 변경합니다.

로컬 환경에 IDENTITY_MANAGEMENT_TYPE이 oidc 또는 ldap로 설정되어 있고 none이 아닌지 확인합니다.
```
echo $IDENTITY_MANAGEMENT_TYPE
```
이 변수가 none으로 설정된 경우 export 명령을 실행하여 oidc 또는 ldap로 다시 설정합니다.
_TKG_CLUSTER_FORCE_ROLE 환경 변수를 management로 설정합니다.
```
export _TKG_CLUSTER_FORCE_ROLE="management"
```
Windows에서 SET 명령을 사용합니다.
tanzu cluster create가 Pinniped 관련 개체에서만 작동하도록 FILTER_BY_ADDON_TYPE 환경 변수를 authentication/pinniped로 설정하십시오.
```
export FILTER_BY_ADDON_TYPE="authentication/pinniped"
```
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 암호를 생성합니다.
암호를 확인한 다음 관리 클러스터에 적용합니다. 예:
```
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 관리 서비스를 사용하도록 자동으로 구성됩니다.

브라우저 없이 시스템에서 사용자 인증

부트스트랩 시스템이 jumpbox 또는 디스플레이가 없는 다른 시스템인 경우 로컬 시스템에서 실행되는 브라우저에서 클러스터에 인증할 수 있습니다. 이 작업을 수행하는 방법은 클러스터가 기반으로 하는 Tanzu Kubernetes 릴리스에서 제공되는 클러스터의 Pinniped 버전에 따라 다릅니다.

클러스터 TKr 버전	브라우저 없는 인증 절차
TKr v1.23.10(Tanzu Kubernetes Grid v1.6.1의 기본값) 이상	아래 지침을 따르십시오.
이전 TKr을 기반으로 하거나 이전 버전의 Tanzu Kubernetes Grid에서 생성한 클러스터	Tanzu Kubernetes Grid v1.4 설명서의 브라우저가 없는 시스템에서 사용자 인증의 절차를 따르십시오.

참고
Tanzu Kubernetes Grid v2.2는 비대화형 계정 또는 암호 부여를 기준으로 하는 브라우저 없는 CLI 로그인을 지원하지 않습니다.

로컬 시스템의 터미널 창에서 ssh를 실행하여 부트스트랩 시스템에 원격으로 로그인합니다.
TANZU_CLI_PINNIPED_AUTH_LOGIN_SKIP_BROWSER=true 환경 변수를 설정합니다. 그러면 클러스터의 kubeconfig에 --skip-browser 옵션이 추가됩니다.
```
# 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에 붙여 넣으라는 페이지가 나타납니다.
인증 코드를 복사한 후 Optionally, paste your authorization code: 프롬프트 뒤의 CLI에 붙여 넣습니다.
이전에 사용한 것과 동일한 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.로 시작하는 설정을 업데이트하려면 다음 단계를 수행해야 합니다.

dex. 설정 또는 업데이트할 설정을 식별합니다. 자동 관리되는 패키지 values.yaml 설정의 표를 참조하십시오.
자동 관리되는 패키지 values.yaml 설정에 설명된 대로 관리 클러스터용 Pinniped 암호를 검색합니다.
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, id, secret 키를 가진 모든 맵일 수 있습니다(예: {name: "example-name", id: "example-id", secret: "example-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
```
Pinniped 암호를 적용합니다.
Pinniped 암호를 적용한 후 관리 클러스터에서 tanzu-system-auth 네임스페이스를 다시 시작합니다. 네임스페이스를 다시 시작하려면 Namespace를 삭제하고 pinniped App이 다시 생성될 때까지 기다립니다. Pinniped 암호를 적용한 후 pinniped-supervisor Namespace에서 pinniped-post-deploy-job Job을 다시 시작해야 할 수 있습니다. 이렇게 하려면 Job을 삭제하고 pinniped App이 다시 생성될 때까지 기다립니다.

기존 배포에서 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 Secret 정의를 생성합니다.
```
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 연결

OIDC ID 관리 서비스의 상태 확인

LDAP ID 관리 서비스의 상태 확인

(OIDC만 해당) OIDC 제공자에 콜백 URI 제공

관리 클러스터용 RBAC 구성

기존 배포에서 ID 관리 사용 및 구성

ID 제공자 세부 정보 가져오기

관리 클러스터용 Pinniped 추가 기능 암호 생성

ID 관리 구성 완료

워크로드 클러스터에서 ID 관리 사용

브라우저 없이 시스템에서 사용자 인증

관리 클러스터 배포 후 Dex 설정 업데이트

기존 배포에서 ID 관리 비활성화

후속 작업

관리 클러스터에 `kubectl` 연결