Tanzu Kubernetes v1.3은 Pinniped과 Dex를 통한 OIDC 및 LDAP ID 관리를 도입한다. Pinniped를 사용하면 외부 OpenID Connect(OIDC) 또는 LDAP 아이덴티티 프로바이더(IDP)를 Tanzu Kubernetes 클러스터에 연결하여 해당 클러스터에 대한 액세스를 제어할 수 있습니다. Pinniped는 Dex를 엔드포인트로 사용하여 업스트림 LDAP ID 공급자(예: Microsoft Active Directory)에 연결합니다. OpenID Connect(OIDC)를 사용하는 경우, 덱스는 필요하지 않습니다. 결국 Pinniped와 함께 LDAP에도 직접 통합되므로 Dex의 필요성이 없어지는 것으로 알고 있습니다. 그러나 현재로서는 두 가지 구성 요소가 모두 필요합니다. 이미 연구소에서 마이크로소프트 Active Directory를 사용하고 있기 때문에 통합을 시작하고 Active Directory를 통해 Tanzu Kubernetes 클러스터에 대한 사용자 액세스를 제어하기로 결정했습니다.

이는 TKG의 독립형 또는 멀티 클라우드 향으로 vSphere에 Tanzu Kubernetes Clusters와 달리 TKG에 대해 다시 한 번 언급합니다. TKG의 Identity Management에 대한 자세한 내용은 여기의 공식 문서에서 확인할 수 있습니다.

요구 사항

시작하기 전에 몇 가지 사항을 고려합니다.

  • Linux 데스크톱에서 TKG를 배포하는 경우 브라우저를 열 수 있는 그래픽 사용자 인터페이스가 필요합니다. 그 이유는 AD 사용자가 처음 워크로드 클러스터와 상호 작용하려고 할 때 Dex 끝점에서 AD/LDAP 자격 증명을 제공할 수 있도록 브라우저 탭이 열리기 때문입니다.
  • ID 공급자에서 CA의 Base64 루트 인증서를 검색할 수 있어야 합니다. Microsoft Active Directory 인증서 서비스에 대해 이 작업을 수행하는 방법을 보여 주겠지만 이 단계는 다른 공급자에 따라 다릅니다.
  • OU, CN, DC 등과 같은 LDAP 디렉토리 속성을 잘 이해해야 합니다. 공식 TKG 설명서는 LDAP 구성 옵션과 관련된 세부 사항은 다루지 않으므로, 동료들이 제공하는 이 두 가지 우수한 리소스를 참조할 것을 강력히 권장합니다. Chris Little은 NSX ALB의 블로그에 몇 가지 매우 유용한 지침을 제공하고 있으며, Brian Ragazzi의 LDAP 설정에 대한 블로그도 매우 유용했습니다. 또 다른 유용한 자료로는 Tom Schwaller의 TKG 1.3 블로그가 있다.
  • LDAP 서비스가 글로벌 카탈로그 서버인지도 확인해야 합니다. 보안 LDAP는 TCP 포트 636을 통해 통신합니다. 글로벌 카탈로그 서버도 있는 경우 TCP 포트 3269를 통해 통신이 수행됩니다.

Active Directory 인증서 서비스에서 루트 CA 검색

앞서 말씀드린 바와 같이, 저는 마이크로소프트 액티브 디렉토리 인증서 서비스를 사용하고 있습니다. CA 인증서를 검색하려면 브라우저로 인증서 서비스를 가리키고 로그인하기만 하면 됩니다.

그런 다음 “Download a CA certificate” 옵션을 클릭합니다. 그러면 다음 창이 열립니다. Base 64 인코딩 방법을 선택한 다음 “Download a CA certificate” 링크를 클릭합니다. 인증서를 안전하게 저장하면 TKG 관리 클러스터 배포로 진행할 수 있습니다.

TKG 관리 클러스터 배포

관리 클러스터를 배포하는 방법에 대한 예는 이 블로그와 다른 블로그에서 모두 볼 수 있습니다. 나는 그 과정을 자세히 설명하지 않을 것이다. 대신 Identity Management(아이덴티티 관리) 섹션에 초점을 맞추겠습니다. -u(–ui) 옵션을 사용하여 구성 파일을 생성할 때 관리 클러스터 배포에서 완료된 구성입니다. 스크린샷에서 비워둔 ROOT CA가 있는지 확인합니다. 이것은 이전 단계에서 AD 인증서 서비스에서 다운로드한 ROOT CA입니다. 앞서 언급한 대로 BIND, FILTER 및 기타 특성을 사용자의 필요에 따라 수정해야 할 수 있습니다.

UI 구성이 완료되면 전체 관리 클러스터 구성 매니페스트가 다음과 유사하게 표시됩니다. 구성은 ~/.tanzu/tkg/clusterconfigs 구성으로 저장됩니다. Base 64 ROOT CA를 포함하여 채워진 LDAP 필드를 다시 볼 수 있습니다.

