TKG 1.6 배포 시 LDAP 연동

2022년 10월 18일: AD Group 만 연동을 위한 내용을 추가 하였습니다.

 

 

https://pinniped.dev/

Pinniped

 

 

우선은 LDAPS 활성화를 위해서 LDAP를 지원하는 인증 제공자를 필요로 하며, Active Directory가 해당될 수 있습니다.

일반적으로 많은 기업은 MS AD를 통해서 조직 정보를 분류하고, 사용자를 할당하여 사용할 것입니다. 특히나, VMware Horizon VDI 및 APPs를 이용 시에도 AD는 활용이 되고 있습니다.

 

이 페이지에서는 AD에서의 LDAPS 활성화 방법 등은 다루지 않습니다. 필요한 경우 Google에서 검색해서 활성화를 해주세요.

 

TKG 1.6 배포 과정에서 사용자 인증 제공자를 이용하는 방식으로 OIDC와 LDAPS 2가지 방식을 채택할 수 있는 옵션을 제공하고 있습니다.

일반적으로 LDAPS가 접근하기에 더 쉬운 경로일 듯 보이며, OIDC 형태는 OCTA와 같은 SaaS를 이용할 수 있습니다.

 

여기서는 LDAPS를 활성화 방법을 다룹니다. 아래와 같이 몇 가지 옵션에 대해서 어떤 정의를 갖고 있는지 살펴 보실 수 있습니다.

중요한 항목은 사용자를 Search하고, 어떤 사용자 ID에 대해서 인식하는 Attribute(특성)가 올바르게 불러오고, 조회하고 있는지에 대한 부분입니다.

 

LDAPS: 회사의 LDAPS 서버에 대한 세부 정보를 제공하십시오. LDAPS 끝점을 제외한 모든 설정은 선택 사항입니다.

- LDAPS Endpoint: LDAPS 서버의 IP 또는 DNS 주소입니다. 호스트: 포트 형식으로 LDAP 서버의 주소와 포트를 제공합니다.
- Bind DN: 애플리케이션 서비스 계정의 DN입니다. 커넥터는 이러한 자격 증명을 사용하여 사용자 및 그룹을 검색합니다. LDAP 서버가 익명 인증에 대한 액세스를 제공하는 경우 필요하지 않습니다.
- Bind Password: Bind DN이 설정된 경우 응용 프로그램 서비스 계정의 암호입니다. 사용자 검색 속성을 제공합니다.
- User Search Base DN: LDAP 검색을 시작할 지점입니다. 예를 들어 OU=Organization, DC=domain, DC=io입니다. - 예) AD 도메인: vmk.corp
- Filter(User): LDAP 검색에서 사용할 선택적 필터입니다. 예) (objectClass=User)
- Username: 사용자 ID가 포함된 LDAP 속성입니다. 예: sAMAccountName, Kubernetes가 인식하는 사용자 ID 입니다.

사용자 ID가 포함된 LDAP 속성입니다.
- Group Search Base DN: group search를 위한 LDAP 검색을 시작할 지점입니다. 예를 들어 OU=조직, DC=도메인, DC=io입니다. - 예) AD 도메인: vmk.corp
- Filter(Group): LDAP 검색에서 사용할 선택적 필터입니다. 예) (objectClass=Group)
- Name Attribute: 그룹 이름을 보유하는 LDAP 속성입니다. 예를 들어, 보통 group 속성에서의 cn, name, sAMAccount
- User Attribute: 그룹 레코드의 구성원 속성 값으로 사용되는 사용자 레코드의 속성입니다. 예를 들어, 고유 이름인 dn, 혹은 uid (Group Attribute에 함께 의존하기에, Group Attribute 값에 따라서 달라질 수 있습니다.)
- Group Attribute: 사용자/구성원 정보를 보유하고 있는 그룹 레코드의 속성입니다. 예를 들어, Group 속성에서의 member, memberuid

 

 

Group Search를 위해서는 AD에서 member에 값이 존재 해야 합니다.

LDAP_BIND_DN: cn=binduser,ou=tkgorg,dc=vmk,dc=corp
LDAP_BIND_PASSWORD: <encoded:Vk13YXJlMSE=>
LDAP_GROUP_SEARCH_BASE_DN: ou=tkgorg,dc=vmk,dc=corp
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: vmk-ad.vmk.corp:636
LDAP_ROOT_CA_DATA_B64: LS0tLS1CRUdJTiBDR~~~~~~~~~
LDAP_USER_SEARCH_BASE_DN: ou=개발팀,dc=vmk,dc=corp
LDAP_USER_SEARCH_FILTER: (objectClass=person)
LDAP_USER_SEARCH_NAME_ATTRIBUTE: sAMAccountName
LDAP_USER_SEARCH_USERNAME: sAMAccountName

 

 

