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