사용자 액세스 문제 해결

이 문서에서는 GKE Identity Service의 사용자 액세스 문제를 해결하는 방법을 안내합니다.

gcloud anthos create-login-config에서 clientconfig를 가져올 수 없음

이 문제는 다음 사례 중 하나에서 발생합니다.

• gcloud anthos create-login-config에 전달된 kubeconfig 파일이 잘못되었습니다.
• ClientConfig 커스텀 리소스가 클러스터에 없습니다(GKE Identity Service가 클러스터에 설치되지 않음).

오류 메시지

  failed to get clientconfig default in namespace kube-public
  

솔루션

이 문제를 해결하려면 다음 단계를 따르세요.

1. 클러스터에 올바른 kubeconfig 파일이 있는지 확인합니다.

2. ClientConfig 커스텀 리소스가 클러스터에 있는지 확인하려면 다음 명령어를 실행합니다.

   kubectl --kubeconfig KUBECONFIG  get clientconfig default -n kube-public
   

   ClientConfig가 클러스터에 없는 경우 클러스터에 GKE Identity Service를 설치하고 구성합니다. 클러스터 설정 옵션에 대한 자세한 내용은 클러스터 설정 옵션을 참조하세요.

중복 클러스터 이름으로 인해 gcloud anthos create-login-config 실패

이 문제는 클러스터의 로그인 구성이 이미 포함된 파일에 클러스터의 로그인 구성을 만들려고 하면 발생합니다.

오류 메시지

  error merging with file FILENAME because FILENAME contains a
    cluster with the same name as the one read from KUBECONFIG.
  

솔루션

이 문제를 해결하려면 --output 플래그를 사용하여 새 대상 파일을 지정합니다.

--output을 제공하지 않으면 로그인 구성 데이터가 현재 디렉터리의 kubectl-anthos-config.yaml 파일에 작성됩니다.

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 서버가 다음 이유 중 하나로 사용자를 승인할 수 없는 경우에 발생합니다.

• gcloud anthos auth login 명령어로 로그인하는 데 사용되는 구성에 오류가 있습니다.
• 필요한 RBAC 정책이 잘못되었거나 사용자에 대한 RBAC 정책이 없습니다.

오류 메시지

  Unauthorized
  

솔루션

이 문제를 해결하려면 다음 단계를 따르세요.

1. 로그인에 사용된 구성을 확인합니다.

   OIDC 구성

   사용자 클러스터 구성 파일의 authentication.oidc 섹션에는 Kubernetes API 서버에서 --oidc-group-claim 플래그와 --oidc-username-claim 플래그를 설정하는 데 사용되는 group 필드와 username 필드가 있습니다. API 서버에 사용자 ID 토큰이 있으면 토큰을 GKE Identity Service로 전달합니다. 그러면 GKE Identity Service는 추출된 group-claim 및 username-claim을 다시 API 서버로 반환합니다. API 서버에서는 응답을 사용하여 해당 그룹이나 사용자에게 올바른 권한이 있는지 확인합니다.

   클러스터 구성 파일의 authentication.oidc 섹션에서 group 및 user에 설정된 클레임이 ID 토큰에 있는지 확인합니다.

2. 적용된 RBAC 정책을 확인합니다.

   GKE Identity Service에 올바른 RBAC 정책을 설정하는 방법은 역할 기반 액세스 제어(RBAC) 설정을 참조하세요.

그룹의 RBAC가 OIDC 제공업체에서 작동하지 않음

참고 다음 문제해결 안내는 해당 제공업체가 ClientConfig 커스텀 리소스의 oidc 섹션에 구성되어 있고 enableAccessToken 필드가 false로 설정된 경우에만 적용됩니다.

1. ID 토큰에 그룹 정보가 있는지 확인

   gcloud anthos auth login 명령어를 실행하여 OIDC 인증 흐름을 시작하면 ID 토큰이 id-token 필드의 kubeconfig 파일에 저장됩니다. jwt.io를 사용하여 ID 토큰을 디코딩하고 예상대로 사용자의 그룹 정보가 포함되어 있는지 확인합니다.

2. ID 토큰에 사용자의 그룹 정보가 없으면 OIDC 제공업체의 문서에 따라 그룹 정보를 반환하도록 OIDC 제공업체를 올바르게 구성합니다. 예를 들어 Okta ID 공급업체의 OIDC 구성을 사용하는 경우 Okta ID 공급업체의 문서에 따라 ID 토큰의 그룹을 구성합니다.

