외부 ID 공급업체를 사용하여 GKE에 인증

컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

이 페이지에서는 외부 ID 공급업체 (IdP)에서 Google Kubernetes Engine (GKE) 클러스터에 대한 인증을 구성하는 방법을 보여줍니다.

이 페이지는 OpenID Connect (OIDC) 또는 보안 보장 마크업 언어 (SAML) 2.0을 지원하는 외부 IdP를 사용하는 플랫폼 관리자 및 운영자, ID 및 계정 관리자를 대상으로 합니다.

이 페이지를 읽기 전에 다음 인증 및 OpenID 개념을 숙지해야 합니다.

• OAuth 2.0
• SAML 2.0
• OpenID Connect
• OIDC 범위 및 사용자 인증 정보
• Kubernetes RBAC

GKE의 외부 IdP 인증 방법

권장: 직원 ID 제휴

직원 ID 제휴는 OIDC 또는 SAML 2.0을 지원하는 모든 외부 IdP에서 Google Cloud 인증할 수 있는 IAM 기능입니다. Workforce Identity Federation은 클러스터 내 설치가 필요하지 않으며 Autopilot 클러스터 및 표준 클러스터에서 작동하며 Google Cloud에 내장되어 있습니다. 자세한 내용은 직원 ID 제휴에 관한 IAM 문서를 참고하세요.

권장하지 않음: GKE용 ID 서비스

GKE Standard 클러스터에서만 GKE는 GKE용 Identity Service도 지원합니다. GKE용 ID 서비스는 OIDC IdP로 제한되며 클러스터에 추가 구성요소를 설치합니다. GKE에서는 GKE용 ID 서비스 대신 Workforce Identity Federation을 사용하는 것이 좋습니다.

시작하기 전에

시작하기 전에 다음 태스크를 수행했는지 확인합니다.

• Google Kubernetes Engine API를 사용 설정합니다.
Google Kubernetes Engine API 사용 설정
• 이 태스크에 Google Cloud CLI를 사용하려면 gcloud CLI를 설치한 후 초기화하세요. 이전에 gcloud CLI를 설치한 경우 gcloud components update를 실행하여 최신 버전을 가져옵니다.

고려사항

헤드리스 시스템은 Workforce Identity Federation과 GKE용 ID 서비스에서 모두 지원되지 않습니다. 브라우저 기반 인증 흐름에서는 사용자에게 동의를 구하고 사용자 계정을 승인하라는 메시지를 표시합니다.

GKE에서 Workforce Identity Federation 사용

GKE 클러스터에서 Workforce Identity Federation을 사용하려면 다음 단계를 따르세요.

1. 조직 및 외부 IdP에 대해 직원 ID 제휴를 설정합니다. 자세한 내용은 직원 ID 제휴 구성을 참고하세요.
2. 외부 IdP에서 Google Cloud 직원 ID 제휴 콘솔에 대한 액세스를 설정합니다. 자세한 내용은 콘솔에 대한 사용자 액세스 설정 (제휴)을 참고하세요.

3. 다음 승인 메커니즘 중 하나를 사용하여 사용자 액세스를 구성합니다.

   • Kubernetes RBAC
   • IAM 허용 정책

4. 사용자에게 다음 단계를 완료하여 클러스터에 액세스하도록 안내합니다.

   1. 제휴 ID로 gcloud CLI에 로그인합니다.
   2. gcloud container clusters get-credentials를 실행하여 특정 클러스터에 인증하도록 kubectl을 구성합니다.

RBAC를 사용하여 클러스터에 대한 사용자 액세스 구성

Google Cloud 는 주 구성원 식별자를 사용하여 직원 ID 풀의 사용자를 식별합니다. Kubernetes RBAC 정책 또는 IAM 정책에서 이러한 주 구성원 식별자를 참조할 수 있습니다. 다음 예와 같이 개인 또는 사용자 그룹에 권한을 부여할 수 있습니다.

principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_IDENTITY_POOL/subject/SUBJECT_ATTRIBUTE_VALUE

principal://iam.googleapis.com/locations/global/workforcePools/full-time-employees/subject/amal@example.com

principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_IDENTITY_POOL/group/GROUP_NAME