AVI_CA_DATA_B64: ""
AVI_CLOUD_NAME: ""
AVI_CONTROLLER: ""
AVI_DATA_NETWORK: ""
AVI_DATA_NETWORK_CIDR: ""
AVI_ENABLE: "false"
AVI_LABELS: ""
AVI_PASSWORD: ""
AVI_SERVICE_ENGINE_GROUP: ""
AVI_USERNAME: ""
CLUSTER_CIDR: 100.96.13.0/11
CLUSTER_NAME: tkg-ldaps-mgmt
CLUSTER_PLAN: dev
ENABLE_CEIP_PARTICIPATION: "false"
ENABLE_MHC: "true"
IDENTITY_MANAGEMENT_TYPE: ldap
INFRASTRUCTURE_PROVIDER: vsphere
LDAP_BIND_DN: cn=Administrator,cn=Users,dc=rainpole,dc=com
LDAP_BIND_PASSWORD: <encoded:VnhSYWlsITIz>
LDAP_GROUP_SEARCH_BASE_DN: dc=rainpole,dc=com
LDAP_GROUP_SEARCH_FILTER: (objectClass=group)
LDAP_GROUP_SEARCH_GROUP_ATTRIBUTE: member
LDAP_GROUP_SEARCH_NAME_ATTRIBUTE: cn
LDAP_GROUP_SEARCH_USER_ATTRIBUTE: DN
LDAP_HOST: dc01.rainpole.com:636
LDAP_ROOT_CA_DATA_B64: LS0tLS1CRUdJ...
LDAP_USER_SEARCH_BASE_DN: cn=Users,dc=rainpole,dc=com
LDAP_USER_SEARCH_FILTER: (objectClass=person)
LDAP_USER_SEARCH_NAME_ATTRIBUTE: userPrincipalName
LDAP_USER_SEARCH_USERNAME: userPrincipalName
OIDC_IDENTITY_PROVIDER_CLIENT_ID: ""
OIDC_IDENTITY_PROVIDER_CLIENT_SECRET: ""
OIDC_IDENTITY_PROVIDER_GROUPS_CLAIM: ""
OIDC_IDENTITY_PROVIDER_ISSUER_URL: ""
OIDC_IDENTITY_PROVIDER_NAME: ""
OIDC_IDENTITY_PROVIDER_SCOPES: ""
OIDC_IDENTITY_PROVIDER_USERNAME_CLAIM: ""
SERVICE_CIDR: 100.64.13.0/13
TKG_HTTP_PROXY_ENABLED: "false"
VSPHERE_CONTROL_PLANE_DISK_GIB: "20"
VSPHERE_CONTROL_PLANE_ENDPOINT: 10.27.51.237
VSPHERE_CONTROL_PLANE_MEM_MIB: "4096"
VSPHERE_CONTROL_PLANE_NUM_CPUS: "2"
VSPHERE_DATACENTER: /OCTO-Datacenter
VSPHERE_DATASTORE: /OCTO-Datacenter/datastore/vsan-OCTO-Cluster-B
VSPHERE_FOLDER: /OCTO-Datacenter/vm/TKG
VSPHERE_NETWORK: VM-51-DVS-B
VSPHERE_PASSWORD: <encoded:Vk13YXJlMTIzIQ==>
VSPHERE_RESOURCE_POOL: /OCTO-Datacenter/host/OCTO-Cluster-B/Resources
VSPHERE_SERVER: vcsa-06.rainpole.com
VSPHERE_SSH_AUTHORIZED_KEY: ssh-rsa AAAA... chogan@chogan-a01.vmware.com
VSPHERE_TLS_THUMBPRINT: FA:A5:8A:...
VSPHERE_USERNAME: administrator@vsphere.local
VSPHERE_WORKER_DISK_GIB: "20"
VSPHERE_WORKER_MEM_MIB: "4096"
VSPHERE_WORKER_NUM_CPUS: "2"

관리 클러스터의 구조는 다음과 같습니다.

$ tanzu management-cluster create --file ./mgmt_cluster.yaml

Validating the pre-requisites...

vSphere 7.0 Environment Detected.

You have connected to a vSphere 7.0 environment which does not have vSphere with Tanzu enabled. vSphere with Tanzu includes
an integrated Tanzu Kubernetes Grid Service which turns a vSphere cluster into a platform for running Kubernetes workloads in dedicated
resource pools. Configuring Tanzu Kubernetes Grid Service is done through vSphere HTML5 client.

