OpenID Connect(OIDC)로 인증

사용자 및 관리자 클러스터 인증에 OpenID Connect(OIDC)를 사용하도록 VMware용 Anthos 클러스터(GKE On-Prem)를 구성하는 방법을 알아봅니다. 이 페이지에서는 일반적으로 OpenID 제공업체를 구성하는 방법을 설명합니다.

VMware용 Anthos 클러스터 인증 흐름의 개요는 인증을 참조하세요. 다른 OpenID 제공업체를 통해 OIDC를 구성하는 방법은 다음 리소스를 참조하세요.

• OIDC 및 Active Directory Federation Services(AD FS)로 인증
• OIDC 및 Google로 인증

VMware용 Anthos 클러스터는 사용자 또는 관리자 클러스터의 Kubernetes API 서버와 상호작용하는 인증 메커니즘 중 하나로 OIDC를 지원합니다. OIDC를 사용하면 조직에서 사용자 계정을 만들고, 사용 설정하고, 사용 중지하기 위한 표준 절차에 따라 Kubernetes 클러스터에 대한 액세스를 관리할 수 있습니다.

사용자가 계정을 승인하는 방법에는 두 가지가 있습니다.

• Google Cloud CLI를 사용하여 OIDC 절차를 시작하고 브라우저 기반 동의 페이지를 통해 사용자 승인을 가져옵니다.

• Google Cloud 콘솔을 사용하여 OIDC 인증 절차를 시작합니다.

시작하기 전에

• 이 주제에서는 다음 인증과 OpenID 개념에 익숙하다고 가정합니다.

  • OAuth 2.0
  • OpenID Connect
  • 범위
  • 클레임

• 헤드리스 시스템은 지원되지 않습니다. 브라우저 기반 인증 흐름은 사용자 동의를 구하고 사용자 계정을 승인하는 데 사용됩니다.

• Google Cloud 콘솔을 통해 인증하려면 OIDC 인증을 위해 구성하려는 각 클러스터가 Google Cloud에 등록되어야 합니다.

캐릭터

이 주제에서는 세 가지 캐릭터를 기준으로 설명합니다.

• 조직 관리자: 이 사람은 OpenID 제공업체를 선택하고 클라이언트 애플리케이션을 제공업체에 등록합니다.

• 클러스터 관리자. 이 사람은 클러스터를 만들고, 클러스터를 사용하는 관리자 및 개발자를 위한 인증 구성 파일을 만듭니다.

• 개발자: 이 사람은 한 개 이상의 클러스터에서 워크로드를 실행하고 OIDC를 사용하여 인증합니다.

OpenID 제공업체 선택

이 섹션은 조직 관리자를 위한 것입니다.

선택한 OpenID 제공업체를 사용할 수 있습니다. 인증된 제공업체 목록은 OpenID 인증을 참조하세요.

다음 OpenID 제공업체의 경우 다음 리소스의 특정 구성 단계를 참조하세요.

• Active Directory Federated Services

• Google

리디렉션 URL 만들기

이 섹션은 조직 관리자를 위한 것입니다.

리디렉션 URL은 OpenID 제공업체가 ID 토큰을 반환하는 데 사용할 수 있는 gcloud CLI와 Google Cloud 콘솔입니다.

gcloud CLI 리디렉션 URL

Google Cloud CLI는 각 개발자의 로컬 머신에 설치됩니다. 리디렉션 URL에 사용할 포트 번호를 1024보다 큰 번호로 지정할 수 있습니다.

http://localhost:PORT/callback

PORT를 포트 번호로 바꿉니다.

OpenID 제공업체를 구성할 때 http://localhost:PORT/callback을 리디렉션 URL 중 하나로 지정합니다. 방법은 제공업체에 따라 다릅니다.

Google Cloud 콘솔 리디렉션 URL

Google Cloud 콘솔의 리디렉션 URL은 다음과 같습니다.