principalSet://iam.googleapis.com/locations/global/workforcePools/full-time-employees/group/sre

Workforce Identity Federation에서 지원하는 모든 주 구성원 식별자에 관한 자세한 내용은 IAM 정책에서 직원 풀 사용자 표현을 참고하세요.

다음 예에서는 IdP 토큰에 access_level="sensitive" 속성이 있는 full-time-employees 직원 풀의 모든 항목에 시크릿에 대한 클러스터 전체 읽기 전용 액세스 권한을 부여하는 방법을 보여줍니다.

1. 다음 ClusterRole 매니페스트를 secret-viewer-cluster-role.yaml로 저장합니다.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: secret-viewer
   rules:
   - apiGroups: [""]
     resources: ["secrets"]
     verbs: ["get", "watch", "list"]
   

   이 ClusterRole을 바인딩하는 모든 주 구성원은 보안 비밀을 볼 수 있습니다.

2. 다음 ClusterRoleBinding 매니페스트를 secret-viewer-cluster-role-binding.yaml로 저장합니다.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name:  users-view-secrets
   subjects:
   - kind: Group
     name: principalSet://iam.googleapis.com/locations/global/workforcePools/full-time-employees/attribute.access_level/sensitive
     apiGroup: rbac.authorization.k8s.io
   roleRef:
     kind: ClusterRole
     name: secret-viewer
     apiGroup: rbac.authorization.k8s.io
   

   이 ClusterRoleBinding은 access_level="sensitive" 속성이 있는 모든 사용자에게 secret-viewer ClusterRole을 부여합니다.

3. ClusterRole 및 ClusterRoleBinding을 배포합니다.

   kubectl apply -f secret-viewer-cluster-role.yaml
   kubectl apply -f secret-viewer-cluster-role-binding.yaml
   

클러스터에 로그인 및 인증

1. 사용자가 Google Cloud에 Google Cloud CLI를 사용하여 로그인하도록 안내합니다.

2. 사용자는 다음을 사용하여 클러스터에 인증하도록 kubectl을 구성할 수 있습니다.

   gcloud container clusters get-credentials
   

GKE 클러스터의 Identity Service를 Workforce Identity Federation으로 이전

기존 GKE 클러스터에서 GKE용 ID 서비스를 사용하는 경우 Workforce Identity Federation으로 이전하세요. 이러한 메서드는 다음 표와 같이 서로 다른 문법을 사용하여 동일한 사용자를 참조합니다.

Workforce Identity Federation을 사용하도록 클러스터를 이전하려면 다음 단계를 따르세요.

1. 조직 및 외부 IdP에 대해 직원 ID 제휴를 설정합니다. 자세한 내용은 직원 ID 제휴 구성을 참고하세요.

2. 직원 ID 제휴 식별자 문법을 사용하도록 클러스터의 모든 RoleBinding 및 ClusterRoleBindings의 매니페스트를 업데이트합니다. 다음 옵션 중 하나를 사용합니다.

   • 프로그래매틱 업데이트: gke-identity-service-migrator 유틸리티를 설치하고 실행합니다. 자세한 내용은 GoogleCloudPlatform/gke-utilities 저장소 README를 참고하세요.

     이 유틸리티는 GKE용 ID 서비스 문법을 사용하는 기존 RBAC 바인딩을 찾고 상응하는 Workforce Identity Federation 사용자 식별자를 사용하는 새 매니페스트를 만듭니다.

   • 수동 업데이트: 인증된 사용자 또는 그룹을 참조하는 모든 결합의 경우 Workforce Identity Federation 식별자 문법을 사용하는 객체의 매니페스트 파일의 별도 사본을 만듭니다.

3. RoleBinding 및 ClusterRoleBinding의 업데이트된 매니페스트를 클러스터에 적용합니다.

4. 사용자가 Workforce Identity Federation을 사용하여 인증할 때 동일한 리소스에 액세스할 수 있는지 테스트합니다.

5. 클러스터에서 더 이상 사용되지 않는 RBAC 바인딩을 삭제합니다.

6. GKE용 ID 서비스를 사용 중지합니다.

GKE용 ID 서비스 사용