Tanzu Kubernetes Grid Service is the preferred way to consume Tanzu Kubernetes Grid in vSphere 7.0 environments. Alternatively you may
deploy a non-integrated Tanzu Kubernetes Grid instance on vSphere 7.0.
Note: To skip the prompts and directly deploy a non-integrated Tanzu Kubernetes Grid instance on vSphere 7.0, you can set the 'DEPLOY_TKG_ON_VSPHERE7' configuration variable to 'true'

Do you want to configure vSphere with Tanzu? [y/N]: N
Would you like to deploy a non-integrated Tanzu Kubernetes Grid management cluster on vSphere 7.0? [y/N]: y
Deploying TKG management cluster on vSphere 7.0 ...

Setting up management cluster...
Validating configuration...
Using infrastructure provider vsphere:v0.7.7
Generating cluster configuration...
Setting up bootstrapper...
Bootstrapper created. Kubeconfig: /home/cormac/.kube-tkg/tmp/config_SR91Ri9a
Installing providers on bootstrapper...
Fetching providers
Installing cert-manager Version="v0.16.1"
Waiting for cert-manager to be available...
Installing Provider="cluster-api" Version="v0.3.14" TargetNamespace="capi-system"
Installing Provider="bootstrap-kubeadm" Version="v0.3.14" TargetNamespace="capi-kubeadm-bootstrap-system"
Installing Provider="control-plane-kubeadm" Version="v0.3.14" TargetNamespace="capi-kubeadm-control-plane-system"
Installing Provider="infrastructure-vsphere" Version="v0.7.7" TargetNamespace="capv-system"
Start creating management cluster...
Saving management cluster kubeconfig into /home/cormac/.kube/config
Installing providers on management cluster...
Fetching providers
Installing cert-manager Version="v0.16.1"
Waiting for cert-manager to be available...
Installing Provider="cluster-api" Version="v0.3.14" TargetNamespace="capi-system"
Installing Provider="bootstrap-kubeadm" Version="v0.3.14" TargetNamespace="capi-kubeadm-bootstrap-system"
Installing Provider="control-plane-kubeadm" Version="v0.3.14" TargetNamespace="capi-kubeadm-control-plane-system"
Installing Provider="infrastructure-vsphere" Version="v0.7.7" TargetNamespace="capv-system"
Waiting for the management cluster to get ready for move...
Waiting for addons installation...
Moving all Cluster API objects from bootstrap cluster to management cluster...
Performing move...
Discovering Cluster API objects
Moving Cluster API objects Clusters=1
Creating objects in the target cluster
Deleting objects from the source cluster
Waiting for additional components to be up and running...
Context set for management cluster tkg-ldaps-mgmt as 'tkg-ldaps-mgmt-admin@tkg-ldaps-mgmt'.

Management cluster created!


You can now create your first workload cluster by running the following:

 tanzu cluster create [name] -f [file]


Some addons might be getting installed! Check their status by running the following:

 kubectl get apps -A

이때 Pinniped 추가 기능이 성공적으로 조정되었는지 확인해야 합니다. Pinniped 사후 배포 작업은 Pinniped 컨시어지 배포가 준비된 후에만 성공하므로 1분 정도 기다릴 필요가 있습니다. 먼저 올바른 TKG 관리 클러스터에 로그인합니다.

$ tanzu cluster list --include-management-cluster
 NAME           NAMESPACE   STATUS  CONTROLPLANE  WORKERS  KUBERNETES       ROLES       PLAN
 tkg-ldaps-mgmt tkg-system  running 1/1           1/1      v1.20.5+vmware.1 management  dev


$ tanzu login
? Select a server tkg-ldaps-mgmt ()
✔ successfully logged in to management cluster using the kubeconfig tkg-ldaps-mgmt

다른 Kubernetes 컨텍스트가 있는 경우 추가 기능 앱을 쿼리하기 전에 새로 생성된 관리 클러스터 컨텍스트로 전환해야 할 수 있습니다. 그러면 모든 조정이 성공했는지 확인하십시오.

$ kubectl config get-contexts
CURRENT NAME                                 CLUSTER         AUTHINFO             NAMESPACE
        kubernetes-admin@kubernetes          kubernetes      kubernetes-admin
        tkg-ldaps-mgmt-admin@tkg-ldaps-mgmt  tkg-ldaps-mgmt  tkg-ldaps-mgmt-admin


$ kubectl config use-context tkg-ldaps-mgmt-admin@tkg-ldaps-mgmt
Switched to context "tkg-ldaps-mgmt-admin@tkg-ldaps-mgmt".


$ kubectl get nodes
NAME                                  STATUS   ROLES                 AGE  VERSION
tkg-ldaps-mgmt-control-plane-hr6nb    Ready    control-plane,master  11m  v1.20.5+vmware.1
tkg-ldaps-mgmt-md-0-54c99747c7-xhs6q  Ready    <none>                10m  v1.20.5+vmware.1