https://console.cloud.google.com/kubernetes/oidc

OIDC 제공업체를 구성할 때 https://console.cloud.google.com/kubernetes/oidc을 리디렉션 URL 중 하나로 지정합니다. 방법은 제공업체에 따라 다릅니다.

OpenID 제공업체에 클라이언트 애플리케이션 등록

이 섹션은 조직 관리자를 위한 것입니다.

개발자가 OpenID 제공업체에서 gcloud CLI 또는 Google Cloud 콘솔을 사용하려면 먼저 OpenID 제공업체에 두 클라이언트를 등록해야 합니다. 등록 절차는 다음과 같습니다.

• 제공업체의 발급기관 URI를 알아봅니다. 여기서 gcloud CLI 또는 Google Cloud 콘솔이 인증 요청을 보냅니다.

• 제공업체에 gcloud CLI의 리디렉션 URL을 제공합니다.

• 제공업체에 Google Cloud 콘솔의 리디렉션 URL을 제공합니다. https://console.cloud.google.com/kubernetes/oidc입니다.

• 단일 클라이언트 ID를 설정합니다. 이는 제공업체에서 gcloud CLI 및 Google Cloud 콘솔을 모두 식별하는 데 사용하는 ID입니다.

• 단일 클라이언트 보안 비밀번호를 설정합니다. gcloud CLI 및 Google Cloud 콘솔 모두 이 보안 비밀번호를 사용하여 OpenID 제공업체에 인증합니다.

• gcloud CLI 또는 Google Cloud 콘솔이 사용자의 보안 그룹을 요청하는 데 사용할 수 있는 커스텀 범위를 설정합니다.

• 제공업체가 사용자의 보안 그룹을 반환하는 데 사용할 커스텀 클레임 이름을 설정합니다.

이 단계를 수행하는 방법은 OpenID 제공업체에 따라 다릅니다.

클러스터에서 oidc 구성

이 섹션은 클러스터 관리자를 위해 작성되었습니다.

OIDC 인증을 구성하려면 클러스터의 인증 세부정보로 클러스터의 ClientConfig CRD를 구성해야 합니다. 이렇게 하려면 kube-public 네임스페이스에서 clientconfig 유형의 KRM 기본 객체를 수정합니다. 조직의 요구사항에 따라 관리자 및 사용자 클러스터에 서로 다른 구성을 적용하거나 동일한 구성을 사용할 수 있습니다.

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

ClientConfig CRD의 세부정보는 Google Cloud 콘솔과 Anthos용 인증 플러그인 모두에 대해 OIDC를 구성하는 데 사용됩니다. 구성에는 다음 OIDC 정보가 포함됩니다.

authentication:
  - name: NAME_STRING
    oidc:
      certificateAuthorityData: CERTIFICATE_STRING
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      cloudConsoleRedirectURI: "http://console.cloud.google.com/kubernetes/oidc"
      deployCloudConsoleProxy: PROXY_BOOLEAN
      enableAccessToken: ENABLE_ACCESS_TOKEN
      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 객체의 필드를 설명합니다.