클러스터 관리자는 GKE Standard 모드 클러스터에서 GKE용 ID 서비스를 설정하고 사용하기 위해 다음을 수행합니다.

1. 클러스터에서 GKE용 ID 서비스를 사용 설정합니다.
2. GKE용 ID 서비스를 구성합니다.
3. 클러스터의 RBAC 정책을 만듭니다.

클러스터 관리자가 GKE용 ID 서비스를 구성한 후에는 개발자가 로그인하고 클러스터에 인증을 수행할 수 있습니다.

GKE용 ID 서비스에서 생성된 Kubernetes 객체

다음 표에서는 클러스터에서 GKE용 ID 서비스를 사용 설정할 때 생성된 Kubernetes 객체에 대해 설명합니다.

클러스터에서 GKE용 ID 서비스 사용 설정

기본적으로 Identity and Access Management(IAM)는 클러스터 인증을 위한 ID 공급업체로 구성됩니다. 타사 ID 공급업체로 OIDC를 사용하려면 Google Cloud CLI를 사용하여 신규 또는 기존 클러스터에서 GKE용 ID 서비스를 사용 설정하면 됩니다.

새 클러스터에서 GKE용 ID 서비스 사용 설정

GKE용 ID 서비스가 사용 설정된 클러스터를 만들려면 다음 명령어를 실행하세요.

gcloud container clusters create CLUSTER_NAME \
    --enable-identity-service

CLUSTER_NAME을 새 클러스터 이름으로 바꿉니다.

기존 클러스터에서 GKE용 ID 서비스 사용 설정

기존 클러스터에서 GKE용 ID 서비스를 사용 설정하려면 다음 명령어를 실행하세요.

gcloud container clusters update CLUSTER_NAME \
    --enable-identity-service

CLUSTER_NAME을 클러스터 이름으로 바꿉니다.

GKE용 ID 서비스 구성

default ClientConfig를 다운로드하고 수정하여 GKE용 ID 서비스 매개변수를 구성할 수 있습니다.

1. default ClientConfig를 다운로드합니다.

   kubectl get clientconfig default -n kube-public -o yaml > client-config.yaml
   