$ kubectl get apps -A

NAMESPACE   NAME                   DESCRIPTION           SINCE-DEPLOY AGE
tkg-system  antrea                 Reconcile succeeded    53s         7m6s
tkg-system  metrics-server         Reconcile succeeded    24s         7m6s
tkg-system  pinniped               Reconcile succeeded    28s         7m7s
tkg-system  tanzu-addons-manager   Reconcile succeeded   119s         11m
tkg-system  vsphere-cpi            Reconcile succeeded   109s         7m7s
tkg-system  vsphere-csi            Reconcile succeeded  5m33s         7m6s

pinniped-post-deploy-job의 경우 관리 클러스터에서 몇 가지 Pod 장애가 발생하는 것이 일반적입니다. Pinniped 컨시어지 배포가 온라인 상태가 되면 이 배포 후 작업의 인스턴스가 완료됩니다. Pinniped 또는 Dex 배포에 실패한 경우 LDAP 구성 문제가 강조 표시될 수 있으므로 Pod 로그를 확인하십시오.

TKG 워크로드 클러스터 배포

이제 첫 번째 워크로드 클러스터를 생성할 준비가 되었습니다. 다음은 이 배포에 사용하는 구성 파일입니다.

#! -- See https://docs.vmware.com/en/VMware-Tanzu-Kubernetes-Grid/1.3/vmware-tanzu-kubernetes-grid-13/GUID-tanzu-k8s-clusters-vsphere.html
##
##! ---------------------------------------------------------------------
##! Basic cluster creation configuration
##! ---------------------------------------------------------------------
##
CLUSTER_NAME: tkg-ldaps-wkld
CLUSTER_PLAN: prod
CNI: antrea
#
##! ---------------------------------------------------------------------
##! Node configuration
##! ---------------------------------------------------------------------
#
CONTROL_PLANE_MACHINE_COUNT: 1
WORKER_MACHINE_COUNT: 2
VSPHERE_CONTROL_PLANE_NUM_CPUS: 2
VSPHERE_CONTROL_PLANE_DISK_GIB: 40
VSPHERE_CONTROL_PLANE_MEM_MIB: 8192
VSPHERE_WORKER_NUM_CPUS: 2
VSPHERE_WORKER_DISK_GIB: 40
VSPHERE_WORKER_MEM_MIB: 4096
#
##! ---------------------------------------------------------------------
##! vSphere configuration
##! ---------------------------------------------------------------------
#
VSPHERE_DATACENTER: /OCTO-Datacenter
VSPHERE_DATASTORE: /OCTO-Datacenter/datastore/vsan-OCTO-Cluster-B
VSPHERE_FOLDER: /OCTO-Datacenter/vm/TKG
VSPHERE_NETWORK: VM-51-DVS-B
VSPHERE_PASSWORD: <encoded:Vk13YXJlMTIzIQ==>
VSPHERE_RESOURCE_POOL: /OCTO-Datacenter/host/OCTO-Cluster-B/Resources
VSPHERE_SERVER: vcsa-06.rainpole.com
VSPHERE_SSH_AUTHORIZED_KEY: ssh-rsa AAAA... chogan@chogan-a01.vmware.com
VSPHERE_TLS_THUMBPRINT: FA:A5:8A:...
VSPHERE_USERNAME: administrator@vsphere.local
VSPHERE_CONTROL_PLANE_ENDPOINT: 10.27.51.238
#
#! ---------------------------------------------------------------------
#! Common configuration
#! ---------------------------------------------------------------------

ENABLE_DEFAULT_STORAGE_CLASS: true

CLUSTER_CIDR: 100.96.13.0/11
SERVICE_CIDR: 100.64.13.0/13

다시 말씀드리지만, 이 파일의 내용에 대한 많은 정보가 있습니다. 그래서 저는 설명하는데 시간을 낭비하지 않을 것입니다. 파일 내용을 읽으면 이 구성이 생성할 TKG 워크로드 클러스터에 대한 좋은 아이디어를 얻을 수 있을 것입니다. 워크로드 클러스터를 배포한 다음 KUBECONFIG 파일을 검색하여 상호 작용하도록 하겠습니다.

$ tanzu cluster create --file ./workload_cluster.yaml
Validating configuration...
Creating workload cluster 'tkg-ldaps-wkld'...
Waiting for cluster to be initialized...
Waiting for cluster nodes to be available...
Waiting for addons installation...

Workload cluster 'tkg-ldaps-wkld' created


$ tanzu cluster list --include-management-cluster
 NAME            NAMESPACE   STATUS   CONTROLPLANE  WORKERS  KUBERNETES        ROLES       PLAN
 tkg-ldaps-wkld  default     running  1/1           2/2      v1.20.5+vmware.1  <none>      prod
 tkg-ldaps-mgmt  tkg-system  running  1/1           1/1      v1.20.5+vmware.1  management  dev