필드	필수	설명	형식
name	예	만들려는 OIDC 구성의 이름입니다.	문자열
certificateAuthorityData	아니요	OIDC 제공업체의 base64로 인코딩된 PEM 인코딩 인증서입니다. 문자열을 만들려면 헤더를 포함한 인증서를 base64로 인코딩합니다. certificateAuthorityData에 결과 문자열을 단일 줄로 포함합니다. 예시: certificateAuthorityData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tC...k1JSUN2RENDQWFT==	문자열
clientID	예	OpenID 제공업체에 인증을 요청하는 클라이언트 애플리케이션의 ID입니다.	문자열
clientSecret	아니요	OIDC 클라이언트 애플리케이션과 OIDC 제공업체 간에 공유된 보안 비밀입니다.	문자열
deployCloudConsoleProxy	아니요	Google Cloud 콘솔이 인터넷을 통해 공개적으로 액세스할 수 없는 온프레미스 ID 공급업체에 연결할 수 있게 해주는 프록시가 배포되었는지 여부를 지정합니다. 기본적으로 false로 설정됩니다.	부울
enableAccessToken	아니요	사용 설정된 경우 Anthos Identity Service는 사용자가 명령줄에서 로그인할 때 ID 공급업체의 사용자 정보 엔드포인트를 사용하여 그룹 정보를 가져올 수 있습니다. 이렇게 하면 이 엔드포인트에서 그룹 클레임을 제공하는 제공업체(예: Okta)가 있을 때 승인을 위해 보안 그룹을 사용할 수 있습니다. 설정하지 않은 경우 false로 간주됩니다.	부울
extraParams	아니요	OpenID 제공업체에 전송할 추가적인 키-값 매개변수입니다. 그룹을 승인하는 경우 resource=token-groups-claim를 전달합니다. 승인 서버가 Microsoft Azure 및 Okta의 인증 동의를 요청하면 extraParams를 prompt=consent로 설정합니다. Cloud ID의 경우 extraParams를 prompt=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.입니다.	문자열

예시: 사용자 및 그룹 승인

대부분의 제공업체는 이메일 및 사용자 ID와 같은 사용자 식별 속성을 토큰에 인코딩합니다. 그러나 다음 속성은 인증 정책에 암시적 위험이 있습니다.

• 사용자 ID는 정책을 읽고 감사하기 어렵게 만들 수 있습니다.

• 이메일로 인해 가용성 위험(사용자가 기본 이메일을 변경하는 경우) 및 잠재적 보안 위험(이메일을 다시 할당할 수 있는 경우)이 생길 수 있습니다.

따라서 그룹 ID는 영구적이고 감사하기 쉬울 수 있으므로 그룹 정책을 사용하는 것이 좋습니다.

제공업체에서 다음 필드를 포함하는 ID 토큰을 생성한다고 가정합니다.

{
  'iss': 'https://server.example.com'
  'sub': 'u98523-4509823'
  'groupList': ['[e-mail]', '[e-mail]']
  ...
}

이 토큰 형식을 사용하면 다음과 같이 구성 파일의 oidc 사양을 채웁니다.

issuerURL: 'https://server.example.com'
userClaim: 'sub'
usernamePrefix: 'uid-'
groupClaim: 'groupList'
groupPrefix: 'gid-'
extraParams: 'resource=token-groups-claim'
...

클러스터를 만든 후 Kubernetes 역할 기반 액세스 제어(RBAC)를 사용하여 인증된 사용자에게 액세스 권한을 부여할 수 있습니다. 예를 들어 사용자에게 클러스터의 보안 비밀에 대한 읽기 전용 액세스 권한을 부여하는 ClusterRole을 만들고, ClusterRoleBinding 리소스를 만들어 인증된 그룹에 역할을 바인딩할 수 있습니다.

ClusterRole

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-reader
rules:
- apiGroups: [""]
  # The resource type for which access is granted
  resources: ["secrets"]
  # The permissions granted by the ClusterRole
  verbs: ["get", "watch", "list"]

ClusterRoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-secrets-admins
subjects:
  # Allows anyone in the "us-east1-cluster-admins" group to
  # read Secrets in any namespace within this cluster.
- kind: Group
  name: gid-us-east1-cluster-admins # Name is case-sensitive
  apiGroup: rbac.authorization.k8s.io
  # Allows this specific user to read Secrets in any
  # namespace within this cluster
- kind: User
  name: uid-u98523-4509823
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

참고: OIDC 제공업체가 이중 백슬래시 문자가 포함된 그룹 이름을 반환하는 경우 ClusterRoleBinding 리소스에서 그룹 이름을 참조할 때 백슬래시 문자 중 하나를 생략해야 합니다. 예를 들어 이름이 corp\\my-group인 그룹을 만든 경우 ClusterRoleBinding 리소스에서 그룹을 corp\my-group으로 참조합니다. 첫 번째 백슬래시 문자가 이스케이프 문자로 처리되기 때문입니다.

