이 문서에서 설명하는 제품인 AWS용 Anthos 클러스터(이전 세대)가 이제 유지보수 모드로 제공됩니다. 모든 신규 설치는 현재 세대 제품인 AWS용 Anthos 클러스터를 사용해야 합니다.

OpenID Connect(OIDC)로 인증

사용자 클러스터 인증에 OpenID Connect(OIDC)를 사용하도록 Anthos clusters on AWS (GKE on AWS)를 구성하는 방법을 알아봅니다. 이 주제에서는 OpenID 제공업체를 사용하여 Anthos clusters on AWS(GKE on AWS)를 구성하는 프로세스를 설명합니다.

OIDC 인증을 사용하는 클러스터를 Kubernetes 1.21로 업그레이드하려면 1.21 버전으로 업그레이드를 참조하세요.

Anthos clusters on AWS 인증 흐름의 개요는 인증을 참조하세요.

개요

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

시작하기 전에

이 주제에서는 다음 인증과 OpenID 개념에 익숙하다고 가정합니다.
Google Cloud CLI는 각 개발자의 로컬 머신에 설치해야 합니다.
헤드리스 시스템은 지원되지 않습니다. 인증하려면 gcloud CLI를 실행하는 로컬 머신에서 브라우저를 열어야 합니다. 그러면 브라우저에 사용자 계정을 승인하라는 메시지가 표시됩니다.
Google Cloud 콘솔을 통해 인증하려면 OIDC 인증을 위해 구성하려는 각 클러스터가 Google Cloud에 등록되어야 합니다.

캐릭터

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

조직 관리자: 이 사람은 OpenID 제공업체를 선택하고 클라이언트 애플리케이션을 제공업체에 등록합니다.
클러스터 관리자: 이 사람은 사용자 클러스터를 하나 이상 만들고 클러스터를 사용하는 개발자를 위한 인증 구성 파일을 만듭니다.
개발자: 이 사람은 클러스터 한 개 이상에서 워크로드를 실행하고 OIDC를 사용하여 인증합니다.

OpenID 제공업체 선택

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

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

리디렉션 URL 만들기

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

OpenID 제공업체는 리디렉션 URL을 사용하여 ID 토큰을 반환합니다. gcloud CLI와 Google Cloud 콘솔 모두에 대해 리디렉션 URL을 만들어야 합니다.

gcloud CLI 리디렉션 URL 설정

OpenID 제공업체를 구성할 때 CLI 리디렉션 URL을 http://localhost:PORT/callback으로 지정합니다.

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

Google Cloud 콘솔 리디렉션 URL 설정

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

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

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

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

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

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