$ tanzu cluster kubeconfig get tkg-ldaps-wkld
ℹ You can now access the cluster by running 'kubectl config use-context tanzu-cli-tkg-ldaps-wkld@tkg-ldaps-wkld'


$ kubectl config get-contexts
CURRENT  NAME                                     CLUSTER         AUTHINFO                 NAMESPACE
         kubernetes-admin@kubernetes              kubernetes      kubernetes-admin
         tanzu-cli-tkg-ldaps-wkld@tkg-ldaps-wkld  tkg-ldaps-wkld  tanzu-cli-tkg-ldaps-wkld
*        tkg-ldaps-mgmt-admin@tkg-ldaps-mgmt      tkg-ldaps-mgmt  tkg-ldaps-mgmt-admin


$ kubectl config use-context tanzu-cli-tkg-ldaps-wkld@tkg-ldaps-wkld
Switched to context "tanzu-cli-tkg-ldaps-wkld@tkg-ldaps-wkld".


$ kubectl config get-contexts
CURRENT  NAME                                     CLUSTER          AUTHINFO                 NAMESPACE
         kubernetes-admin@kubernetes              kubernetes       kubernetes-admin
*        tanzu-cli-tkg-ldaps-wkld@tkg-ldaps-wkld  tkg-ldaps-wkld   tanzu-cli-tkg-ldaps-wkld
         tkg-ldaps-mgmt-admin@tkg-ldaps-mgmt      tkg-ldaps-mgmt   tkg-ldaps-mgmt-admin

Dex를 통해 AD 엔드포인트에 로그인

그래픽이 아닌 헤드가 없는 데스크톱을 사용하거나 kubectl 명령을 실행하는 데스크톱에 SSH를 입력한 경우 이 시점에서 노드(또는 클러스터와의 상호 작용)를 쿼리하려고 하면 다음과 유사한 메시지가 생성됩니다.

$ kubectl get nodes
Error: no DISPLAY environment variable specified
^C

여기서 일어나는 일은 kubectl이 Pinniped와 Dex를 통해 아이덴티티 프로바이더에 대한 연합 로그인을 수행하기 위해 tanzu login을 호출한다는 것이다. 이 출력은 처음에는 브라우저 탭을 시작하여 AD/LDAP 자격 증명을 묻는 메시지를 표시하려고 할 때까지 저를 혼란스럽게 했습니다. 이러한 자격 증명은 워크로드 클러스터에 대한 액세스 권한을 부여하려는 개발자의 자격 증명입니다. 그렇기 때문에 GUI가 있는 데스크톱에서 이 배포를 수행해야 한다고 요구 사항을 언급했습니다(최소한 명령줄에서 이러한 자격 증명을 제공할 수 있는 방법을 알지 못합니다). 따라서 Dex는 kubectl이 시작되고 tanzu login이 생성되면 AD/LDAP 자격 증명을 묻는 브라우저 페이지를 호스팅합니다. 이때 클러스터와 상호 작용할 사용자의 LDAP 사용자 이름(예: 개발자)이 추가됩니다. 이 사람이 사용자 이름 chogan@rainpole.com을 사용하는 개발자라고 가정합니다. 그런 다음 사용자 이름과 암호를 추가하고 로그인 버튼을 클릭합니다.

자격 증명이 성공하고 모든 것이 올바르게 작동한다고 가정하면 브라우저 탭에 다음이 나타납니다.

kubectl을 통해 시작하는 대신 다음 명령을 실행하여 직접 개발자 액세스를 제공할 수도 있습니다.

$ tanzu login --endpoint https://<MGMT Cluster API Server IP address>:6443 --name <MGMT Cluster Name>

API 서버 IP 주소와 관리 클러스터 이름은 ~/.kube/config에서 가져올 수 있습니다. 그러면 이전과 같이 브라우저 탭이 시작되고 개발자 자격 증명이 다시 한 번 제공됩니다. 이 단계에서는 이 개발자/사용자를 위해 ~/.tanzu/pinniped/sessions.yaml이라는 파일을 만듭니다. 이 경우 Active Directory에서 ID 관리 시스템에서 검색된 모든 정보가 포함됩니다. 지금까지는 좋아. 그러나 아직 완료되지 않았습니다. 개발자로 워크로드 클러스터를 쿼리하려고 하면 다음과 같은 오류가 발생합니다.

$ kubectl get nodes
Error from server (Forbidden): nodes is forbidden: User "chogan@rainpole.com" cannot list resource "nodes" in API group "" at the cluster scope