인증 구성 파일 만들기 및 배포

이 섹션은 클러스터 관리자를 위해 작성되었습니다.

사용자 클러스터를 만든 후 클러스터의 인증 구성 파일을 만듭니다. 단일 인증 구성 파일에서 여러 클러스터를 구성할 수 있습니다. 인증 구성 파일을 각 클러스터에서 인증하려는 사용자에게 제공해야 합니다.

인증 구성 파일 만들기

현재 디렉터리에 인증 구성 파일을 만들려면 다음 gkectl 명령어를 실행합니다.

gkectl create-login-config --kubeconfig USER_CLUSTER_KUBECONFIG

USER_CLUSTER_KUBECONFIG를 사용자 클러스터의 kubeconfig 파일 경로로 바꿉니다. gkectl create cluster를 실행하여 사용자 클러스터를 만들었으면 kubeconfig 파일이 생성됩니다.

결과: kubectl-anthos-config.yaml이라는 인증 구성 파일이 현재 디렉터리에 생성됩니다.

인증 구성 파일에 여러 클러스터 추가

단일 인증 구성 파일에 있는 여러 클러스터의 인증 구성 세부정보를 저장할 수 있습니다.

다음 명령어를 사용하여 추가 사용자 클러스터 인증 세부정보를 기존 인증 구성 파일에 병합할 수 있습니다. 기존 인증 구성 파일이 제공되면 추가 사용자 클러스터 인증 세부정보를 병합하거나 결합할 수 있습니다.

• 추가 사용자 클러스터 인증 세부정보를 기존 인증 구성 파일에 병합합니다.
• 추가 사용자 클러스터 인증 세부정보를 새 파일에 결합합니다.

예를 들어 anthos-config-1cluster.yaml 및 anthos-config-3clusters.yaml 인증 구성 파일을 모두 관리하여 조직의 여러 사용자 그룹에 대한 액세스 요구사항을 수용해야 할 수 있습니다.

기존 인증 구성 파일에 사용자 클러스터를 추가하려면 다음 안내를 따르세요.

1. 각 클러스터에 고유한 이름이 있는지 확인합니다. 클러스터 이름이 동일한 경우 이름을 동일한 인증 구성 파일에 결합할 수 없습니다. 클러스터를 만든 후에는 클러스터 이름을 변경할 수 없습니다.

2. 다음 gkectl 명령어를 실행하여 구성 세부정보를 병합하거나 결합합니다.

   gkectl create-login-config --kubeconfig USER_CLUSTER_KUBECONFIG \
   --merge-from IN_AUTH_CONFIG_FILE --output OUT_AUTH_CONFIG_FILE

   다음을 바꿉니다.

   • USER_CLUSTER_KUBECONFIG는 추가할 사용자 클러스터의 kubeconfig 파일을 지정합니다.

   • IN_AUTH_CONFIG_FILE은 추가 클러스터 정보와 병합할 기존 인증 구성 파일의 경로를 지정합니다.

   • OUT_AUTH_CONFIG_FILE은 병합된 인증 구성을 저장할 파일의 경로를 지정합니다.

     • IN_AUTH_CONFIG_FILE과 동일한 파일을 지정하여 추가 클러스터 정보를 기존 파일에 병합합니다.
     • 인증 구성 세부정보를 새 파일에 결합하도록 새 경로와 파일 이름을 지정합니다.

인증 구성 파일 배포

사용자가 사용자 클러스터를 인증할 수 있도록 하려면 개발자가 만든 인증 구성 파일 중 하나 이상에 대한 액세스 권한을 사용자에게 제공해야 합니다. 다음 단계에서는 기본 파일 이름과 gcloud CLI에서 예상하는 위치를 사용합니다. 대체 파일 이름과 위치 사용에 대한 자세한 내용은 커스텀 구성을 참조하세요.