3. ID 토큰에 그룹 정보가 있으면 ID 토큰의 그룹 정보 키가 oidc 섹션에서 구성된 groupsClaim 필드와 일치하는지 확인합니다.

   예를 들어 ID 토큰이 groups 키에 그룹 정보를 포함하는 경우 다음과 같습니다.

   "groups" : ["group1", "group2" ...]
   

   oidc 섹션의 groupsClaim 필드 값은 groups이어야 합니다.

   oidc 섹션에서 구성을 수정한 후 사용자 액세스 설정 및 클러스터 액세스에 나열된 안내를 다시 실행해야 합니다.

ID 공급업체 문제 해결

GKE 클러스터에서 OIDC 또는 LDAP를 사용하는 데 문제가 있는 경우 이 섹션의 단계를 수행하여 GKE Identity Service 문제를 해결하고 ID 공급업체 구성에 문제가 있는지 확인합니다.

GKE Identity Service 디버그 로그 사용 설정

클러스터에서 ID 관련 문제를 해결하려면 GKE Identity Service 디버그 로그를 사용 설정합니다.

1. kubectl patch를 사용하여 기존 클러스터를 패치합니다.

   kubectl patch deployment ais \
     -n anthos-identity-service --type=json \
     -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value":"--vmodule=cloud/identity/hybrid/charon/*=LOG_LEVEL"}]' \
     --kubeconfig KUBECONFIG
   

   다음을 바꿉니다.

   • LOG_LEVEL: 가장 자세한 로그의 경우 문제를 해결할 때 이 값을 수준 3로 설정합니다.

     참고: 이 값을 9로 더 높게 설정할 수 있지만 이 수준에서는 일부 사용자 인증 정보가 콘솔에 표시될 수 있습니다.

   • KUBECONFIG: 사용자 클러스터 kubeconfig 파일의 경로입니다.

GKE Identity Service 컨테이너 로그 확인

오류나 경고가 있는지 GKE Identity Service 컨테이너 로그의 콘텐츠를 검토합니다.

1. 로그를 검토하려면 kubectl logs를 사용합니다.

   kubectl logs -f -l k8s-app=ais \
     -n anthos-identity-service \
     --kubeconfig KUBECONFIG
   

   KUBECONFIG를 사용자 클러스터 kubeconfig 파일의 경로로 바꿉니다.

GKE Identity Service 포드 다시 시작

컨테이너 로그에 문제가 표시되면 GKE Identity Service 포드를 다시 시작합니다.

1. GKE Identity Service 포드를 다시 시작하려면 기존 포드를 삭제합니다. 자동으로 대체 새 포드가 생성됩니다.

   kubectl delete pod -l k8s-app=ais \
     -n anthos-identity-service \
     --kubeconfig KUBECONFIG
   

   KUBECONFIG를 사용자 클러스터 kubeconfig 파일의 경로로 바꿉니다.

ID 공급업체 연결 문제 해결

GKE Identity Service 포드가 올바르게 실행 중인 것으로 보이면 원격 ID 공급업체에 대한 연결을 테스트합니다.

1. GKE Identity Service 포드와 동일한 네임스페이스에서 busybox 포드를 시작합니다.

   kubectl run curl --image=radial/busyboxplus:curl \
     -n anthos-identity-service -- sleep 3000 \
     --kubeconfig KUBECONFIG
   

   KUBECONFIG를 사용자 클러스터 kubeconfig 파일의 경로로 바꿉니다.

2. 검색 URL을 가져올 수 있는지 확인하려면 busybox 포드를 실행하고 curl 명령어를 실행합니다.

   kubectl exec pod/curl -n anthos-identity-service -- \
     curl ISSUER_URL \
     --kubeconfig KUBECONFIG
   

   다음을 바꿉니다.

   • ISSUER_URL: ID 공급업체의 발급기관 URL입니다.
   • KUBECONFIG: 사용자 클러스터 kubeconfig 파일의 경로입니다.

   성공적인 응답은 자세한 ID 공급업체 엔드포인트가 포함된 JSON 결과입니다.

3. 이전 명령어에서 예상된 결과를 반환하지 않으면 ID 공급업체 관리자에게 추가 도움을 요청하세요.

LDAP 로그인이 VMware용 Anthos 관리자 클러스터에서 작동하지 않음

LDAP는 현재 VMware용 Anthos 사용자 클러스터에서만 지원됩니다.