좋아요 – 이제 우리는 약간의 닭이 먼저냐 달걀 먼저냐의 상황이 있습니다. chogan@rainpole.com용 ClusterRoleBinding을 생성하여 개발자에게 클러스터에 대한 액세스 권한을 부여해야 하지만 개발자는 클러스터와 상호 작용하여 역할 바인딩을 생성할 수 있는 권한이 없습니다. 이것은 클러스터 관리자에 대한 작업입니다. 클러스터 관리자는 –admin 옵션과 함께 tanzu 명령을 사용하여 관리자 권한으로 새 컨텍스트를 검색하여 클러스터에 대한 관리자 권한을 얻습니다.

$ tanzu cluster kubeconfig get tkg-ldaps-wkld --admin
Credentials of cluster 'tkg-ldaps-wkld' have been saved
You can now access the cluster by running 'kubectl config use-context tkg-ldaps-wkld-admin@tkg-ldaps-wkld'


$ kubectl config use-context tkg-ldaps-wkld-admin@tkg-ldaps-wkld
Switched to context "tkg-ldaps-wkld-admin@tkg-ldaps-wkld".


$ kubectl config get-contexts
CURRENT  NAME                                     CLUSTER         AUTHINFO                 NAMESPACE
         kubernetes-admin@kubernetes              kubernetes      kubernetes-admin
         tanzu-cli-tkg-ldaps-wkld@tkg-ldaps-wkld  tkg-ldaps-wkld  tanzu-cli-tkg-ldaps-wkld
         tkg-ldaps-mgmt-admin@tkg-ldaps-mgmt      tkg-ldaps-mgmt  tkg-ldaps-mgmt-admin
*        tkg-ldaps-wkld-admin@tkg-ldaps-wkld      tkg-ldaps-wkld  tkg-ldaps-wkld-admin

이제 워크로드 클러스터에 대한 관리자 권한이 있는 새 컨텍스트 항목을 만들었습니다. 다음 단계는 사용자 chogan@rainpole.com에 대한 ClusterRoleBinding 매니페스트를 생성하여 클러스터에 적용하는 것입니다. 여기 예제에서는 (kind:) 사용자 수준에서 생성되고 있습니다. 또한 액세스가 필요한 여러 개발자 또는 사용자가 모두 동일한 AD 그룹의 일부인 경우 (kind:) 그룹 수준에서 이 작업을 수행할 수 있습니다. 이 경우 cluster-admin의 ClusterRole도 제공하지만, 다른 많은 역할을 할당할 수 있습니다.

$ cat chogan-crb.yaml
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: chogan
subjects:
 - kind: User
 name: chogan@rainpole.com
 apiGroup:
roleRef:
 kind: ClusterRole
 name: cluster-admin
 apiGroup: rbac.authorization.k8s.io


$ kubectl apply -f chogan-crb.yaml
clusterrolebinding.rbac.authorization.k8s.io/chogan created

그러면 컨텍스트를 비관리 컨텍스트로 다시 변경하고 관리 컨텍스트를 삭제한 후 chogan@rainpole.com 사용자가 ClusterRoleBinding을 사용하여 클러스터를 쿼리할 수 있는지 알아보겠습니다.

$ kubectl config use-context tanzu-cli-tkg-ldaps-wkld@tkg-ldaps-wkld
Switched to context "tanzu-cli-tkg-ldaps-wkld@tkg-ldaps-wkld".


$ kubectl config get-contexts
CURRENT NAME                                     CLUSTER         AUTHINFO                 NAMESPACE
        kubernetes-admin@kubernetes              kubernetes      kubernetes-admin
*       tanzu-cli-tkg-ldaps-wkld@tkg-ldaps-wkld  tkg-ldaps-wkld  tanzu-cli-tkg-ldaps-wkld
        tkg-ldaps-mgmt-admin@tkg-ldaps-mgmt      tkg-ldaps-mgmt  tkg-ldaps-mgmt-admin
        tkg-ldaps-wkld-admin@tkg-ldaps-wkld      tkg-ldaps-wkld  tkg-ldaps-wkld-admin


$ kubectl config delete-context tkg-ldaps-wkld-admin@tkg-ldaps-wkld
deleted context tkg-ldaps-wkld-admin@tkg-ldaps-wkld from /home/cormac/.kube/config


$ kubectl config get-contexts
CURRENT NAME                                     CLUSTER         AUTHINFO                 NAMESPACE
        kubernetes-admin@kubernetes              kubernetes      kubernetes-admin
*       tanzu-cli-tkg-ldaps-wkld@tkg-ldaps-wkld  tkg-ldaps-wkld  tanzu-cli-tkg-ldaps-wkld
        tkg-ldaps-mgmt-admin@tkg-ldaps-mgmt      tkg-ldaps-mgmt  tkg-ldaps-mgmt-admin