2. 원하는 설정으로 spec.authentication 섹션을 업데이트하세요.

   apiVersion: authentication.gke.io/v2alpha1
   kind: ClientConfig
   metadata:
     name: default
     namespace: kube-public
   spec:
     name: cluster-name
     server: https://192.168.0.1:6443
     authentication:
     - name: oidc
       oidc:
         clientID: CLIENT_ID
         certificateAuthorityData: OIDC_PROVIDER_CERTIFICATE
         extraParams: EXTRA_PARAMS
         issuerURI:  ISSUER_URI
         cloudConsoleRedirectURI: https://console.cloud.google.com/kubernetes/oidc
         kubectlRedirectURI: KUBECTL_REDIRECT_URL
         scopes: SCOPES
         userClaim: USER
         groupsClaim: GROUPS
         userPrefix: USER_PREFIX
         groupPrefix: GROUP_PREFIX
   

   다음을 바꿉니다.

   • CLIENT_ID: OIDC 공급업체에 대해 인증 요청을 수행하는 클라이언트 애플리케이션의 ID입니다.
   • OIDC_PROVIDER_CERTIFICATE: (선택사항) OIDC 공급업체에 대한 PEM 인증서입니다. 이 필드는 OIDC 공급업체가 자체 서명된 인증서를 사용하는 경우에 유용할 수 있습니다. GKE용 ID 서비스에는 기본적으로 공개 루트 집합이 포함됩니다.
   • EXTRA_PARAMS: OIDC 제공업체에 전송할 추가적인 키-값 매개변수입니다.
     • 그룹을 승인하려면 resource=token-groups-claim을 사용하세요.
     • Microsoft Azure 및 Okta를 인증하려면 prompt=consent를 사용합니다.
     • Cloud ID의 경우 prompt=consent,access_type=offline을 사용하세요.
   • ISSUER_URI: OIDC 승인 요청을 전송할 URL입니다(예시: https://example.com/adfs). Kubernetes API 서버는 이 URL을 사용하여 토큰을 확인할 수 있도록 공개 키를 검색합니다. URI는 HTTPS를 사용해야 합니다. Cloud ID의 경우 https://accounts.google.com을 사용하세요.
   • KUBECTL_REDIRECT_URL: 승인을 위해 kubectl oidc login에 사용되는 리디렉션 URL입니다. 일반적으로 http://localhost:PORT/callback 형식입니다. 여기서 PORT는 개발자 워크스테이션에서 사용 가능한 1024보다 큰 포트입니다(예: http://localhost:10000/callback). 이 URL을 OIDC 제공업체에 클라이언트 애플리케이션의 승인된 리디렉션 URL로 등록해야 합니다. Google ID를 OIDC 공급업체로 사용하는 경우 리디렉션 URI 설정을 참조하세요.
   • SCOPES: OIDC 제공업체에 전송할 추가적인 범위입니다.
     • Microsoft Azure 및 Okta에는 offline_access 범위가 필요합니다.
     • Cloud ID의 경우 openid, email을 사용하여 email 클레임에 이메일 주소가 포함된 ID 토큰을 가져옵니다.
   • USER: ID 토큰의 사용자 클레임입니다.
   • GROUPS: ID 토큰의 그룹 클레임입니다.
   • USER_PREFIX: 기존 이름과 충돌을 방지하기 위해 사용자 클레임에 추가된 프리픽스입니다. 기본적으로 발급자 프리픽스가 Kubernetes API server에 제공된 userID 앞에 붙습니다(사용자 클레임이 email이 아닌 경우). 그 결과 사용자 식별자는 ISSUER_URI#USER가 됩니다. 프리픽스를 사용하는 것을 권장하지만, 사용자는 USER_PREFIX를 -로 설정하여 프리픽스를 사용 중지할 수 있습니다.
   • GROUP_PREFIX: 기존 이름과 충돌을 방지하기 위해 그룹 클레임에 추가되는 프리픽스입니다. 예를 들어 이름이 foobar인 그룹이 2개 있는 경우 gid- 프리픽스를 추가하세요. 결과 그룹은 gid-foobar입니다.

3. 업데이트된 구성을 적용합니다.

   kubectl apply -f client-config.yaml
   

   이 구성을 적용하면 GKE용 ID 서비스가 클러스터 내에서 실행되고 gke-oidc-envoy 부하 분산기 뒤에서 요청을 처리합니다. spec.server 필드의 IP 주소는 부하 분산기의 IP 주소여야 합니다. spec.server 필드를 변경하면 kubectl 명령어가 실패할 수 있습니다.

4. client-config.yaml 구성 파일의 사본을 만듭니다.

   cp client-config.yaml login-config.yaml
   

5. spec.authentication.oidc 섹션의 clientSecret 설정을 사용하여 login-config.yaml 구성 파일을 업데이트합니다.

   clientSecret: CLIENT_SECRET
   

   CLIENT_SECRET를 OIDC 클라이언트 애플리케이션과 OIDC 제공업체 사이의 공유 보안 비밀로 바꿉니다.

6. 업데이트된 login-config.yaml 파일을 개발자에게 배포합니다.

엄격한 정책으로 클러스터에서 GKE용 ID 서비스 구성

엄격한 네트워크 정책이 적용된 클러스터에서 예상대로 작동하도록 GKE용 ID 서비스를 구성하려면 다음을 수행합니다.

1. 컨트롤 플레인이 ClientConfig 검증 웹훅과 통신할 수 있도록 TCP 포트 15000에 대해 방화벽 규칙을 추가합니다.
2. gke-oidc-envoy가 내부 부하 분산기로 생성되었으면 이를 VPC에 노출합니다.
3. 클러스터 내에서 트래픽을 거부하는 정책이 있으면 gke-oidc-envoy 배포가 gke-oidc-service 배포와 통신할 수 있도록 TCP 포트 8443에 대해 방화벽 규칙을 추가합니다.

GKE용 ID 서비스 구성요소 버전 0.2.20 이상에서는 TCP 포트 15000을 사용하지 않습니다. 구성요소 버전이 0.2.20 이상인 경우 포트 15000에 대한 방화벽 규칙을 추가할 필요가 없습니다. 구성요소 버전을 확인하려면 다음 명령어를 실행합니다.

kubectl describe deployment gke-oidc-envoy -n anthos-identity-service \
    | grep "components.gke.io/component-name: gke-oidc" -A1

부하 분산기에 커스텀 속성 추가

GKE용 ID 서비스를 구성한 후 고정 IP 주소와 같은 커스텀 주석 및 속성을 gke-oidc-envoy 부하 분산기에 추가할 수 있습니다. gke-oidc-envoy 서비스를 수정하려면 다음 명령어를 실행합니다.

kubectl edit service gke-oidc-envoy -n anthos-identity-service

GKE에 TCP/UDP 부하 분산 구성에 관한 자세한 내용은 LoadBalancer 서비스 매개변수를 참조하세요.

클러스터의 RBAC 정책 만들기

관리자가 Kubernetes 역할 기반 액세스 제어(RBAC)를 사용하여 인증된 클러스터 사용자에게 액세스 권한을 부여할 수 있습니다. 클러스터에 대해 RBAC를 구성하려면 사용자는 각 개발자에게 RBAC 역할을 부여해야 합니다. 특정 네임스페이스의 리소스에 대한 액세스 권한을 부여하려면 Role과 RoleBinding을 만듭니다. 전체 클러스터에서 리소스에 대한 액세스 권한을 부여하려면 ClusterRole과 ClusterRoleBinding을 만듭니다.

예를 들어 사용자가 클러스터 간의 모든 보안 비밀 객체를 확인해야 한다고 가정해보세요. 다음 단계에서는 이 사용자에게 필요한 RBAC 역할을 부여합니다.

1. 다음 ClusterRole 매니페스트를 secret-viewer-cluster-role.yaml로 저장하세요. 이 역할이 부여된 사람은 클러스터의 모든 보안 비밀을 가져오고, 보고, 나열할 수 있습니다.

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

2. ClusterRole 매니페스트를 적용합니다.

   kubectl apply -f secret-viewer-cluster-role.yaml
   

3. 다음 ClusterRoleBinding 매니페스트를 secret-viewer-cluster-role-binding.yaml로 저장합니다. binding은 클라이언트 구성 파일에 정의된 사용자 이름에 secret-viewer 역할을 부여합니다.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name:  people-who-view-secrets
   subjects:
   - kind: User
     name: ISSUER_URI#USER
     apiGroup: rbac.authorization.k8s.io
   roleRef:
     kind: ClusterRole
     name: secret-viewer
     apiGroup: rbac.authorization.k8s.io
   

   다음을 바꿉니다.

   • ISSUER_URI: 클라이언트 구성 파일의 spec.authentication.oidc.issuerURI에서 가져온 발급기관 URI입니다.
   • USER: 클라이언트 구성 파일의 spec.authentication.oidc.userClaim에 구성된 클레임 이름 아래에 있는 토큰의 사용자 식별자

4. ClusterRoleBinding 매니페스트를 적용합니다.

   kubectl apply -f secret-viewer-cluster-role-binding.yaml
   

클러스터에 로그인 및 인증

관리자로부터 OIDC 구성 파일을 받는 개발자는 클러스터에 인증할 수 있습니다.

1. 관리자가 제공한 login-config.yaml 파일을 다운로드합니다.

2. 별도의 OIDC 구성요소를 제공하는 Google Cloud CLI SDK를 설치하세요. 다음 명령어를 실행하여 이를 설치할 수 있습니다.

   gcloud components install kubectl-oidc
   

3. 클러스터에 인증을 수행합니다.

   kubectl oidc login --cluster=CLUSTER_NAME --login-config=login-config.yaml
   

   인증 프로세스를 완료하도록 웹브라우저가 열립니다.

4. 인증된 후에는 kubectl 명령어를 실행하여 다음을 수행할 수 있습니다.

   kubectl get pods
   

GKE용 ID 서비스 사용 중지

gcloud CLI를 사용하여 GKE용 ID 서비스를 사용 중지할 수 있습니다. GKE용 ID 서비스를 사용 중지하려면 다음 명령어를 실행하세요.

gcloud container clusters update CLUSTER_NAME \
    --no-enable-identity-service

다음 단계

• 직원 ID 제휴에 대해 자세히 알아보기
• 워크로드 배포 자세히 알아보기