다음과 같은 방법으로 인증 구성 파일을 배포하는 것이 좋습니다.

• 액세스 가능한 URL에 파일을 호스팅합니다. gcloud anthos auth login 명령어에 --login-config 플래그를 포함하면 gcloud CLI가 해당 위치에서 인증 구성 파일을 가져옵니다.

  보안 호스트에 파일을 호스팅하는 것이 좋습니다. 보안 HTTPS 액세스에 PEM 인증서를 사용하는 방법에 대한 자세한 내용은 gcloud CLI의 --login-config-cert 플래그를 참조하세요.

• 각 사용자에게 수동으로 파일을 제공합니다. 사용자가 파일을 다운로드한 후에는 기본 위치에 파일을 저장하는 방법과 gcloud CLI에서 예상하는 기본 파일 이름을 알려야 합니다.

  예를 들어 사용자는 다음 명령어를 실행하여 기본 kubectl-anthos-config.yaml 파일 이름과 기본 위치에 인증 구성 파일을 저장할 수 있습니다.

  Linux

  mkdir -p  $HOME/.config/google/anthos/
  cp AUTH_CONFIG_FILE $HOME/.config/google/anthos/kubectl-anthos-config.yaml

  여기서 AUTH_CONFIG_FILE은 인증 구성 파일의 이름입니다. 예를 들면 kubectl-anthos-config.yaml입니다.

  macOS

  mkdir -p  $HOME/Library/Preferences/google/anthos/
  cp AUTH_CONFIG_FILE $HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml

  여기서 AUTH_CONFIG_FILE은 인증 구성 파일의 이름입니다. 예를 들면 kubectl-anthos-config.yaml입니다.

  Windows

  md "%APPDATA%\google\anthos"
  copy AUTH_CONFIG_FILE "%APPDATA%\google\anthos\kubectl-anthos-config.yaml"

  여기서 AUTH_CONFIG_FILE은 인증 구성 파일의 이름입니다. 예를 들면 kubectl-anthos-config.yaml입니다.

• 내부 도구를 사용하여 인증 구성 파일을 각 사용자 머신으로 푸시합니다. 예를 들어 도구를 사용하면 기본 kubectl-anthos-config.yaml 파일 이름을 사용하여 파일을 각 사용자 머신의 기본 위치로 푸시할 수 있습니다.

  Linux

  $HOME/.config/google/anthos/kubectl-anthos-config.yaml

  macOS

  $HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml

  Windows

  %APPDATA%\google\anthos\kubectl-anthos-config.yaml

커스텀 구성

gcloud CLI에서는 인증 구성 파일이 기본 위치에 저장되고 이전 섹션에서 언급된 기본 파일 이름인 kubectl-anthos-config.yaml일 것으로 예상합니다. 하지만 인증 구성 파일의 이름을 바꾸거나 대체 위치에 이 파일을 저장할 수 있습니다. 파일 이름과 위치가 기본값과 다른 경우 클러스터로 인증할 때 실행하는 각 명령어에 --login-config 플래그를 추가해야 합니다. 추가 명령어 플래그는 커스텀 경로와 파일 이름을 전달합니다. 명령어 플래그에 대한 자세한 내용은 gcloud CLI를 통해 인증을 참조하세요.

gcloud CLI 설치

이 섹션은 클러스터 관리자 및 개발자를 위해 작성되었습니다.

클러스터를 인증해야 하는 각 개발자나 사용자는 자체 머신에 Google Cloud CLI를 설치해야 합니다. Anthos 인증 명령어는 gcloud CLI에 anthos-auth 구성요소로 통합되었습니다.

• 이전 버전의 'Kubectl용 Anthos 플러그인'이 있으면 gcloud CLI와 anthos-auth 구성요소를 설치하기 전에 플러그인을 제거해야 합니다.