$ kubectl get nodes
NAME                                  STATUS ROLES                 AGE  VERSION
tkg-ldaps-wkld-control-plane-skhm2    Ready  control-plane,master  38m  v1.20.5+vmware.1
tkg-ldaps-wkld-md-0-5d44ddfb98-7tlsg  Ready  <none>                36m  v1.20.5+vmware.1
tkg-ldaps-wkld-md-0-5d44ddfb98-tjk2v  Ready  <none>                36m  v1.20.5+vmware.1

성공! 사용자/개발자 chogan@rainpole.com은 이제 Pinniped 및 Dex를 통해 Active Directory/LDAP로 인증된 후 TKG 워크로드 클러스터와 성공적으로 상호 작용할 수 있습니다. Dex 통해 tanzu 로그인 명령은 모든 워크로드 클러스터의 개발자에 대해 한 번만 수행하면 됩니다. 그러나 클러스터 관리자가 동일한 개발자에게 각 클러스터에 대해 서로 다른 사용 권한을 부여할 수 있도록 각 워크로드 클러스터에 대해 클러스터 역할 바인딩을 수행해야 합니다. ~./kube/config를 검사하면 워크로드 클러스터에 액세스할 때 Pinniped 인증을 사용한 탄자 로그인이 KUBECONFIG 컨텍스트 로직에 포함됩니다.

문제 해결 팁

TKG로 LDAP를 구성할 때 주의해야 할 몇 가지 사항.

LDAP HOST의 IP 주소 또는 FQDN

LDAP 호스트의 Subject Alternate Name (SAN)을 인증서에 추가하지 않은 경우 FQDN을 사용해야 합니다. 그렇지 않으면 Dex를 통해 연결하려고 하면 다음과 같이 실패합니다.

무시된 LDAP 속성

관리 클러스터 구성에서 OU, DC, CN과 같은 LDAP 속성을 올바르게 설정하지 않으면 다음과 유사한 연결 오류가 발생할 수 있습니다.

Chris Little(NSX ALB)과 Brian Ragazzi’s (LDAP 설정)의 블로그 게시물이 큰 도움이 된 곳이다.

Fat Fingered 인증 정보

이것은 조금 더 명백했다. 올바른 LDAP_BIND_PASSWORD를 제공하지 않는 경우 인증 시 이와 같은 내용이 표시됩니다.

구성을 관리 클러스터에 커밋하기 전에 UI에서 이러한 필드를 채울 때 LDAP 또는 이와 유사한 실행 테스트를 수행할 수 있는 기능이 유용한 기능입니다. 나는 이 기능을 담당하는 여러 팀들에게 이것을 돌려주고 있다.

Dex 포드 고장

물론, 여러분의 구축은 이 정도까지 도달하지 못할 수도 있습니다. Pinniped 또는 Dex Pods가 고장난 문제에 부딪혔을 수 있습니다. 이 예에서는 UI의 LDAP 필드를 모두 채우지 않았습니다. LDAP_USER_SEARCH_USERNAME을(를) 생략했습니다. 모든 필드가 있고 정확한지 확인하기 위해 수행된 유효성 검사는 없습니다. 이 때문에 Pinniped Post Deploy Job Pod가 완료되지 않았습니다. Dex 문제를 지적한 포드 로그를 확인했습니다. Dex 포드의 로그를 확인했을 때 이 필수 필드가 누락되었다는 것을 알 수 있었습니다.

$ kubectl logs pinniped-post-deploy-job-ckcgk -n pinniped-supervisor
2021-06-16T13:15:26.066Z INFO inspect/inspect.go:88 Getting TKG metadata...
2021-06-16T13:15:26.074Z INFO configure/configure.go:65 Readiness check for required resources
2021-06-16T13:15:26.086Z INFO configure/configure.go:102 The Pinniped concierge deployments are ready
2021-06-16T13:15:26.088Z INFO configure/configure.go:136 The Pinniped supervisor deployments are ready
2021-06-16T13:15:26.093Z INFO configure/configure.go:153 The Pinniped OIDCIdentityProvider pinniped-supervisor/upstream-oidc-identity-provider is ready
2021-06-16T13:15:58.428Z ERROR configure/configure.go:177 the Dex deployment is not ready, error: Dex deployment does not have enough ready replicas. 0/1 are ready
github.com/vmware-tanzu-private/core/addons/pinniped/post-deploy/pkg/configure.ensureResources
 /workspace/pkg/configure/configure.go:177
github.com/vmware-tanzu-private/core/addons/pinniped/post-deploy/pkg/configure.TKGAuthentication
 /workspace/pkg/configure/configure.go:197
main.main
 /workspace/main.go:103
runtime.main
 /usr/local/go/src/runtime/proc.go:203
2021-06-16T13:15:58.428Z ERROR workspace/main.go:111 Dex deployment does not have enough ready replicas. 0/1 are ready
main.main
 /workspace/main.go:111