💡 중요한 점은 입력되는 옵셥에서 사용자 ID에 대한 정보 조회와 이 조회를 위한 사용자 ID가 실제 AD에서의 Attribute Editor에서 어떤식으로 나타나는지에 대한 항목입니다. LDAP 조회 시, FILTER를 어떤 기준으로 줌으로서 어떤 객체를 가져올 것이냐를 놓고 보면 objectClass를 기준으로 Person 혹은 User가 사용자에 해당할 것입니다. 그러나, “VERIFY LDAP CONFIGURATION” 항목으로 조회를 할 경우에는 다를 수 있습니다. 이 Web UI에서의 현재 VERIFY 항목은 정해진 2가지 값에 대한 조회만을 제공하고 있습니다. “Username” 의 경우에는 cn 값으로 AD에서 입력된 기준으로 보면 given name과 Sur name을 나열한 값이 됩니다. user02@vmk.corp 라는 계정의 성은 “홍”, 이름은 “길동” 이라고 한다면, user02가 아닌 이 Verify 항목에서는 “홍 길동”을 입력하여 실제 사용자가 있는지 확인을 하고 있는 것입니다. “Groupname”의 경우에는 OU 값에 해당합니다. 즉, 해당 tree의 하위 OU가 아닌 경우 조회가 되지 않습니다. 그렇기에 꼭, Verify가 성공을 해야만 하는 것은 아니며, Verify는 일종의 LDAP과 정상적인 연결 상태를 확인하기 위한 참고 정도로 살펴볼 필요가 있습니다. 필요하다면, Web UI가 아닌 일반적은 ldapsearch 명령 도구를 linux 에 설치하여 다른 옵션 값을 부여하여 조회를 하시면 모든 조회는 가능합니다. 우리가 필요한 항목은 LDAP을 연동하고, Kubernetes가 인식할 수 있는 username으로 만드는 것입니다.

 

LDAP 연동 배포 이후 작업

💡 인증된 사용자가 관리 클러스터에 연결할 수 있도록 kubeconfig 생성

사용자가 관리 클러스터에 액세스할 수 있도록 하려면 해당 사용자와 공유할 수 있는 파일로 관리 클러스터의 kubeconfig를 내보냅니다.

admin 버전의 kubeconfig를 내보내는 경우 공유하는 모든 사용자는 관리 클러스터에 대한 전체 액세스 권한을 갖게 되며 LDAP 인증이 우회됩니다. kubeconfig의 일반 버전을 내보내면 클러스터의 리소스에 액세스하기 전에 사용자의 ID가 LDAP으로 확인되도록 필요한 인증 정보로 채워집니다.

 

기본적으로 인증 프로세스에서는 사용자가 클러스터에 연결하는 시스템에 브라우저가 있어야 합니다. tanzu 및 kubectl 명령을 실행하는 컴퓨터에 브라우저가 없는 경우 인증 프로세스 중에 브라우저 자동 열기를 건너뛸 수 있습니다. 자세한 내용은 브라우저가 없는 컴퓨터에서 사용자 인증을 참조하십시오. (웹 브라우저 접속은 어디에서든 management VIP로 접속이 가능하기만 하면 됩니다. TKG 1.6부터 웹 브라우저 접속을 통한 인증이 필수입니다.)

 

# web browser을 skip 하도록 구성
# tanzu cli 명령어가 실행되는 곳에서 web browser가 실행이 되어야 하기에 skip 처리.
export TANZU_CLI_PINNIPED_AUTH_LOGIN_SKIP_BROWSER=true

# --admin 옵션 없이 실행
# management cluster에 대한 kubeconfig 파일 생성
tanzu mc kubeconfig get --export-file /tmp/my-cluster-kubeconfig-mc

# workload cluster에 대한 kubeconfig 파일 생성
tanzu cluster kubeconfig get my-cluster --export-file /tmp/my-cluster-kubeconfig-wl

# 각 kubeconfig 파일을 이용하여 정보 조회 시도하면, 다음의 스냅샷과 같이 외부에 접속이 LB service link가 생성됩니다.
kubectl get pods -A --kubeconfig /tmp/my-cluster-kubeconfig-mc
  or
kubectl get pods -A --kubeconfig /tmp/my-cluster-kubeconfig-wl

 

아래와 같이 로그인 링크가 생성된 이후, 브라우저를 통해서 링크 접속

 

”SEARCH USERNAME”을 “sAMAccountName”으로 설정을 해놨기 때문에 사용자 ID 와 Password 만을 접속된 로그인 화면에 입력하면 아래와 같이 SSH 화면에 다시 입력할 code 값을 회신 받습니다.

사용자 로그인 화면(웹 브라우저로 생성된 링크로 접속)

로그인을 완료하면 SSH에 회신을 위한 코드 값이 생성됨

코드 값 입력 이후 정상적으로 동작하지 않고 error 값이 출력 되는 것을 확인할 수 있습니다. 이는 Cluster role binding이 되어 있지 않음으로 생기는 정상적인 행동입니다.

 

# 동일하게 이전에 수행한 kubeconfig 파일 경로를 이용해서 다시 조회를 해볼 경우
# kubectl get pods -A --kubeconfig FILE-PATH
kubectl get pods -A --kubeconfig /tmp/my-cluster-kubeconfig-mc

