이 문서는 Google Distributed Cloud의 인증 문제를 해결하는 데 도움이 됩니다. OpenID Connect(OIDC) 및 경량 디렉터리 액세스 프로토콜(LDAP)에 대한 구체적인 정보와 함께 일반적인 문제 해결 정보 및 안내가 제공됩니다.
OIDC 및 LDAP 인증에는 GKE Identity Service가 사용됩니다. Google Distributed Cloud에서 GKE Identity Service를 사용하려면 먼저 ID 공급업체를 구성해야 합니다. GKE Identity Service의 ID 공급업체를 구성하지 않은 경우 다음과 같은 더욱 일반적인 공급업체 중 하나의 안내를 따르세요.
ID 로그와 테스트 연결을 사용 설정하고 검토하는 방법은 GKE Identity Service ID 공급업체 문제 해결 가이드를 참조하세요.
추가 지원이 필요하면 Cloud Customer Care에 문의하세요.일반적인 문제해결
다음 문제 해결 팁은 Google Distributed Cloud의 일반적인 인증 및 승인 문제를 해결하는 데 도움이 됩니다. 이러한 문제가 적용되지 않거나 OIDC 또는 LDAP에 문제가 있는 경우 GKE Identity Service 문제 해결 섹션으로 이동하세요.
gcloud anthos auth 최신 상태로 유지
gcloud anthos auth 설치 구성요소가 최신 버전인지 확인하면 일반적인 여러 문제를 방지할 수 있습니다.
확인해야 할 두 가지 사항이 있습니다. gcloud anthos auth 명령어에는 Google Cloud CLI 핵심 구성요소와 별도의 패키지 anthos-auth 구성요소의 로직이 포함되어 있습니다.
Google Cloud CLI를 업데이트하려면 다음을 실행합니다.
gcloud components updateanthos-auth구성요소를 업데이트하려면 다음을 실행합니다.gcloud components install anthos-auth
잘못된 제공업체 구성
ID 공급업체 구성이 잘못된 경우 로그인을 클릭하면 ID 공급업체의 오류 화면이 표시됩니다. 공급업체별 안내에 따라 제공업체 또는 클러스터를 올바르게 구성합니다.
잘못된 구성
Google Cloud 콘솔이 클러스터에서 OIDC 구성을 읽을 수 없으면 로그인 버튼이 중지됩니다. 클러스터 OIDC 구성 문제를 해결하려면 이 문서의 다음 OIDC 문제 해결 섹션을 참조하세요.
잘못된 권한
인증 절차를 완료했지만 클러스터의 세부정보가 여전히 표시되지 않는 경우 OIDC와 함께 사용한 계정에 올바른 RBAC 권한을 부여했는지 확인하세요. 이 계정은 Google Cloud 콘솔에 액세스하는 데 사용하는 계정과 다른 계정일 수 있습니다.
갱신 토큰 누락
승인 서버에서 동의를 요청하지만 필요한 인증 매개변수가 제공되지 않으면 다음 오류가 발생합니다.
Error: missing 'RefreshToken' field in 'OAuth2Token' in credentials struct
이 문제를 해결하려면 ClientConfig 리소스의 authentication.oidc.extraParams 필드에 prompt=consent를 추가합니다. 그런 다음 클라이언트 인증 파일을 다시 생성합니다.
갱신 토큰 만료
kubeconfig 파일의 갱신 토큰이 만료되면 다음 문제가 발생합니다.
Unable to connect to the server: Get {DISCOVERY_ENDPOINT}: x509:
certificate signed by unknown authority
이 문제를 해결하려면 gcloud anthos auth login 명령어를 다시 실행합니다.
gcloud anthos auth login 실패, proxyconnect tcp 오류
이 문제는 https_proxy 또는 HTTPS_PROXY 환경 변수 구성에 오류가 있으면 발생합니다. 환경 변수에 https://가 지정된 경우 프록시가 SOCK5와 같은 기타 프로토콜을 사용하여 HTTPS 연결을 처리하도록 구성되어 있으면 GoLang HTTP 클라이언트 라이브러리가 실패할 수 있습니다.
다음과 같은 오류 메시지가 반환될 수 있습니다.
proxyconnect tcp: tls: first record does not look like a TLS handshake
이 문제를 해결하려면 https_proxy 및 HTTPS_PROXY 환경 변수를 수정하여 https:// prefix를 생략합니다. Windows에서는 시스템 환경 변수를 수정합니다. 예를 들어 https_proxy 환경 변수의 값을 https://webproxy.example.com:8000에서 webproxy.example.com:8000으로 변경합니다.
gcloud anthos auth login으로 생성된 kubeconfig를 사용할 때 클러스터 액세스 실패
이 문제는 Kubernetes API 서버에서 사용자를 승인할 수 없으면 발생합니다. 이는 적절한 RBAC가 없거나 잘못된 경우 또는 클러스터의 OIDC 구성에 오류가 있는 경우에 발생할 수 있습니다. 다음 오류 예시가 표시될 수 있습니다.
Unauthorized
이 문제를 해결하려면 다음 단계를 완료하시기 바랍니다.
gcloud anthos auth login으로 생성된 kubeconfig 파일에서id-token값을 복사합니다.kind: Config ... users: - name: ... user: auth-provider: config: id-token: xxxxyyyyjwt-cli를 설치하고 다음을 실행합니다.
jwt ID_TOKENOIDC 구성을 확인합니다.
ClientConfig리소스에는group및username필드가 있습니다. 이러한 필드는 Kubernetes API 서버에서--oidc-group-claim및--oidc-username-claim플래그를 설정하는 데 사용됩니다. API 서버에 토큰이 있으면 이 서버에서 토큰을 GKE Identity Service로 전달합니다. 이를 통해 추출된group-claim및username-claim이 다시 API 서버로 반환됩니다. API 서버에서는 응답을 사용하여 해당 그룹이나 사용자에게 올바른 권한이 있는지 확인합니다.ClientConfig리소스에서group및user에 설정된 클레임이 ID 토큰에 있는지 확인합니다.적용된 RBAC를 확인합니다.
username-claim으로 지정된 사용자 또는 이전 단계의group-claim에 나열된 그룹 중 하나에 대한 올바른 권한을 보유한 RBAC가 있는지 확인합니다. RBAC의 사용자 또는 그룹 이름에는ClientConfig리소스에 지정된usernameprefix또는groupprefix를 프리픽스로 지정해야 합니다.usernameprefix가 비어 있고username이email이외의 값이면 기본적으로issuerurl#프리픽스가 추가됩니다. 사용자 이름 프리픽스를 중지하려면usernameprefix를-로 설정합니다.사용자 및 그룹 프리픽스에 대한 자세한 내용은 OIDC로 인증을 참조하세요.
ClientConfig리소스:oidc: ... username: "unique_name" usernameprefix: "-" group: "group" groupprefix: "oidc:"ID 토큰:
{ ... "email": "cluster-developer@example.com", "unique_name": "EXAMPLE\cluster-developer", "group": [ "Domain Users", "EXAMPLE\developers" ], ... }다음 RBAC binding은 이 그룹과 사용자에게
pod-reader클러스터 역할을 부여합니다. 이때 이름 필드에 이중 슬래시 대신 단일 슬래시를 사용한다는 것에 유의하세요.그룹 ClusterRoleBinding:
apiVersion: kind: ClusterRoleBinding metadata: name: example-binding subjects: - kind: Group name: "oidc:EXAMPLE\developers" apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: pod-reader apiGroup: rbac.authorization.k8s.io사용자 ClusterRoleBinding:
apiVersion: kind: ClusterRoleBinding metadata: name: example-binding subjects: - kind: User name: "EXAMPLE\cluster-developer" apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: pod-reader apiGroup: rbac.authorization.k8s.ioKubernetes API 서버 로그를 확인합니다.
Kubernetes API 서버에 구성된 OIDC 플러그인이 올바르게 시작하지 않으면 ID 토큰이 표시될 때 API 서버에서
Unauthorized오류를 반환합니다. API 서버의 OIDC 플러그인에 문제가 있는지 확인하려면 다음을 실행하세요.kubectl logs statefulset/kube-apiserver -n USER_CLUSTER_NAME \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG다음을 바꿉니다.
USER_CLUSTER_NAME: 로그를 볼 사용자 클러스터의 이름입니다.ADMIN_CLUSTER_KUBECONFIG: 관리자 클러스터 kubeconfig 파일입니다.
gkectl create-login-config가 clientconfig를 가져올 수 없음
gkectl create-login-config에 전달된 kubeconfig 파일이 사용자 클러스터 파일이 아니거나 클러스터를 만드는 동안 ClientConfig 리소스가 발생되지 않았을 때 이 문제가 발생합니다.
Error getting clientconfig using KUBECONFIG
이 문제를 해결하려면 사용자 클러스터에 올바른 kubeconfig 파일이 있는지 확인합니다. 그런 다음 ClientConfig 리소스가 클러스터에 있는지 확인합니다.
kubectl get clientconfig default -n kube-public \
--kubeconfig USER_CLUSTER_KUBECONFIG
USER_CLUSTER_KUBECONFIG를 사용자 클러스터 kubeconfig 파일의 경로로 바꿉니다.
중복된 클러스터 이름으로 인해 gkectl create-login-config 실패
대상 파일에 이미 존재하는 클러스터 이름이 포함된 로그인 구성 데이터를 쓰려고 하면 이 문제가 발생합니다. 각 로그인 구성 파일에는 고유한 클러스터 이름이 포함되어야 합니다.
error merging with file MERGE_FILE because MERGE_FILE contains a cluster with
the same name as the one read from KUBECONFIG. Please write to a new
output file
이 문제를 해결하려면 --output 플래그를 사용하여 새 대상 파일을 지정합니다.
--output을 제공하지 않으면 로그인 구성 데이터가 현재 디렉터리의 kubectl-anthos-config.yaml 파일에 작성됩니다.
OIDC 문제 해결
Google Distributed Cloud에서 OIDC 인증이 작동하지 않는다면 보통은 ClientConfig 리소스의 OIDC 사양이 잘못 구성되었기 때문입니다.
ClientConfig 리소스에서는 OIDC 문제의 원인을 파악할 수 있도록 로그 및 OIDC 사양을 검토하는 방법을 설명합니다.
ID 로그와 테스트 연결을 사용 설정하고 검토하는 방법은 GKE Identity Service ID 공급업체 문제 해결 가이드를 참조하세요. GKE Identity Service가 예상대로 작동하는지 확인하거나 문제를 식별한 후에 다음 OIDC 문제 해결 정보를 검토하세요.
클러스터의 OIDC 사양 확인
클러스터의 OIDC 정보는 kube-public 네임스페이스의 ClientConfig 리소스에 지정됩니다.
kubectl get을 사용하여 사용자 클러스터의 OIDC 리소스를 출력합니다.kubectl --kubeconfig KUBECONFIG -n kube-public get \ clientconfig.authentication.gke.io default -o yamlKUBECONFIG를 사용자 클러스터 kubeconfig 파일의 경로로 바꿉니다.필드 값을 검토하여 사양이 OIDC 제공업체에 대해 올바르게 구성되었는지 확인합니다.
사양에서 구성 문제를 식별하면 OIDC를 다시 구성합니다.
문제를 직접 진단하고 해결할 수 없는 경우 Google Cloud 지원팀에 문의하세요.
Google Cloud 지원팀에서 OIDC 문제를 진단하고 해결하는 데 GKE Identity Service 로그와 OIDC 사양이 필요합니다.
OIDC 인증이 사용 설정되어 있는지 확인
OIDC 인증을 테스트하기 전에 OIDC 인증이 클러스터에 사용 설정되어 있는지 확인합니다.
다음과 같이 GKE Identity Service 로그를 검사합니다.
kubectl logs -l k8s-app=ais -n anthos-identity-service다음 출력 예시에서는 OIDC 인증이 올바르게 사용 설정되었음을 보여줍니다.
... I1011 22:14:21.684580 33 plugin_list.h:139] OIDC_AUTHENTICATION[0] started. ...OIDC 인증이 올바르게 사용 설정되지 않으면 다음 예시와 비슷한 오류가 표시됩니다.
Failed to start the OIDC_AUTHENTICATION[0] authentication method with error:보고된 특정 오류를 검토하고 수정해 보세요.
OIDC 인증 테스트
OIDC 기능을 사용하려면 UI 및 브라우저가 사용 설정된 워크스테이션을 사용합니다. 텍스트 기반 SSH 세션에서는 이러한 단계를 수행할 수 없습니다. OIDC가 클러스터에서 올바르게 작동하는지 테스트하려면 다음 단계를 완료합니다.
- Google Cloud CLI를 다운로드합니다.
로그인 구성 파일을 생성하려면 다음
gcloud anthos create-login-config명령어를 실행합니다.gcloud anthos create-login-config \ --output user-login-config.yaml \ --kubeconfig KUBECONFIGKUBECONFIG를 사용자 클러스터 kubeconfig 파일의 경로로 바꿉니다.사용자를 인증하려면 다음 명령어를 실행합니다.
gcloud anthos auth login --cluster CLUSTER_NAME \ --login-config user-login-config.yaml \ --kubeconfig AUTH_KUBECONFIG다음을 바꿉니다.
- CLUSTER_NAME을 연결할 사용자 클러스터의 이름으로 바꿉니다.
- AUTH_KUBECONFIG를 클러스터에 액세스할 수 있는 사용자 인증 정보가 포함된 새 kubeconfig 파일로 바꿉니다. 자세한 내용은 클러스터에 인증을 참조하세요.
로컬 워크스테이션의 기본 웹브라우저에서 로그인 동의 페이지가 열립니다. 이 로그인 프롬프트에서 사용자에게 유효한 인증 정보를 제공합니다.
이전 로그인 단계를 성공적으로 완료하면 현재 디렉터리에 kubeconfig 파일이 생성됩니다.
사용자 인증 정보가 포함된 새 kubeconfig 파일을 테스트하려면 사용자 클러스터의 포드를 나열합니다.
kubectl get pods --kubeconfig AUTH_KUBECONFIGAUTH_KUBECONFIG를 이전 단계에서 생성된 새 kubeconfig 파일의 경로로 바꿉니다.
성공적으로 인증 가능하지만 계정에 할당된 역할 기반 액세스 제어(RBAC)가 없음을 나타내는 다음 예시 메시지가 반환될 수 있습니다.
Error from server (Forbidden): pods is forbidden: User "XXXX" cannot list resource "pods" in API group "" at the cluster scope
OIDC 인증 로그 검토
OIDC로 인증할 수 없는 경우 GKE Identity Service 로그를 검토하면 문제를 디버깅하는 데 가장 관련성이 높고 유용한 정보를 찾을 수 있습니다.
다음과 같이
kubectl logs를 사용하여 GKE Identity Service 로그를 출력합니다.kubectl --kubeconfig KUBECONFIG \ -n anthos-identity-service logs \ deployment/ais --all-containers=trueKUBECONFIG를 사용자 클러스터 kubeconfig 파일의 경로로 바꿉니다.로그에서 OIDC 문제를 진단하는 데 도움이 되는 오류를 검토합니다.
예를 들어
ClientConfig리소스의issuerURL필드에htps://accounts.google.com과 같은 오타(예:https에서t가 누락됨)가 있을 수 있습니다. GKE Identity Service 로그에 다음 예와 같은 항목이 포함됩니다.OIDC (htps://accounts.google.com) - Unable to fetch JWKs needed to validate OIDC ID token.로그에서 구성 문제를 식별하면 OIDC를 재구성하고 구성 문제를 수정합니다.
문제를 직접 진단하고 해결할 수 없는 경우 Google Cloud 지원팀에 문의하세요. Google Cloud 지원팀에서 OIDC 문제를 진단하고 해결하는 데 GKE Identity Service 로그와 OIDC 사양이 필요합니다.
일반적인 OIDC 문제
OIDC 인증에 문제가 있으면 다음과 같은 일반적인 문제를 검토합니다. 문제를 해결하는 방법에 대한 안내를 수행합니다.
서비스 'ais'에 사용할 수 있는 엔드포인트 없음
ClientConfig 리소스를 저장하면 다음 오류 메시지가 반환됩니다.
Error from server (InternalError): Internal error occurred: failed calling webhook "clientconfigs.validation.com":
failed to call webhook: Post "https://ais.anthos-identity-service.svc:15000/admission?timeout=10s":
no endpoints available for service "ais"
이 오류는 비정상 GKE Identity Service 엔드포인트로 인해 발생합니다. GKE Identity Service 포드에서 검증 웹훅을 제공할 수 없습니다.
GKE Identity Service 포드가 비정상인지 확인하려면 다음 명령어를 실행합니다.
kubectl get pods -n anthos-identity-service \ --kubeconfig KUBECONFIGKUBECONFIG를 사용자 클러스터 kubeconfig 파일의 경로로 바꿉니다.다음 예시 출력은 GKE Identity Service 포드가 비정상 종료됨을 의미합니다.
NAME READY STATUS RESTARTS AGE ais-5949d879cd-flv9w 0/1 ImagePullBackOff 0 7m14s포드에 문제가 있는 이유를 알아보려면 포드 이벤트를 살펴보세요.
kubectl describe pod -l k8s-app=ais \ -n anthos-identity-service \ --kubeconfig KUBECONFIGKUBECONFIG를 사용자 클러스터 kubeconfig 파일의 경로로 바꿉니다.다음 출력 예시는 이미지를 가져올 때 권한 오류를 보고합니다.
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 10m default-scheduler Successfully assigned anthos-identity-service/ais-5949d879cd-flv9w to pool-1-76bbbb8798-dknz5 Normal Pulling 8m23s (x4 over 10m) kubelet Pulling image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00" Warning Failed 8m21s (x4 over 10m) kubelet Failed to pull image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00": rpc error: code = Unknown desc = failed to pull and unpack image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00": failed to resolve reference "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00": pulling from host gcr.io failed with status code [manifests hybrid_identity_charon_20220808_2319_RC00]: 401 Unauthorized Warning Failed 8m21s (x4 over 10m) kubelet Error: ErrImagePull Warning Failed 8m10s (x6 over 9m59s) kubelet Error: ImagePullBackOff Normal BackOff 4m49s (x21 over 9m59s) kubelet Back-off pulling image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00"포드 이벤트에서 문제가 보고되면 영향을 받는 영역에서 문제 해결을 계속합니다. 추가 지원이 필요하면 Google Cloud 지원팀에 문의하세요.
서버에서 응답 바이트 읽기 실패
GKE Identity Service 로그에 다음 오류가 표시될 수 있습니다.
E0516 07:24:38.314681 65 oidc_client.cc:207] Failed fetching the Discovery URI
"https://oidc.idp.cloud.example.com/auth/idp/k8sIdp/.well-known/openid-configuration" with error:
Failed reading response bytes from server.
E0516 08:24:38.446504 65 oidc_client.cc:223] Failed to fetch the JWKs URI
"https://oidc.idp.cloud.example.com/auth/idp/k8sIdp/certs" with error:
Failed reading response bytes from server.
이러한 네트워크 오류는 다음 방법 중 하나로 로그에 표시될 수 있습니다.
로그에 희소하게 표시됨: 희소한 오류는 주요 문제가 아닐 수 있으며 간헐적인 네트워크 문제일 수 있습니다.
GKE Identity Service OIDC 플러그인에는 5초마다 주기적으로 OIDC 검색 URL을 동기화하는 데몬 프로세스가 있습니다. 네트워크 연결이 불안정하면 이 이그레스 요청이 실패할 수 있습니다. 비정기적인 실패는 OIDC 인증에 영향을 주지 않습니다. 캐시 처리된 기존 데이터를 재사용할 수 있습니다.
로그에 희소한 오류가 있으면 추가 문제 해결 단계를 계속 진행합니다.
로그에 계속 표시되거나 GKE Identity Service가 잘 알려진 엔드포인트에 성공적으로 도달하지 못함: 이러한 지속적인 문제는 GKE Identity Service와 OIDC ID 공급업체 간 연결에 문제가 있음을 나타냅니다.
다음 문제 해결 단계는 이러한 연결 문제를 진단하는 데 도움이 될 수 있습니다.
- 방화벽에서 GKE Identity Service의 아웃바운드 요청을 차단하지 않는지 확인합니다.
- ID 공급업체 서버가 올바르게 실행 중인지 확인합니다.
ClientConfig리소스의 OIDC 발급기관 URL이 올바르게 구성되었는지 확인합니다.ClientConfig리소스에서 프록시 필드를 사용 설정한 경우 이그레스 프록시 서버의 상태나 로그를 검토합니다.- GKE Identity Service 포드와 OIDC ID 공급업체 서버 간의 연결을 테스트합니다.
서버에 로그인된 상태여야 함(승인되지 않음)
OIDC 인증을 사용하여 로그인하려고 하면 다음 오류 메시지가 표시될 수 있습니다.
You must be logged in to the server (Unauthorized)
이 오류는 추가 정보가 제공되지 않는 일반적인 Kubernetes 인증 문제입니다. 하지만 이 오류는 구성 문제를 나타냅니다.
문제를 확인하려면 이전 섹션인 클러스터의 OIDC 사양 확인 및 ClientConfig 리소스 구성을 참조하세요.
웹훅 인증자를 요청할 수 없음
GKE Identity Service 로그에 다음 오류가 표시될 수 있습니다.
E0810 09:58:02.820573 1 webhook.go:127] Failed to make webhook authenticator request:
error trying to reach service: net/http: TLS handshake timeout
이 오류는 API 서버에서 GKE Identity Service 포드와의 연결을 설정할 수 없음을 나타냅니다.
외부에서 GKE Identity Service 엔드포인트에 연결할 수 있는지 확인하려면 다음
curl명령어를 실행합니다.curl -k -s -o /dev/null -w "%{http_code}" -X POST \ https://APISERVER_HOST/api/v1/namespaces/anthos-identity-service/services/https:ais:https/proxy/authenticate -d '{}'APISERVER_HOST를 API 서버 주소로 바꿉니다.예상되는 응답은
HTTP 400상태 코드입니다. 요청 시간이 초과되면 GKE Identity Service 포드를 다시 시작합니다. 오류가 계속되는 경우 GKE Identity Service HTTP 서버가 시작되지 않음을 의미합니다. 추가 지원이 필요하면 Google Cloud 지원팀에 문의하세요.
로그인 URL을 찾을 수 없음
Google Cloud 콘솔에서 ID 공급업체에 연결할 수 없는 경우 다음과 같은 문제가 발생합니다. 로그인 시도가 URL not found 오류가 있는 페이지로 리디렉션됩니다.
이 문제를 해결하려면 다음 문제 해결 단계를 검토합니다. 각 단계 후에 다시 로그인해보세요.
ID 공급업체가 공개 인터넷을 통해 연결할 수 없는 경우 OIDC HTTP 프록시를 사용 설정하여 Google Cloud 콘솔을 사용해 로그인합니다.
ClientConfig커스텀 리소스를 수정하고useHTTPProxy를true로 설정합니다.kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIGUSER_CLUSTER_KUBECONFIG를 사용자 클러스터 kubeconfig 파일의 경로로 바꿉니다.HTTP 프록시가 사용 설정된 상태에서도 여전히 이 오류가 발생하면 프록시 시작에 문제가 있을 수 있습니다. 프록시 로그를 봅니다.
kubectl logs deployment/clientconfig-operator -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIGUSER_CLUSTER_KUBECONFIG를 사용자 클러스터 kubeconfig 파일의 경로로 바꿉니다.ID 공급업체에 잘 알려진 CA가 있더라도 성공적으로 시작하려면 HTTP 프록시의
ClientConfig커스텀 리소스에oidc.caPath값을 제공해야 합니다.승인 서버가 동의를 요청하지만
extraparamprompt=consent매개변수를 표함하고 있지 않은 경우ClientConfig커스텀 리소스를 추가하고prompt=consent를extraparams매개변수에 추가합니다.kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIGUSER_CLUSTER_KUBECONFIG를 사용자 클러스터 kubeconfig 파일의 경로로 바꿉니다.스토리지 서비스에서 구성 설정이 변경되면 기존 세션에서 명시적으로 로그아웃해야 할 수 있습니다. Google Cloud 콘솔에서 클러스터 세부정보 페이지로 이동하고 로그아웃을 선택합니다.
LDAP 문제 해결
LDAP 인증에 문제가 있는 경우 적절한 구성 문서 중 하나를 수행하여 환경을 설정했는지 확인합니다.
또한 LDAP 서비스 계정 보안 비밀을 채우고 LDAP 인증을 사용 설정하도록 ClientConfig 리소스를 구성했는지 확인해야 합니다.
ID 로그와 테스트 연결을 사용 설정하고 검토하는 방법은 GKE Identity Service ID 공급업체 문제 해결 가이드를 참조하세요. GKE Identity Service가 예상대로 작동하는지 확인하거나 문제를 식별한 후에 다음 LDAP 문제 해결 정보를 검토하세요.
LDAP 인증이 사용 설정되어 있는지 확인
LDAP 인증을 테스트하기 전에 LDAP 인증이 클러스터에 사용 설정되어 있는지 확인합니다.
다음과 같이 GKE Identity Service 로그를 검사합니다.
kubectl logs -l k8s-app=ais -n anthos-identity-service다음 출력 예시에서는 LDAP 인증이 올바르게 사용 설정되었음을 보여줍니다.
... I1012 00:14:11.282107 34 plugin_list.h:139] LDAP[0] started. ...LDAP 인증이 올바르게 사용 설정되지 않으면 다음 예시와 비슷한 오류가 표시됩니다.
Failed to start the LDAP_AUTHENTICATION[0] authentication method with error:보고된 특정 오류를 검토하고 수정해 보세요.
LDAP 인증 테스트
LDAP 기능을 사용하려면 UI 및 브라우저가 사용 설정된 워크스테이션을 사용합니다. 텍스트 기반 SSH 세션에서는 이러한 단계를 수행할 수 없습니다. LDAP 인증이 클러스터에서 올바르게 작동하는지 테스트하려면 다음 단계를 완료합니다.
- Google Cloud CLI를 다운로드합니다.
로그인 구성 파일을 생성하려면 다음 gcloud anthos create-login-config 명령어를 실행합니다.
gcloud anthos create-login-config \ --output user-login-config.yaml \ --kubeconfig KUBECONFIGKUBECONFIG를 사용자 클러스터 kubeconfig 파일의 경로로 바꿉니다.사용자를 인증하려면 다음 명령어를 실행합니다.
gcloud anthos auth login --cluster CLUSTER_NAME \ --login-config user-login-config.yaml \ --kubeconfig AUTH_KUBECONFIG다음을 바꿉니다.
CLUSTER_NAME을 연결할 사용자 클러스터의 이름으로 바꿉니다.AUTH_KUBECONFIG를 클러스터에 액세스할 수 있는 사용자 인증 정보가 포함된 새 kubeconfig 파일로 바꿉니다. 자세한 내용은 클러스터에 인증을 참조하세요.
로컬 워크스테이션의 기본 웹브라우저에서 로그인 동의 페이지가 열립니다. 이 로그인 프롬프트에서 사용자에게 유효한 인증 정보를 제공합니다.
이전 로그인 단계를 성공적으로 완료하면 현재 디렉터리에 kubeconfig 파일이 생성됩니다.
사용자 인증 정보가 포함된 새 kubeconfig 파일을 테스트하려면 사용자 클러스터의 포드를 나열합니다.
kubectl get pods --kubeconfig AUTH_KUBECONFIGAUTH_KUBECONFIG를 이전 단계에서 생성된 사용자 클러스터 kubeconfig 경로로 바꿉니다.
Error from server (Forbidden): pods is forbidden: User "XXXX" cannot list resource "pods" in API group "" at the cluster scope
일반적인 LDAP 문제
LDAP 인증에 문제가 있으면 다음과 같은 일반적인 문제를 검토합니다. 문제를 해결하는 방법에 대한 안내를 수행합니다.
사용자가 CN의 쉼표로 인해 인증할 수 없음
LDAP를 사용할 때 CN에 쉼표가 포함된 경우(예: CN="a,b") 사용자가 인증할 수 없는 문제가 발생할 수 있습니다. GKE Identity Service에 디버깅 로그를 사용 설정하면 다음 오류 메시지가 보고됩니다.
I0207 20:41:32.670377 30 authentication_plugin.cc:977] Unable to query groups from the LDAP server directory.example.com:636, using the LDAP service account
'CN=svc.anthos_dev,OU=ServiceAccount,DC=directory,DC=example,DC=com'.
Encountered the following error: Empty entries.
이 문제는 GKE Identity Service LDAP 플러그인이 쉼표를 이중으로 이스케이프 처리하기 때문에 발생합니다. 이 문제는 Google Distributed Cloud 1.13 이하 버전에서만 발생합니다.
이 문제를 해결하려면 다음 단계 중 하나를 완료하세요.
- 클러스터를 Google Distributed Cloud 1.13 이상으로 업그레이드합니다.
- CN을 사용하는 대신
sAMAccountName과 같은 다른identifierAttribute를 선택합니다. - LDAP 디렉터리의 CN 내에서 쉼표를 삭제합니다.
Google Cloud CLI 1.4.2에서 인증 실패
Google Cloud CLI anthos-auth 1.4.2를 사용하면 gcloud anthos auth login 명령어를 실행할 때 다음 오류 메시지가 표시될 수 있습니다.
Error: LDAP login failed: could not obtain an STS token: Post "https://127.0.0.1:15001/sts/v1beta/token":
failed to obtain an endpoint for deployment anthos-identity-service/ais: Unauthorized
ERROR: Configuring Anthos authentication failed
GKE Identity Service 로그에 다음 오류도 표시됩니다.
I0728 12:43:01.980012 26 authentication_plugin.cc:79] Stopping STS authentication, unable to decrypt the STS token:
Decryption failed, no keys in the current key set could decrypt the payload.
이 오류를 해결하려면 다음 단계를 수행합니다.
Google Cloud CLI
anthos-auth버전 1.4.2를 사용하는지 확인합니다.gcloud anthos auth version다음 예시 출력에서는 버전이 1.4.2임을 보여줍니다.
Current Version: v1.4.2Google Cloud CLI
anthos-auth버전 1.4.2를 실행하는 경우 버전 1.4.3 이상으로 업그레이드합니다.
일반적인 문제
이 섹션에서는 일반적인 인증 문제와 해결 방법을 자세히 설명합니다.
SSH 키 permission denied 오류로 인해 관리자 워크스테이션에 대한 액세스 상실
관리자 워크스테이션에 연결을 시도하고 다음 예시와 비슷한 "Permission denied" 메시지가 수신되면 다음 오류가 발생합니다.
Authorized users only. All activity may be monitored and reported.
TARGET_MACHINE: Permission denied (publickey).
이 오류는 SSH를 사용하여 관리자 워크스테이션에 연결할 때 잘못된 비공개 키를 사용하거나 키를 사용하지 않았기 때문에 발생합니다.
이 문제를 해결하려면 올바른 SSH 키를 찾아서 사용하세요. 올바른 SSH 키를 찾을 수 없으면 다음 단계를 사용하여 관리자 워크스테이션에 새 SSH 키 쌍을 생성합니다.
임시 복구 VM을 만듭니다. 이 복구 VM은 현재 관리자 워크스테이션 VM과 동일한 네트워크 및 Datastore에 연결되어야 합니다.
관리자 워크스테이션 VM 및 복구 VM을 종료합니다.
관리자 워크스테이션 VM의 데이터 디스크를 복구 VM에 연결합니다. 데이터 디스크는 부팅 디스크와 구분되는 관리자 워크스테이션 구성 파일에서 다른 디스크 크기를 지정하지 않는 한 일반적으로 512MB입니다.
복구 VM의 전원을 켭니다.
SSH를 사용하여 복구 VM에 연결합니다.
로컬 컴퓨터에서 새 SSH 키 쌍을 생성합니다.
로컬 컴퓨터에서
ssh-copy-id명령어를 사용하여 새 SSH 공개 키를 복구 VM에 복사합니다.ssh-copy-id -i ~/.ssh/NEW_SSH_KEY ubuntu@RESCUE_VM다음을 바꿉니다.
NEW_SSH_KEY를 이전 단계에서 만든 새 SSH 키의 이름으로 바꿉니다.RESCUE_VM을 복구 VM의 IP 주소 또는 FQDN으로 바꿉니다.
복구 VM에서 데이터 디스크를 복구 VM에 마운트합니다.
sudo mkdir -p /mnt/ext-disk sudo mount DEVICE /mnt/ext-diskDEVICE를 자체 디스크 고유 식별자(예:/dev/sdb1)로 바꿉니다.복구 VM에서 관리 워크스테이션 VM의 마운트된 데이터 디스크에 있는
authorized_keys파일에 새 SSH 공개 키를 복사합니다.이전 단계의
ssh-copy-id명령어를 사용하여 복사한 새 SSH 공개 키가 포함된 복구 VM의authorized_keys파일 콘텐츠를 확인합니다.ls ~/.ssh/authorized_keysauthorized_keys파일에서 최신 SSH 공개 키 항목을 복사한 후 파일을 닫습니다.관리 워크스테이션 VM에서 마운트된 데이터 디스크의
authorized_keys파일을 수정합니다.vi /mnt/ext-disk/.ssh/authorized_keys복구 VM의
authorized_keys파일에서 SSH 공개 키의 콘텐츠를 붙여넣습니다.관리 워크스테이션 VM에서 마운트된 데이터 디스크의
authorized_keys파일을 저장하고 닫습니다./mnt/ext-disk/.ssh/의 파일에 올바른 권한이 적용되었는지 확인합니다.chown -R ubuntu /mnt/ext-disk/.ssh/* chmod -R 600 /mnt/ext-disk/.ssh/*복구 VM에 대한 SSH 연결을 종료합니다.
복구 VM을 종료합니다.
복구 VM에서 데이터 디스크를 분리하고 디스크를 관리 워크스테이션 VM에 다시 연결합니다.
관리자 워크스테이션의 전원을 켭니다.
VM이 성공적으로 실행되면 SSH 및 새 SSH 키 쌍을 사용하여 관리 워크스테이션에 연결합니다.
ssh -i ~/.ssh/NEW_SSH_KEY ubuntu@ADMIN_VM다음을 바꿉니다.
NEW_SSH_KEY를 이전 단계에서 만들고 관리자 워크스테이션 VM에 복사한 새 SSH 키의 이름으로 바꿉니다.RESCUE_VM을 관리 워크스테이션 VM의 IP 주소 또는 FQDN으로 바꿉니다.
SSH를 통해 성공적으로 연결할 수 있는지 확인합니다.
복구 VM을 삭제합니다.