• 기존 버전의 gcloud CLI가 있으면 최신 버전과 anthos-auth 구성요소를 설치합니다.

이전 플러그인 삭제

gcloud CLI의 anthos-auth 구성요소를 사용하려면 먼저 이전 플러그인을 제거해야 합니다. 다음 명령어를 실행하면 머신에 지난 kubectl 기반 플러그인 중 하나가 있는지 확인할 수 있습니다.

kubectl anthos version

• 명령어가 Error: unknown command "anthos" for "kubectl"에 응답하면 플러그인이 발견되지 않았으므로 다음 섹션으로 건너뛸 수 있습니다.

• 1.0beta 버전의 플러그인이 있으면 플러그인 바이너리를 찾아 삭제해야 합니다. 다음 명령어를 실행하여 위치를 나열한 후 이 위치를 사용하여 머신에서 바이너리를 삭제합니다.

  kubectl plugin list

gcloud CLI 및 gcloud CLI 설치

gcloud CLI를 설치하려면 먼저 gcloud CLI를 설치해야 합니다.

중요: VMware용 Anthos 클러스터에서 gcloud CLI를 사용하면 Google 계정이 필요하지 않습니다. 계정이 있는 경우 로그인은 선택사항이지만 gcloud init 명령어를 실행할 필요는 없습니다.

1. gcloud CLI를 설치하되 gcloud init 명령어를 건너뜁니다.

2. 다음 명령어를 실행하여 anthos-auth 구성요소를 설치합니다.

   gcloud components update
   gcloud components install anthos-auth

3. 다음 명령어 중 하나를 실행하여 gcloud CLI가 성공적으로 설치되었는지 확인합니다.

   gcloud anthos auth
   gcloud anthos auth login

   결과: 각 명령어는 필수 인수 및 사용 가능한 옵션에 대한 세부정보로 응답해야 합니다.

인증 구성 파일 가져오기

이 섹션은 개발자를 위해 작성되었습니다.

관리자는 인증 구성 파일을 만들어 개발자에게 제공해야 합니다. 자세한 내용은 인증 구성 파일 배포를 참조하세요.

기본적으로 gcloud CLI에서는 인증 구성 파일의 기본 파일 이름과 스토리지 위치를 사용합니다. 수동으로 파일을 제공했고 머신에 저장해야 하는 경우 기본값을 사용하여 gcloud 인증 명령어를 단순화합니다.

다음 명령어를 사용하여 인증 구성 파일을 기본 위치에 복사합니다.

Linux

mkdir -p  $HOME/.config/google/anthos/
cp AUTH_CONFIG_FILE $HOME/.config/google/anthos/kubectl-anthos-config.yaml

여기서 AUTH_CONFIG_FILE은 인증 구성 파일의 이름입니다. 예를 들면 kubectl-anthos-config.yaml입니다.

macOS

mkdir -p  $HOME/Library/Preferences/google/anthos/
cp AUTH_CONFIG_FILE $HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml

여기서 AUTH_CONFIG_FILE은 인증 구성 파일의 이름입니다. 예를 들면 kubectl-anthos-config.yaml입니다.

Windows

md "%APPDATA%\google\anthos"
copy AUTH_CONFIG_FILE "%APPDATA%\google\anthos\kubectl-anthos-config.yaml"

여기서 AUTH_CONFIG_FILE은 인증 구성 파일의 이름입니다. 예를 들면 kubectl-anthos-config.yaml입니다.

다른 파일 이름이나 위치를 사용하는 경우 각 인증 요청에 --login-config 플래그를 포함할 수 있습니다. gcloud anthos auth login 명령어 사용 방법에 대한 자세한 내용은 다음 섹션을 참조하세요.

사용자 클러스터로 인증

이 섹션은 개발자를 위해 작성되었습니다.

