베어메탈용 Anthos 클러스터의 OIDC 문제 해결

이 페이지에서는 베어메탈용 Anthos 클러스터의 OpenID Connect(OIDC) 문제를 식별하고 해결하는 방법을 보여줍니다.

OIDC 문제 식별

베어메탈용 Anthos 클러스터에서 OIDC가 작동하지 않는 경우 일반적으로 클러스터 구성 파일 내의 OIDC 사양이 잘못 구성되었기 때문입니다. 이 섹션에서는 OIDC 문제의 원인을 파악할 수 있도록 로그 및 OIDC 사양을 검토하는 방법을 설명합니다.

Anthos Identity Service 로그 검토

Anthos Identity 서비스는 베어메탈용 Anthos 클러스터에서 OIDC를 지원합니다.

  1. kubectl logs를 사용하여 Anthos Identity Service 로그를 출력합니다.

    kubectl --kubeconfig CLUSTER_KUBECONFIG -n anthos-identity-service logs \
    deployment/ais --all-containers=true
    
  2. 로그에서 OIDC 문제를 진단하는 데 도움이 되는 오류를 검토합니다.

    OIDC로 인증할 수 없는 경우 Anthos Identity Service 로그가 문제를 디버깅하는 데 가장 관련성이 높고 유용한 정보를 제공합니다.

    예를 들어 클러스터 구성 파일에 있는 OIDC 사양의 issuerURL 필드에 htps://accounts.google.com(https에서 't' 누락)과 같은 오타가 있는 경우 Anthos Identity Service 로그는 다음과 같은 항목을 포함됩니다.

    OIDC (htps://accounts.google.com) - Unable to fetch JWKs needed to validate OIDC ID token.
    
  3. 로그에서 구성 문제를 식별한 경우 OIDC 재구성을 진행합니다.

  4. 문제를 직접 진단하고 해결할 수 없는 경우 클라우드 고객 관리를 활용하세요.

    클라우드 고객 관리에서는 OIDC 문제를 진단하고 해결하기 위해 Anthos Identity Service 로그와 OIDC 사양을 필요로 합니다.

클러스터에서 OIDC 사양 확인

클러스터의 OIDC 정보는 kube-public 네임스페이스의 clientconfig 객체에 지정됩니다.

  1. kubectl get을 사용하여 클러스터의 OIDC 리소스를 출력합니다.

    kubectl --kubeconfig CLUSTER_KUBECONFIG -n kube-public get \
    clientconfig.authentication.gke.io default -o yaml
    
  2. 필드 값을 검토하여 사양이 OIDC 제공업체에 대해 올바르게 구성되었는지 확인합니다.

  3. 사양에서 구성 문제를 식별한 경우 OIDC 재구성을 진행합니다.

  4. 문제를 직접 진단하고 해결할 수 없는 경우 클라우드 고객 관리를 활용하세요.

    클라우드 고객 관리에서는 OIDC 문제를 진단하고 해결하기 위해 Anthos Identity Service 로그와 OIDC 사양을 필요로 합니다.

OIDC 재구성

Anthos Identity Service 로그 또는 clientconfig 객체에서 문제가 식별되면 클러스터를 다시 만들지 않고 클러스터에서 OIDC를 다시 구성하여 문제를 해결할 수 있습니다. OIDC를 다시 구성하려면 kube-public 네임스페이스에서 clientconfig 유형의 KRM 기본 객체를 수정합니다.

kubectl --kubeconfig CLUSTER_KUBECONFIG -n kube-public edit clientconfig default

ClientConfig CRD의 세부정보는 Google Cloud 콘솔과 Anthos용 인증 플러그인 모두에 대해 OIDC를 구성하는 데 사용됩니다. ClientConfig CRD에 포함된 OIDC 정보에 대한 자세한 내용은 다음 YAML 및 관련 필드 설명 표를 참조하세요.

authentication:
  - name: oidc
    oidc:
      certificateAuthorityData: CERTIFICATE_STRING
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      cloudConsoleRedirectURI: "http://console.cloud.google.com/kubernetes/oidc"
      deployCloudConsoleProxy: PROXY_BOOLEAN
      extraParams: EXTRA_PARAMS
      groupsClaim: GROUPS_CLAIM
      groupPrefix: GROUP_PREFIX
      issuerURI: ISSUER_URI
      kubectlRedirectURI: KUBECTL_REDIRECT_URI
      scopes: SCOPES
      userClaim: USER_CLAIM
      userPrefix: USER_PREFIX
    proxy: PROXY_URL

다음 표는 ClientConfig CRD oidc 객체의 필드를 설명합니다.

필드 필수 설명 형식
이름 만들려는 OIDC 구성의 이름입니다. 문자열
certificateAuthorityData 아니요

OIDC 제공업체의 base64로 인코딩된 PEM 인코딩 인증서입니다. 문자열을 만들려면 헤더를 포함한 인증서를 base64로 인코딩합니다. certificateAuthorityData에 결과 문자열을 단일 줄로 포함합니다.

예시:
certificateAuthorityData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tC...k1JSUN2RENDQWFT==

문자열
clientID OpenID 제공업체에 인증을 요청하는 클라이언트 애플리케이션의 ID입니다. 문자열
clientSecret 아니요 OIDC 클라이언트 애플리케이션과 OIDC 제공업체 간에 공유된 보안 비밀입니다. 문자열
extraParams 아니요

OpenID 제공업체에 전송할 추가적인 키-값 매개변수입니다. 그룹을 승인하는 경우 resource=token-groups-claim를 전달합니다.

승인 서버가 Microsoft Azure 및 Okta의 인증 동의를 요청하면 extraParamsprompt=consent로 설정합니다. Cloud ID의 경우 extraParamsprompt=consent,access_type=offline으로 설정합니다.

쉼표로 구분된 목록
groupsClaim 아니요 제공업체가 보안 그룹을 반환하기 위해 사용할 JWT 클레임입니다. 문자열
groupPrefix 아니요 기존 이름과 충돌을 방지하기 위해 그룹 클레임에 추가된 프리픽스입니다. 예를 들어 이름이 foobar인 그룹이 2개 있는 경우 gid- 프리픽스를 추가합니다. 결과 그룹은 gid-foobar입니다. 문자열
issuerURI 승인 요청이 OpenID로 전송되는 URL입니다(예: https://example.com/adfs). Kubernetes API 서버는 이 URL을 사용하여 토큰을 확인할 수 있도록 공개 키를 검색합니다. URI는 HTTPS를 사용해야 합니다. URL 문자열
kubectlRedirectURI 승인을 위해 kubectl에서 사용하는 리디렉션 URL입니다. URL 문자열
scopes OpenID 제공업체에 전송할 추가적인 범위입니다. Microsoft Azure 및 Okta에는 offline_access 범위가 필요합니다. 쉼표로 구분된 목록
userClaim 아니요 사용자 이름으로 사용할 JWT 클레임입니다. OpenID 제공업체에 따라 이메일 또는 이름과 같은 다른 클레임을 선택할 수 있습니다. 하지만 이메일 이외의 클레임은 이름 충돌을 방지하기 위해 발급기관 URL이 프리픽스로 추가됩니다. 문자열
userPrefix 아니요 기존 이름과 충돌하지 않도록 사용자 이름 클레임에 추가되는 프리픽스입니다. 문자열
proxy 아니요 해당되는 경우 auth 메서드에 사용할 프록시 서버입니다. 예를 들면 http://user:password@10.10.10.10:8888.입니다. 문자열