runtime.main
 /usr/local/go/src/runtime/proc.go:203
$ kubectl logs dex-64884d69fc-mhxmj -n tanzu-system-auth
{"level":"info","msg":"config using log level: info","time":"2021-06-16T13:15:46Z"}
{"level":"info","msg":"config issuer: https://0.0.0.0:30167","time":"2021-06-16T13:15:46Z"}
{"level":"info","msg":"kubernetes client apiVersion = dex.coreos.com/v1","time":"2021-06-16T13:15:46Z"}
{"level":"info","msg":"creating custom Kubernetes resources","time":"2021-06-16T13:15:46Z"}
{"level":"info","msg":"checking if custom resource authcodes.dex.coreos.com has been created already...","time":"2021-06-16T13:15:46Z"}
{"level":"info","msg":"The custom resource authcodes.dex.coreos.com already available, skipping create","time":"2021-06-16T13:15:46Z"}
{"level":"info","msg":"checking if custom resource authrequests.dex.coreos.com has been created already...","time":"2021-06-16T13:15:46Z"}
{"level":"info","msg":"The custom resource authrequests.dex.coreos.com already available, skipping create","time":"2021-06-16T13:15:46Z"}
{"level":"info","msg":"checking if custom resource oauth2clients.dex.coreos.com has been created already...","time":"2021-06-16T13:15:46Z"}
{"level":"info","msg":"The custom resource oauth2clients.dex.coreos.com already available, skipping create","time":"2021-06-16T13:15:46Z"}
{"level":"info","msg":"checking if custom resource signingkeies.dex.coreos.com has been created already...","time":"2021-06-16T13:15:46Z"}
{"level":"info","msg":"The custom resource signingkeies.dex.coreos.com already available, skipping create","time":"2021-06-16T13:15:46Z"}
{"level":"info","msg":"checking if custom resource refreshtokens.dex.coreos.com has been created already...","time":"2021-06-16T13:15:46Z"}
{"level":"info","msg":"The custom resource refreshtokens.dex.coreos.com already available, skipping create","time":"2021-06-16T13:15:46Z"}
{"level":"info","msg":"checking if custom resource passwords.dex.coreos.com has been created already...","time":"2021-06-16T13:15:46Z"}
{"level":"info","msg":"The custom resource passwords.dex.coreos.com already available, skipping create","time":"2021-06-16T13:15:46Z"}
{"level":"info","msg":"checking if custom resource offlinesessionses.dex.coreos.com has been created already...","time":"2021-06-16T13:15:46Z"}
{"level":"info","msg":"The custom resource offlinesessionses.dex.coreos.com already available, skipping create","time":"2021-06-16T13:15:46Z"}
{"level":"info","msg":"checking if custom resource connectors.dex.coreos.com has been created already...","time":"2021-06-16T13:15:46Z"}
{"level":"info","msg":"The customresource connectors.dex.coreos.com already available, skipping create","time":"2021-06-16T13:15:46Z"}
{"level":"info","msg":"checking if custom resource devicerequests.dex.coreos.com has been created already...","time":"2021-06-16T13:15:46Z"}
{"level":"info","msg":"The custom resource devicerequests.dex.coreos.com already available, skipping create","time":"2021-06-16T13:15:46Z"}
{"level":"info","msg":"checking if custom resource devicetokens.dex.coreos.com has been created already...","time":"2021-06-16T13:15:46Z"}
{"level":"info","msg":"The custom resource devicetokens.dex.coreos.com already available, skipping create","time":"2021-06-16T13:15:46Z"}
{"level":"info","msg":"config storage: kubernetes","time":"2021-06-16T13:15:46Z"}
{"level":"info","msg":"config static client: pinniped","time":"2021-06-16T13:15:46Z"}
{"level":"info","msg":"config connector: ldap","time":"2021-06-16T13:15:46Z"}
{"level":"info","msg":"config response types accepted: [code]","time":"2021-06-16T13:15:46Z"}
{"level":"info","msg":"config skipping approval screen","time":"2021-06-16T13:15:46Z"}
{"level":"info","msg":"config signing keys expire after: 1h30m0s","time":"2021-06-16T13:15:46Z"}
{"level":"info","msg":"config id tokens valid for: 5m0s","time":"2021-06-16T13:15:46Z"}
failed to initialize server: server: Failed to open connector ldap: failed to open connector: \
failed to create connector ldap: ldap: missing required field "userSearch.username"

그것들은 단지 몇 가지 조언일 뿐이고 알아야 할 것들이 있다. 그것으로 글은 완성되었다. 유용하다고 생각하시길 바랍니다. 더 이상 관찰하거나 제안할 사항이 있으면 언제든지 의견을 남겨 주십시오.

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 항목은 *(으)로 표시합니다

You May Also Like