이제 머신에 gcloud CLI가 설치되고 관리자가 인증 구성 파일을 제공했으므로 gcloud CLI 또는 Google Cloud console을 사용하여 클러스터를 인증할 수 있습니다.

gcloud CLI를 통한 인증

gcloud 명령어를 실행하여 클러스터를 인증합니다.

1. gcloud anthos auth login 명령어를 실행하여 인증 절차를 시작합니다.

   gcloud anthos auth login \
    --cluster CLUSTER_NAME \
    --user USER_NAME \
    --login-config AUTH_CONFIG_FILE_PATH \
    --login-config-cert CA_CERT_PEM_FILE \
    --kubeconfig USER_CLUSTER_KUBECONFIG

   각 항목의 의미는 다음과 같습니다.

   • CLUSTER_NAME(선택사항)은 사용자 클러스터 이름을 지정합니다. 이 플래그를 생략하면 인증 구성 파일에 지정된 사용자 클러스터 중에서 선택하라는 메시지가 나타납니다.

   • USER_NAME(선택사항)은 kubeconfig 파일에 저장된 사용자 인증 정보의 사용자 이름을 지정합니다. 기본값은 CLUSTER_NAME-anthos-default-user입니다.

   • AUTH_CONFIG_FILE_PATH(선택사항)는 인증 구성 파일이 저장되거나 호스팅되는 커스텀 경로 또는 URL을 지정합니다. 파일이 기본 위치에 있으면 이 매개변수를 생략할 수 있습니다. 예를 들면 --login-config /path/to/custom/authentication-config.yaml입니다.

   • CA_CERT_PEM_FILE(선택사항)은 CA의 PEM 인증서 파일에 대한 경로를 지정합니다. 인증 구성 파일이 안전하게 호스팅되면 HTTPS 연결을 사용하여 파일에 액세스할 수 있습니다. 예를 들면 --login-config-cert my-cert.pem입니다.

   • USER_CLUSTER_KUBECONFIG(선택사항)는 사용자 클러스터의 kubeconfig 파일에 대한 커스텀 경로를 지정합니다. OpenID 제공업체에서 반환하는 OIDC ID 토큰은 kubeconfig 파일에 저장됩니다.

     kubeconfig 파일이 기본.위치 이외의 위치에 있으면 이 플래그를 사용합니다. 이 플래그를 생략하면 새 kubeconfig 파일이 기본 위치에 생성됩니다. 예를 들면 --kubeconfig /path/to/custom.kubeconfig입니다.

   예시:

   • 특정 클러스터를 인증합니다.

     gcloud anthos auth login --cluster my-production-cluster
     

   • 프롬프트를 사용하여 인증할 클러스터를 선택합니다.

     gcloud anthos auth login
     

     결과:

     Please use the --cluster flag to specify a cluster from the list below:
     Source: $HOME/.config/google/anthos/kubectl-anthos-config.yaml
     1. Cluster: test-cluster ServerIP: https://192.168.0.1:6443
     2. Cluster: test-cluster-2 ServerIP: https://192.168.0.2:6443
     3. Cluster: my-production-cluster ServerIP: https://192.168.0.3:6443
     

   • 호스팅된 인증 구성 파일을 사용합니다.

     gcloud anthos auth login \
      --cluster my-production-cluster \
      --login-config HTTPS://my-secure-server/kubectl-anthos-config.yaml \
      --login-config-cert my-cert.pem
     

2. 열려 있는 브라우저 기반 동의 화면에 사용자 인증 정보를 입력합니다.

3. 클러스터에 대한 세부정보를 검색하도록 kubectl 명령어 중 하나를 실행하여 인증이 성공했는지 확인합니다. 예를 들면 다음과 같습니다.

   kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

결과: 이제 kubeconfig 파일에 kubectl 명령어가 사용자 클러스터의 Kubernetes API 서버를 인증하는 데 사용할 ID 토큰이 포함됩니다.

SSH를 사용하여 원격 머신에서 인증