아래와 같은 메시지를 확인할 수 있습니다.

Error from server (Forbidden): pods is forbidden: User "user@example.com" cannot list resource "pods" in API group "" at the cluster scope

 

Cluster role binding을 통해서 user 에게 권한을 부여합니다.

Management cluster에 대한 권한 부여

• Management cluster로 context를 전환

# Tanzu Login 및 Management Cluster로 context를 전환
kubectl config use-context id-mgmt-test-admin@id-mgmt-test

 

• 다음과 같은 규칙을 따름

A RoleBinding can reference a Role or ClusterRole.

A ClusterRoleBinding can reference only a ClusterRole.

# 새로운 clusterrolebinding을 위한 role name "id-mgmt-test-rb" 를 정의하고, clsuterrole "cluster-admin" 을 부여하며, 사용자 "user02@vmk.corp" 에게 부여하는 예제
kubectl create clusterrolebinding id-mgmt-test-rb --clusterrole cluster-admin --user user02

# 하나의 role에 여러 정보를 넣을 수 있습니다.
kubectl create clusterrolebinding id-mgmt-test-rb --clusterrole cluster-admin --user user02 --user user03

# Role에 AD Group 만을 바인딩할 수 있습니다.
kubectl create clusterrolebinding id-mgmt-test-rb --clusterrole cluster-admin --group 개발팀

• LDAPS: The username attribute is set in the Username field under LDAPS Identity Management Source –> User Search Attributes in the installer interface or the LDAP_USER_SEARCH_USERNAME configuration variable.

중요한 점은 최초 LDAP 구성 시, LDAP_USER_SEARCH_USERNAME에 할당한 attribute 값에 해당하는 value 여야 하는 점 입니다. 앞서 “sAMAccountName” 이라는 attribute로 했기 때문에 전체 user@domain 주소가 아닌 user 값만을 입력하여 role을 할당합니다.

롤 바인딩 이후, 약 10초 이후에 다시 조회를 해보면 정상적으로 명령어가 동작됨을 확인할 수 있습니다.

 

kubectl get pods -A --kubeconfig /tmp/my-cluster-kubeconfig-mc

 

Workload cluster에 대한 권한 부여

Management Cluster와 유사한 과정을 거치며, 동일하게 RBAC 권한을 사용자에게 부여해줄 필요가 있습니다.

# Workload cluster의 kubeconfig 파일을 로컬 머신으로 export 합니다.
tanzu cluster kubeconfig get my-cluster --export-file /tmp/my-cluster-kubeconfig
# download한 kubeconfig 파일을 이용하여 kubectl 명령어 수행
kubectl get pods -A --kubeconfig /tmp/my-cluster-kubeconfig

 

아래와 같이 로그인 링크가 생성된 이후, 브라우저를 통해서 링크 접속

 

 

입력 이후 정상적으로 동작하지 않고 error 값이 출력 되는 것을 확인할 수 있습니다. 이는 Cluster role binding이 되어 있지 않음으로 생기는 정상적인 행동입니다.

사용자에 클러스터 권한을 주는 작업을 수행합니다.

# 생성된 워크로드 클러스터의 admin kubeconfig 인증 값을 획득
tanzu cluster kubeconfig get my-cluster --admin
# admin 권한으로 워크로드 클러스터로 context 전환
kubectl config get-contexts
kubectl config use-context my-cluster-admin@my-cluster-admin

# Cluster role을 사용자에 부여합니다.
kubectl create clusterrolebinding workload-test-rb --clusterrole cluster-admin --user user03

 

Kubernetes의 권한 부여 방식을 참조하여, 요구되는 권한에 맞는 사용자를 지정할 필요가 있습니다.

https://kubernetes.io/docs/reference/access-authn-authz/rbac/

Using RBAC Authorization

 

 

사용자 Linux machine에서도 non-admin으로 생성된 kubeconfig 파일을 복제한 이후, 동일한 방법으로 웹 브라우저를 통한 ID 로그인을 한 이후 사용

# TKG 1.6 부터는 web browser를 통한 대화형 로그인을 필수로 수행해야 합니다.
# 그럼으로 SSH 접속하는 머신이 아니더라도, 어떤 위치에서든지 VIP를 통해서 웹브라우저를 통한 DEX 화면의 로그인 접속을 필요로 합니다. VIP는 Management Cluster에서 생성된 서비스 IP 대역임으로 사용자가 해당 VIP로 웹 브라우저를 통한 접근이 가능해야 합니다.

kubectl get pod -A --kubeconfig /tmp/my-cluster-kubeconfig-wl

 

고객사의 인증서를 가지고 통신을 위해서는 기존 생성된 인증서를 대체하는 작업을 진행해 주시기 바랍니다.

https://docs.vmware.com/en/VMware-Tanzu-Kubernetes-Grid/1.6/vmware-tanzu-kubernetes-grid-16/GUID-iam-custom-pinniped-certificates.html

Configure and Manage TLS Certificates for Pinniped and Dex