제공업체의 발급기관 URI를 파악합니다. gcloud CLI 또는 Google Cloud 콘솔이 이 URI에 인증 요청을 보냅니다.
포트 번호를 포함한 gcloud CLI의 리디렉션 URL을 사용하여 제공업체를 구성합니다.
Google Cloud 콘솔의 리디렉션 URL(https://console.cloud.google.com/kubernetes/oidc)을 사용하여 제공업체를 구성합니다.
제공업체가 Google Cloud CLI와 Google Cloud 콘솔을 모두 식별하는 데 사용할 단일 클라이언트 ID를 만듭니다.
gcloud CLI와 Google Cloud 콘솔이 OpenID 제공업체에 인증하는 데 사용할 단일 클라이언트 보안 비밀번호를 만듭니다.
gcloud CLI 또는 Google Cloud 콘솔이 사용자의 보안 그룹을 요청하는 데 사용할 수 있는 커스텀 범위를 만듭니다.
제공업체가 사용자의 보안 그룹을 반환하는 데 사용할 커스텀 클레임 이름을 만듭니다.

클러스터 구성

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

OIDC 인증을 구성하려면 클러스터의 인증 세부정보로 사용자 클러스터의 AWSCluster 리소스를 구성해야 합니다. AWSCluster의 세부정보는 Google Cloud 콘솔과 Anthos용 인증 플러그인 모두에 대해 OIDC를 구성하는 데 사용됩니다. 구성에는 다음 OIDC 정보가 포함됩니다.

authentication:
  awsIAM:
    adminIdentityARNs:
      - AWS_IAM_ARN
  oidc:
  -   certificateAuthorityData: CERTIFICATE_STRING
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      extraParams:  EXTRA_PARAMS
      groupsClaim:  GROUPS_CLAIM
      groupPrefix:  GROUP_PREFIX
      issuerURI:  ISSUER_URI
      kubectlRedirectURI:  KUBECTL_REDIRECT_URI
      scopes:  SCOPES
      userClaim:  USER_CLAIM
      userPrefix:  USER_PREFIX

인증 필드

다음 표에서는 authentication.awsIAM.adminIdentityARNs 객체의 필드를 설명합니다.

다음 표에서는 `oidc` 객체의 필드를 설명합니다.

필드	필수	설명	형식
adminIdentityARNs	예(OIDC를 구성하는 경우)	Anthos clusters on AWS가 클러스터 관리자 액세스 권한을 부여한 AWS IAM ID(사용자 또는 역할)의 Amazon 리소스 이름(ARN). 예: `arn:aws:iam::123456789012:group/Developers`	문자열

필드	필수	설명	형식
certificateAuthorityData	아니요	OIDC 제공업체의 base64로 인코딩된 PEM 인코딩 인증서입니다. 문자열을 만들려면 헤더를 포함한 인증서를 base64로 인코딩합니다. `certificateAuthorityData`에 결과 문자열을 단일 줄로 포함합니다. 예를 들면 `certificateAuthorityData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tC...k1JSUN2RENDQWFT==`입니다.	문자열
clientID	예	OpenID 제공업체에 인증을 요청하는 클라이언트 애플리케이션의 ID입니다.	문자열
clientSecret	아니요	OIDC 클라이언트 애플리케이션과 OIDC 제공업체 간에 공유된 보안 비밀입니다.	문자열
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	예	승인을 위해 리디렉션 url `kubectl`에서 사용됩니다.	URL 문자열
scopes	예	OpenID 제공업체에 전송할 추가적인 범위입니다. Microsoft Azure 및 Okta에는 `offline_access` 범위가 필요합니다.	쉼표로 구분된 목록
userClaim	아니요	사용자 이름으로 사용할 JWT 클레임입니다. OpenID 제공업체에 따라 이메일 또는 이름과 같은 다른 클레임을 선택할 수 있습니다. 하지만 이메일 이외의 클레임은 이름 충돌을 방지하기 위해 발급기관 URL이 프리픽스로 추가됩니다.	문자열
userPrefix	없음	기존 이름과 충돌하지 않도록 사용자 이름 클레임에 추가되는 프리픽스입니다.	문자열

예시: 사용자 및 그룹 승인

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

사용자 ID는 정책을 읽고 감사하기 어렵게 만들 수 있습니다.
이메일 주소를 사용하면 가용성 위험(사용자가 기본 이메일을 변경하는 경우) 및 보안 위험(이메일을 다시 할당할 수 있는 경우)이 생길 수 있습니다.

사용자 ID를 할당하는 대신 영구적이고 감사하기 쉬운 그룹 정책을 사용하는 것이 좋습니다.

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

{
  'iss': 'https://server.example.com'
  'sub': 'u98523-4509823'
  'groupList': ['developers@example.corp', 'us-east1-cluster-admins@example.corp']
  ...
}

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

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

사용자 클러스터를 만든 후 Kubernetes 역할 기반 액세스 제어(RBAC)를 사용하여 인증된 사용자에게 액세스 권한을 부여합니다.

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

ClusterRole을 정의합니다. 다음 YAML을 secret-reader-role.yaml이라는 파일에 복사합니다.

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을 정의합니다. 다음 YAML을 secret-reader-admins.yaml이라는 파일에 복사합니다.

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

kubectl을 사용하여 클러스터에 secret-reader-role.yaml 및 secret-reader-admins.yaml을 적용합니다.
```
env HTTPS_PROXY=http://localhost:8118 \
  kubectl apply -f secret-reader-role.yaml && \
  kubectl apply -f secret-reader-admins.yaml
```
이제 read-secrets-admins에 액세스 권한이 부여된 사용자가 클러스터에서 보안 비밀을 읽을 수 있습니다.

로그인 구성 만들기

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

사용자 클러스터를 만든 후에는 gcloud anthos create-login-config를 사용하여 클러스터에 대해 구성 파일을 생성해야 합니다.

anthos-aws 디렉터리에서 anthos-gke를 사용하여 컨텍스트를 사용자 클러스터로 전환합니다.
```
cd anthos-aws
env HTTPS_PROXY=http://localhost:8118 \
  anthos-gke aws clusters get-credentials CLUSTER_NAME
```
CLUSTER_NAME을 사용자 클러스터 이름으로 바꿉니다.
gcloud anthos를 사용하여 구성을 만듭니다.
```
gcloud anthos create-login-config --kubeconfig usercluster-kubeconfig
```
usercluster-kubeconfig를 사용자 클러스터의 kubeconfig 파일 경로로 바꿉니다. Linux 및 macOS에서는 이 파일은 기본적으로 ~/.kube/config에 있습니다.

이 명령어는 개발자가 gcloud CLI로 클러스터에 인증하기 위해 사용하는 구성 정보가 포함된 파일(kubectl-anthos-config.yaml)을 생성합니다. 이 파일을 수정해서는 안됩니다.

kubectl-anthos-config.yaml의 콘텐츠를 자세히 알아보려면 부록을 참조하세요.

사용자 클러스터에 인증해야 하는 사용자에게 구성 파일을 배포합니다. 다음과 같이 구성을 배포할 수 있습니다.

기본 디렉터리에 파일을 배치합니다.
파일을 보안 방식으로 배포합니다.
HTTPS 서버에 파일을 호스팅합니다.

로그인 구성 기본 디렉터리

각 OS에서 구성 파일을 저장하기 위한 기본 위치는 다음과 같습니다.

Linux: $HOME/.config/google/anthos/kubectl-anthos-config.yaml. $HOME은 사용자의 홈 디렉터리입니다.
macOS: $HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml. $HOME은 사용자의 홈 디렉터리입니다.
Windows: %APPDATA%/google/anthos/kubectl-anthos-config.yaml. %APPDATA%는 사용자의 애플리케이션 데이터 디렉터리입니다.

로그인 구성이 배포된 다음에는 개발자가 클러스터에 액세스하도록 gcloud CLI를 구성할 수 있습니다.

Kubernetes 1.21로 업그레이드한 후 클러스터 수정

클러스터를 Kubernetes 1.21로 업그레이드한 후에는 Anthos Identity Service를 구성하고 클러스터 구성에서 OIDC 정보를 삭제해야 합니다. 구성을 업데이트하려면 다음 단계를 수행합니다.

클러스터 업그레이드의 단계를 따릅니다.
anthos-aws 디렉터리에서 anthos-gke를 사용하여 컨텍스트를 사용자 클러스터로 전환합니다.
```
cd anthos-aws
env HTTPS_PROXY=http://localhost:8118 \
  anthos-gke aws clusters get-credentials CLUSTER_NAME
```
CLUSTER_NAME을 사용자 클러스터 이름으로 바꿉니다.
AWSCluster가 포함된 매니페스트를 텍스트 편집기에서 엽니다. 파일을 열어 두고 oidc 객체의 값을 사용하여 Anthos Identity Service용 클러스터 구성의 단계를 따릅니다.
anthos-aws 디렉터리에서 anthos-gke를 사용하여 컨텍스트를 관리 서비스로 전환합니다.
```
cd anthos-aws
anthos-gke aws management get-credentials
```
참고: anthos-gke에서는 aws configure를 실행할 때 지정한 사용자 인증 정보를 사용합니다.
AWSCluster를 만든 YAML 파일을 텍스트 편집기에서 엽니다. 초기 YAML 파일이 없으면 kubectl edit를 사용할 수 있습니다.
YAML 수정
사용자 클러스터 만들기 안내를 따랐으면 YAML 파일 이름은 cluster-0.yaml입니다. 이 파일을 텍스트 편집기에서 엽니다.
kubectl 수정
kubectl edit를 사용하여 AWSCluster를 수정하려면 다음 명령어를 실행합니다.
```
env HTTPS_PROXY=http://localhost:8118 \
  kubectl edit awscluster cluster-name
```
cluster-name을 AWSCluster로 바꿉니다. 예를 들어 기본 클러스터 cluster-0을 수정하려면 다음 명령어를 실행합니다.
```
env HTTPS_PROXY=http://localhost:8118 \
  kubectl edit awscluster cluster-0
```
클러스터의 매니페스트에서 oidc 객체를 삭제합니다.
파일을 저장합니다. kubectl edit을 사용하는 경우 kubectl이 변경사항을 자동으로 적용합니다. YAML 파일을 편집하는 경우 다음 명령어를 사용하여 관리형 서비스에 적용합니다.
```
env HTTPS_PROXY=http://localhost:8118 \
  kubectl apply -f cluster-0.yaml
```
그러면 관리 서비스가 AWSCluster를 업데이트합니다.

클러스터에 액세스하도록 gcloud 구성

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

기본 요건

이 섹션을 완료하려면 다음을 완료해야 합니다.

로그인 구성
gcloud CLI를 포함하는 anthos-auth 도구의 업데이트 버전
```
gcloud components update
gcloud components install anthos-auth
```
필요한 인수 및 사용 가능한 옵션에 대한 세부정보로 응답하는 다음 명령어를 실행해서 gcloud CLI가 성공적으로 설치되었는지 확인합니다.
```
gcloud anthos auth
```

클러스터 인증

다음과 같은 방법으로 클러스터에 인증할 수 있습니다.

로컬 머신에서 gcloud CLI 사용
SSH 터널을 사용하는 원격 머신에서 gcloud CLI 사용
Google Cloud 콘솔에서 Connect 사용

gcloud 로컬

gcloud anthos auth login을 사용하여 로그인 구성으로 클러스터에 인증합니다.

기본 위치에 로그인 구성을 배치했고 클러스터 이름을 구성한 경우 옵션 없이 gcloud anthos auth login을 사용할 수 있습니다. 또한 선택적인 매개변수를 사용해서 클러스터, 사용자, 다른 인증 세부정보를 구성할 수 있습니다.

기본

gcloud anthos auth login --cluster CLUSTER_NAME

CLUSTER_NAME을 정규화된 클러스터 이름으로 바꿉니다. 예를 들면 projects/my-gcp-project/locations/global/memberships/cluster-0-0123456a입니다.

선택적 매개변수

gcloud anthos auth login에는 다음과 같은 선택적 매개변수가 지원됩니다.

gcloud anthos auth login --cluster CLUSTER_NAME \
--user USERNAME --login-config ANTHOS_CONFIG_YAML \
--login-config-cert LOGIN_CONFIG_CERT_PEM \
--kubeconfig=KUBECONFIG --dry-run

매개변수는 다음 표에 설명되어 있습니다.

매개변수	설명
`cluster`	인증할 클러스터의 이름입니다. 기본값은 'kubectl-anthos-config.yaml'에 있는 클러스터입니다.
`user`	`kubeconfig`에 있는 사용자 인증 정보에 대한 사용자 이름입니다. 기본값은 `{cluster-name}-anthos-default-user`입니다.
`login-config`	개발자를 위해 클러스터 관리자가 생성한 구성 파일의 경로 또는 이 파일을 호스팅하는 URL입니다. 기본값은 `kubectl-anthos-config.yaml`입니다.
`login-config-cert`	`login-config`에 대한 URL을 사용하는 경우 HTTPS 연결을 수행하기 위한 CA 인증서 파일의 경로입니다.
`kubeconfig`	토큰이 포함된 kubeconfig 파일의 경로입니다. 기본값은 $HOME/.kube/config`입니다.
테스트 실행	구성 또는 클러스터를 변경하지 않고 명령줄 옵션을 테스트합니다.

gcloud anthos login 명령어는 브라우저를 실행해서 사용자가 자신의 기업 사용자 인증 정보로 로그인을 수행하도록 요청하고 OIDC 사용자 인증 정보 교환을 수행하며 관련 토큰을 가져옵니다. 그런 다음 gcloud CLI가 토큰을 kubeconfig 파일에 기록합니다. kubectl은 이 파일을 사용해서 사용자 클러스터에 대해 인증을 수행합니다.

인증이 성공했는지 확인하려면 kubeconfig 파일로 kubectl 명령어를 실행합니다.

env HTTPS_PROXY=http://localhost:8118 \
  kubectl get nodes --kubeconfig my.kubeconfig

gcloud 터널

원격 머신에서 사용자 클러스터에 인증하려면 SSH 터널을 사용하여 인증을 수행할 수 있습니다. 터널을 사용하려면 인증 구성 파일이 원격 머신에 있어야 하며 로컬 머신에서 Open ID 제공업체에 연결할 수 있어야 합니다.

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

ssh USERNAME@REMOTE_MACHINE -L LOCAL_PORT:localhost:REMOTE_PORT

다음을 바꿉니다.

USERNAME을 원격 머신에 대한 SSH 액세스 권한이 있는 사용자로 바꿉니다.
REMOTE_MACHINE을 원격 머신의 호스트 이름 또는 IP 주소로 바꿉니다.
LOCAL_PORT는 ssh가 원격 머신에 터널링하는 데 사용하는 로컬 머신의 사용 가능한 포트입니다.
REMOTE_PORT는 OIDC 리디렉션 URL에 구성한 포트입니다. 포트 번호는 인증 구성 파일의 kubectlRedirectURI 필드에 포함됩니다.

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

gcloud anthos auth login --login-config AUTH_CONFIG_FILE

AUTH_CONFIG_FILE를 원격 머신의 인증 구성 파일 경로로 바꿉니다. gcloud CLI는 원격 머신에서 웹 서버를 실행합니다.

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

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

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

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get nodes

콘솔

Google Cloud 콘솔로 인증하고 Google Cloud 콘솔의 Kubernetes 클러스터 페이지에서 인증 흐름을 시작할 수 있습니다.

Google Cloud 콘솔을 엽니다.

Kubernetes 클러스터 페이지로 이동
목록에서 Anthos clusters on AWS를 찾은 다음 로그인을 클릭합니다.
클러스터에 구성된 ID 공급업체로 인증을 선택한 후 로그인을 클릭합니다.

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

OIDC 구성 업데이트

클러스터의 OIDC 구성을 업데이트하려면 kubectl edit 명령어를 사용합니다.

env HTTPS_PROXY=http://localhost:8118 \
  kubectl edit clientconfigs -n kube-public default

kubectl 도구는 기본 편집기에 ClientConfig 리소스를 로드합니다. 구성을 업데이트하려면 파일을 저장합니다. kubectl 도구는 클러스터의 ClientConfig 리소스를 업데이트합니다.

ClientConfig 리소스의 콘텐츠에 대한 자세한 내용은 다음 섹션을 참조하세요.

부록: 로그인 구성 예시

kubectl-anthos-config.yaml 예시는 다음과 같습니다. 이 예시는 해당 콘텐츠의 이해를 돕기 위해 포함되어 있습니다. 항상 gcloud anthos create-login-config를 사용하여 파일을 생성해야 합니다.

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
 name: default
 namespace: kube-public
spec:
  authentication:
  - name: oidc
    oidc:
      clientID: CLIENT_CONFIG
      clientSecret: CLIENT_SECRET
      extraParams: resource=k8s-group-claim,domain_hint=consumers
      certificateAuthorityData:   CERTIFICATE_STRING
      issuerURI: https://adfs.contoso.com/adfs
      kubectlRedirectURI: http://redirect.kubectl.com/
      scopes: allatclaim,group
      userClaim: "sub"
      groupsClaim: "groups"
    proxy: PROXY_URL #Optional
  certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
  name: projects/my-project/locations/global/membership/cluster-0
  server: https://192.168.0.1:PORT
  preferredAuthentication: oidc

필드 콘텐츠에 대한 설명은 인증 필드를 참조하세요.

다음 단계

Anthos clusters on AWS에 첫 번째 워크로드를 배포합니다.

OpenID Connect(OIDC)로 인증

개요

시작하기 전에

캐릭터

OpenID 제공업체 선택

리디렉션 URL 만들기

gcloud CLI 리디렉션 URL 설정

Google Cloud 콘솔 리디렉션 URL 설정

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

클러스터 구성

인증 필드

예시: 사용자 및 그룹 승인

로그인 구성 만들기

로그인 구성 배포

로그인 구성 기본 디렉터리

Kubernetes 1.21로 업그레이드한 후 클러스터 수정

YAML 수정

kubectl 수정

클러스터에 액세스하도록 gcloud 구성

기본 요건

클러스터 인증

gcloud 로컬

기본

선택적 매개변수

gcloud 터널

콘솔

OIDC 구성 업데이트

부록: 로그인 구성 예시

다음 단계