SSH를 통해 원격 머신에 연결하여 원격 머신에서 사용자 클러스터를 인증한다고 가정해 보겠습니다. 이렇게 하려면 인증 구성 파일이 원격 머신에 있어야 하며 로컬 머신에서 Open ID 제공업체에 연결할 수 있어야 합니다.

로컬 머신에서 다음 명령어를 실행합니다.

ssh USER_NAME@REMOTE_MACHINE -L LOCAL_PORT:localhost:REMOTE_PORT

각 항목의 의미는 다음과 같습니다.

• USER_NAME과 REMOTE_MACHINE은 SSH를 통해 로그인하는 데 사용되는 표준 값입니다.

• LOCAL_PORT는 원격 머신에 액세스하는 데 사용할 로컬 머신에서 선택한 공개 포트입니다.

• REMOTE_PORT는 OIDC 리디렉션 URL에 구성한 포트입니다. 인증 구성 파일의 kubectlRedirectURI 필드에서 이 포트를 확인할 수 있습니다.

SSH 셸에서 다음 명령어를 실행하여 인증을 시작합니다.

gcloud anthos auth login --login-config AUTH_CONFIG_FILE

여기서 AUTH_CONFIG_FILE은 원격 머신의 인증 구성 파일에 대한 경로입니다.

로컬 머신의 브라우저에서 http://localhost:LOCAL_PORT/login으로 이동하여 OIDC 로그인 절차를 완료합니다.

이제 원격 머신의 kubeconfig 파일에 사용자 클러스터에 액세스하는 데 필요한 토큰이 있습니다.

SSH 셸에서 사용자 클러스터에 액세스했는지 확인합니다.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get nodes

Google Cloud Console을 통한 인증

Google Cloud Console의 Kubernetes 클러스터 페이지에서 인증 절차를 시작합니다.

1. Google Cloud 콘솔을 엽니다.

   Kubernetes 클러스터 페이지로 이동

2. 목록에서 VMware용 Anthos 클러스터 클러스터를 찾은 다음 로그인을 클릭합니다.

3. 클러스터에 구성된 ID 공급업체로 인증을 선택한 후 로그인을 클릭합니다.

   ID 공급업체로 리디렉션됩니다. 여기서 계정에 액세스하는 Google Cloud console에 로그인하거나 동의해야 할 수 있습니다. 그런 다음 Google Cloud Console에서 Kubernetes 클러스터 페이지로 다시 리디렉션됩니다.

OIDC 구성 문제 해결

OIDC 문제를 해결하는 데 유용한 다음 동작과 오류를 검토합니다.

잘못된 구성

Google Cloud Console이 클러스터에서 OIDC 구성을 읽을 수 없으면 로그인 버튼이 비활성화됩니다.

잘못된 제공업체 구성

ID 공급업체 구성이 잘못된 경우 로그인을 클릭하면 ID 공급업체의 오류 화면이 표시됩니다. 공급업체별 안내에 따라 제공업체 또는 클러스터를 올바르게 구성합니다.

잘못된 권한

인증 절차를 완료했지만 클러스터의 세부정보가 여전히 표시되지 않는 경우 OIDC와 함께 사용한 계정에 올바른 RBAC 권한을 부여했는지 확인하세요. 이 계정은 Google Cloud Console에 액세스하는 계정과 다른 계정일 수 있습니다.

Error: missing 'RefreshToken' field in 'OAuth2Token' in credentials struct

승인 서버에서 동의를 요청하지만 필요한 인증 매개변수가 제공되지 않으면 이 오류가 발생할 수 있습니다. VMware용 Anthos 클러스터 구성 파일의 oidc: extraparams 필드에 prompt=consent 매개변수를 제공하고 --extra-params prompt=consent 플래그를 사용하여 클라이언트 인증 파일을 다시 생성합니다.

다음 단계

• 범위 및 클레임 자세히 알아보기