LDAP로 GKE Identity Service 설정
이 문서는 클러스터에 GKE Identity Service를 설정하는 클러스터 관리자 또는 애플리케이션 운영자를 대상으로 합니다. 여기에서는 Microsoft Active Directory를 포함하여 선호하는 경량 디렉터리 액세스 프로토콜(LDAP) 공급업체를 사용하여 클러스터에 GKE Identity Service를 설정하는 방법을 설명합니다. GKE Identity Service의 LDAP 공급업체 설정 안내에 따라 사용자 또는 플랫폼 관리자가 이미 LDAP 공급업체의 로그인 세부정보를 가지고 있다고 가정합니다. GKE Identity Service 작동 방법 및 기타 설정 옵션에 대한 자세한 내용은 개요를 참조하세요. 개발자 또는 다른 클러스터 사용자로서 이 서비스를 사용하여 클러스터에 액세스하는 방법은 GKE Identity Service로 클러스터에 액세스를 참조하세요. LDAP가 있는 GKE Identity Service는 VMware용 GKE(사용자 클러스터) 또는 베어메탈용 GKE에서만 사용할 수 있습니다.
시작하기 전에
- 다음 명령줄 도구가 설치되었는지 확인합니다.
- 프로젝트에서 사용할 수 있도록 gcloud CLI를 초기화했는지 확인합니다.
이 설정을 진행하는 동안 LDAP 서버의 문서를 참조해야 할 수 있습니다. 다음 관리자 가이드에서는 LDAP 서버에 로그인하고 클러스터를 구성하기 위해 필요한 정보를 찾을 수 있는 장소를 포함하여 몇 가지 인기 있는 LDAP 제공업체에 대한 구성을 설명합니다.
LDAP 서비스 계정 보안 비밀 채우기
GKE Identity Service를 통해 LDAP 서버에 인증하고 사용자 세부정보를 검색하려면 서비스 계정 보안 비밀이 필요합니다. LDAP 인증에 허용되는 두 가지 서비스 계정 유형은 기본 인증(서버 인증을 위해 사용자 이름과 비밀번호 사용) 또는 클라이언트 인증서(클라이언트 비공개 키 및 클라이언트 인증서 사용)입니다. 사용자 또는 플랫폼 관리자에게 다음 GKE Identity Service용 LDAP 공급업체 설정에서 가져온 공급업체 관련 정보가 있어야 합니다.
LDAP 서버 로그인 정보를 GKE Identity Service에 제공하려면 GKE Identity Service용 LDAP 공급업체 설정에서 가져온 로그인 세부정보로 Kubernetes 보안 비밀 리소스를 만들어야 합니다.
다음 예시에서는 두 서비스 계정 유형 모두에 대해 보안 비밀을 구성하는 방법을 보여줍니다. 예시에서는 anthos-identity-service
네임스페이스에 적용되는 보안 비밀을 보여줍니다.
다음은 기본 인증 보안 비밀 구성의 예시입니다.
apiVersion: v1 kind: Secret metadata: name: SERVICE_ACCOUNT_SECRET_NAME namespace: "anthos-identity-service" type: kubernetes.io/basic-auth # Make sure the type is correct data: username: USERNAME # Use a base64-encoded username password: PASSWORD # Use a base64-encoded password
여기서 SERVICE_ACCOUNT_SECRET_NAME은 이 보안 비밀에 대해 선택된 이름입니다. 사용자 이름과 비밀번호 값을 이전 단계에서 가져온 사용자 이름 및 비밀번호로 바꿉니다. USERNAME은 base64로 인코딩된 사용자 이름입니다. PASSWORD는 base64로 인코딩된 비밀번호입니다.
다음은 클라이언트 인증서 보안 비밀 구성의 예시입니다.
apiVersion: v1 kind: Secret metadata: name: SERVICE_ACCOUNT_SECRET_NAME namespace: anthos-identity-service type: kubernetes.io/tls # Make sure the type is correct data: # the data is abbreviated in this example tls.crt: | MIIC2DCCAcCgAwIBAgIBATANBgkqh ... tls.key: | MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ...
여기서 SERVICE_ACCOUNT_SECRET_NAME은 이 보안 비밀에 대해 선택된 이름입니다. TLS 인증서와 키 값을 이전 단계에서 가져온 인코딩된 인증서와 키 값으로 바꿉니다.
이 예시에서는 권장 방법인 anthos-identity-service
네임스페이스에 적용되는 보안 비밀을 보여줍니다. 이는 anthos-identity-service
의 보안 비밀 읽기 권한이 GKE Identity Service에 기본으로 있기 때문입니다. 다른 네임스페이스를 사용하려면 보안 비밀에서 메타데이터를 변경한 후 다음과 같이 GKE Identity Service에 해당 네임스페이스의 보안 비밀을 읽을 수 있는 권한을 부여하는 새 RBAC 정책을 추가합니다.
--- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: NAMESPACE name: ais-secret-reader-role rules: - apiGroups: [""] resources: ["secrets"] verbs: ["get","list"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: ais-secret-reader-role-binding namespace: NAMESPACE roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: ais-secret-reader-role subjects: - kind: ServiceAccount name: default namespace: anthos-identity-service ---
클러스터 구성
GKE Identity Service는 ID 공급업체에 대한 정보 필드, 사용자 정보를 반환하는 데 필요한 매개변수와 함께 특수 Kubernetes 커스텀 리소스 유형(CRD)을 사용하여 ClientConfig
라는 클러스터를 구성합니다. 또한 ClientConfig
구성에는 이전 섹션에서 만들고 적용한 보안 비밀의 보안 비밀 이름과 네임스페이스가 포함되어 있어 GKE Identity Service가 LDAP 서버에 인증할 수 있습니다.
클러스터에 구성을 적용하려면 kube-public
네임스페이스에서 clientconfig
유형의 KRM 기본 객체를 수정합니다.
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-public edit clientconfig default
여기서 USER_CLUSTER_KUBECONFIG
는 클러스터의 kubeconfig 파일 경로입니다. kubeconfig에 여러 컨텍스트가 있으면 현재 컨텍스트가 사용됩니다. 명령어를 사용하기 전 현재 컨텍스트를 올바른 클러스터로 재설정해야 할 수 있습니다.
다음은 ClientConfig
구성의 형식을 보여줍니다.
authentication: - name: NAME_STRING ldap: host: HOST_NAME certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA connectionType: CONNECTION_TYPE serviceAccountSecret: name: SERVICE_ACCOUNT_SECRET_NAME namespace: NAMESPACE type: SECRET_FORMAT user: baseDN: BASE_DN filter: FILTER identifierAttribute: IDENTIFIER_ATTRIBUTE loginAttribute: LOGIN_ATTRIBUTE group: baseDN: BASE_DN filter: FILTER identifierAttribute: IDENTIFIER_ATTRIBUTE
다음 표에서는 ClientConfig
CRD의 필드를 설명합니다.
필드 | 필수 | 설명 | 형식 |
---|---|---|---|
name | 예 | 이 LDAP 구성을 식별하기 위한 이름 | 문자열 |
호스트 | 예 | LDAP 서버의 호스트 이름 또는 IP 주소입니다. 포트는 선택사항이며 지정하지 않으면 389로 기본 설정됩니다. 예를 들면 ldap.server.example.com 또는 10.10.10.10:389 입니다.
|
문자열 |
certificateAuthorityData | 특정 LDAP 연결 유형에 필요 | LDAP 서버에 대해 Base64로 인코딩된 PEM 형식의 인증 기관 인증서를 포함합니다. ldaps 및 startTLS 연결에만 제공되어야 합니다.
|
문자열 |
connectionType | 예 | LDAP 서버에 연결할 때 사용할 LDAP 연결 유형입니다. 기본값은 startTLS 입니다. insecure 모드는 서버와의 모든 통신이 일반 텍스트로 진행되기 때문에 개발 목적으로만 사용해야 합니다.
|
문자열 |
serviceAccountSecret | |||
name | 예 | LDAP 서비스 계정의 사용자 인증 정보를 저장하는 Kubernetes 보안 비밀의 이름입니다. | 문자열 |
네임스페이스 | 예 | LDAP 서비스 계정의 사용자 인증 정보를 저장하는 Kubernetes 보안 비밀의 네임스페이스입니다. | 문자열 |
유형 | 예 | 다양한 종류의 사용자 인증 정보를 지원하기 위해 서비스 계정 보안 비밀의 형식을 정의합니다. 보안 비밀 구성에 basic-auth 를 지정한 경우에는 basic 이고, 그렇지 않으면 tls 입니다. 지정하지 않으면 기본적으로 basic 입니다.
|
문자열 |
사용자 | |||
baseDN | 예 | 사용자 항목을 검색하기 위한 LDAP 디렉터리의 하위 트리 위치입니다. | 문자열 |
필터 | 아니요 | 사용자를 검색할 때 적용할 선택적인 필터입니다. 이를 사용하여 로그인이 허용되는 사용자 계정을 추가적으로 제한할 수 있습니다. 지정하지 않으면 기본적으로 (objectClass=User) 입니다.
|
문자열 |
identifierAttribute | 아니요 | 인증 후 사용자 ID로 사용할 속성을 결정합니다.
이 필드는 사용자 이름으로 사용자 로그인을 허용하기 위한 loginAttribute 필드와 구분되지만, 해당 식별자로 이메일 주소 또는 전체 고유 이름(DN)이 사용됩니다. 예를 들어 loginAttribute를 sAMAccountName 으로 설정하고 identifierAttribute를 userPrincipleName 으로 설정하면 사용자가 bsmith 로 로그인할 수 있지만 사용자의 실제 RBAC 정책은 bsmith@example.com 으로 기록됩니다.
각 사용자에 대해 고유하기 때문에 userPrincipleName 을 사용하는 것이 좋습니다. 지정하지 않으면 기본적으로 userPrincipleName 입니다.
|
문자열 |
loginAttribute | 아니요 | 입력 사용자 이름과 일치하는 속성 이름입니다. (<LoginAttribute>=<username>) 과 같이 LDAP 데이터베이스에서 사용자를 찾기 위해 사용되며, 선택적인 필터 필드와 결합됩니다. 기본값은 userPrincipleName 입니다.
|
문자열 |
group(선택적 필드) | |||
baseDN | 예 | 그룹 항목을 검색하기 위한 LDAP 디렉터리의 하위 트리 위치입니다. | 문자열 |
필터 | 아니요 | 사용자가 속한 그룹을 검색할 때 사용할 선택적인 필터입니다. 각 사용자에게 반환되는 그룹 수를 줄이기 위해 특정 그룹과만 명시적으로 일치하도록 사용할 수 있습니다. 기본값은 (objectClass=Group) 입니다.
|
문자열 |
identifierAttribute | 아니요 | 사용자가 속한 각 그룹의 식별 이름입니다. 예를 들어 distinguishedName 으로 설정되었으면 RBAC 및 다른 그룹 예상값도 전체 DN으로 기록되어야 합니다. 지정하지 않으면 기본적으로 distinguishedName 입니다.
|
문자열 |
다음 단계
구성이 적용된 후에는 GKE Identity Service를 사용하여 클러스터에 대한 사용자 액세스를 설정합니다.