ID 관리 구성

이 항목에서는 독립형 관리 클러스터를 사용하여 TKG(Tanzu Kubernetes Grid)에서 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 계정을 생성합니다.
  2. 관리자 버튼을 클릭하여 관리 포털로 이동합니다.
  3. 애플리케이션으로 이동하고 애플리케이션 통합 생성(Create App Integration)을 클릭합니다.
  4. 로그인 방법(Sign-in method)에서 OIDC - OpenID 연결(OIDC - OpenID Connect)을 선택하고 애플리케이션 유형(Application type)에서 웹 애플리케이션(Web Application)을 선택한 다음 다음(Next)을 클릭합니다.
  5. 애플리케이션에 이름을 지정합니다.
  6. 유형 부여(Grant Type)사용자 대신 클라이언트 행동(Client acting on behalf of a user)에서 인증 코드(Authorization Code)토큰 새로 고침(Refresh Token)이 모두 선택되어 있는지 확인합니다.
  7. 자리 표시자 로그인 리디렉션 URI를 입력합니다. 예를 들어 http://localhost:8080/authorization-code/callback를 입력합니다. 관리 클러스터를 배포한 후 실제 URL로 업데이트합니다.
  8. 할당(Assignments0에서 사용자와 그룹을 애플리케이션에 할당합니다. 애플리케이션에 할당하는 사용자와 그룹은 관리 클러스터 및 배포에 사용하는 워크로드 클러스터에 액세스할 수 있는 사용자가 됩니다.
  9. 저장을 클릭합니다.
  10. 애플리케이션의 일반 탭에서 클라이언트 ID클라이언트 암호를 복사하여 저장합니다. 관리 클러스터를 배포할 때 이러한 자격 증명이 필요합니다.
중요

TKG 2.3 이상을 사용하려면 모든 OIDC 제공자가 새로 고침 토큰을 실행하도록 구성되어야 합니다.

Tanzu Kubernetes Grid LDAPS 또는 OIDC 설정 구성

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

  • 설치 관리자 인터페이스를 사용하여 관리 클러스터를 배포하는 경우 ID 관리 섹션에서 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 관리 구성을 완료합니다.

  1. kubectl을 관리 클러스터에 연결합니다.
  2. 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
    

ID 관리 서비스의 상태 확인

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

  1. 관리 클러스터에서 실행 중인 서비스에 대한 정보를 가져옵니다. 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
    
  2. 다음 정보를 기록합니다.

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

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

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

Tanzu Kubernetes Grid Pinniped를 사용하여 클러스터를 LDAP ID 서비스와 통합하여 서비스 끝점을 노출합니다. LDAP를 사용하도록 설정하면, Tanzu Kubernetes Grid는 pinniped-supervisor 네임스페이스의 pinniped-supervisor 서비스 및 pinniped-concierge 네임스페에스의 pinniped-concierge 서비스를 생성합니다.

  1. 관리 클러스터의 모든 서비스가 실행되고 있는지 확인합니다.

    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
    
    참고

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

  2. 관리 클러스터용 RBAC 구성으로 진행합니다.

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

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

  1. Okta 계정에 로그인합니다.
  2. 기본 메뉴에서 애플리케이션으로 이동합니다.
  3. Tanzu Kubernetes Grid에 대해 생성한 애플리케이션을 선택합니다.
  4. [일반 설정] 패널에서 편집을 클릭합니다.
  5. 로그인에서 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를 지정해야 합니다.

  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,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 제공자 구성을 위한 변수 - OIDCID 제공자 구성을 위한 변수 - LDAP로 이동합니다.

    관리 클러스터가 프록시 뒤에 있는 경우 새 구성 파일에 프록시 구성 세부 정보가 포함되어 있는지 확인합니다.

    TKG_HTTP_PROXY:
    TKG_HTTPS_PROXY:
    TKG_NO_PROXY:
    

    이러한 변수에 대한 자세한 내용은 프록시 구성을 참조하십시오.

    vSphere: 내부 검사를 통과하기 위한 더미 값으로 VSPHERE_CONTROL_PLANE_ENDPOINT 구성 설정을 사용하지 않는 IP 주소로 변경합니다.

  3. 로컬 환경에 IDENTITY_MANAGEMENT_TYPEoidc 또는 ldap로 설정되어 있고 none이 아닌지 확인합니다.

    echo $IDENTITY_MANAGEMENT_TYPE
    

    이 변수가 none으로 설정된 경우 export 명령을 실행하여 oidc 또는 ldap로 다시 설정합니다.

  4. tanzu management-cluster create가 Pinniped 관련 개체에서만 작동하도록 FILTER_BY_ADDON_TYPE 환경 변수를 authentication/pinniped로 설정하십시오.

    export FILTER_BY_ADDON_TYPE="authentication/pinniped"
    
  5. 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 암호를 생성합니다.

  6. 암호를 확인한 다음 관리 클러스터에 적용합니다. 예:

    kubectl apply -f CLUSTER-NAME-example-secret.yaml
    
  7. 암호를 적용한 후 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.3은 비대화형 계정 또는 암호 부여를 기준으로 하는 브라우저 없는 CLI 로그인을 지원하지 않습니다.

  1. 로컬 시스템의 터미널 창에서 ssh를 실행하여 부트스트랩 시스템에 원격으로 로그인합니다.

  2. 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
    
  3. 클러스터의 표준 kubeconfig를 로컬 파일로 내보냅니다. 명령에는 --admin 옵션이 포함되지 않으므로 내보낸 kubeconfigadmin 버전이 아닌 표준 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. 인증 코드를 복사한 후 Optionally, paste your authorization code: 프롬프트 뒤의 CLI에 붙여 넣습니다.

  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를 구성해야 합니다.

기존 배포에서 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 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)입니다.

  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-NAMESecret 규격에 설정된 metadata.name 값입니다.

후속 작업

표준 비-관리자 kubeconfig 파일을 사용하여 사용자에게 관리 및 워크로드 클러스터에 대한 액세스 권한을 부여하려면 RBAC 권한 부여를 구성해야 합니다.

check-circle-line exclamation-circle-line close-line
Scroll to top icon