Fleet 워크로드 아이덴티티 제휴 정보

이 페이지에서는 Fleet 워크로드에서 Google Cloud API로의 요청을 인증하는 메커니즘인 Fleet 워크로드 아이덴티티 제휴를 설명합니다. 이 페이지에서는 워크로드의 ID 동일성, Fleet 워크로드 아이덴티티 제휴의 작동 방식, 대규모로 관리하기 위한 권장사항을 알아봅니다.

이 페이지는 대규모로 워크로드 승인을 더 효율적으로 관리하려는 플랫폼 관리자 및 운영자와 보안 엔지니어를 대상으로 합니다. Google Cloud문서에서 참조하는 사용자 역할 및 예시 태스크에 대해 자세히 알아보려면 일반 GKE Enterprise 사용자 역할 및 태스크를 참고하세요.

이 페이지를 읽기 전 다음 내용을 숙지해야 합니다.

Google Cloud의 제휴 워크로드 ID 정보

워크로드 아이덴티티 제휴는 사용자 인증 정보를 다운로드하고 수동으로 순환하고 일반적으로 관리할 필요 없이 클러스터의 워크로드가 Google Cloud Google Cloud 에 인증할 수 있는 기능입니다. 대신 워크로드는 Google Cloud에서 생성된 단기 토큰을 사용하여 인증합니다.

GKE용 워크로드 아이덴티티 제휴는 GKE 클러스터에서 실행되는 애플리케이션이 아이덴티티를 가져오는 프로젝트 전체 Google 관리 워크로드 아이덴티티 풀을 제공하는 워크로드 아이덴티티 제휴의 GKE용 구현입니다. Fleet 워크로드 아이덴티티 제휴는 클러스터가 다른 프로젝트에 있는지 또는 Google Cloud외부에 있는지에 관계없이 GKE용 워크로드 아이덴티티 제휴를 모든 Fleet 구성원 클러스터로 확장합니다. Fleet 워크로드 아이덴티티 제휴를 사용하면 Fleet 멤버십에 워크로드 아이덴티티 제휴가 사용 설정된 등록된 클러스터는 Fleet 전체의 Google 관리 워크로드 아이덴티티 풀을 사용하여 ID를 가져옵니다. 이 공유 풀을 사용하면 여러 프로젝트에 걸쳐 전체 Fleet에서 Google Cloud API 및 기타 서비스에 대한 인증을 구성할 수 있습니다.

또한 Fleet 워크로드 아이덴티티 제휴는 일부 클러스터 유형의 Connect Agent에서 Fleet 멤버십의 일부로 Google Cloud 에 인증을 수행하기 위해 사용될 수 있으며, Cloud Service Mesh와 같이 프로젝트 간에 작동하는 일부 GKE Enterprise 기능을 사용하기 위해 필요합니다.

워크로드 아이덴티티 풀 정보

워크로드 아이덴티티 풀은 애플리케이션의 ID를 중앙에서 관리하는 항목입니다. 클러스터에서 GKE용 워크로드 아이덴티티 제휴를 사용 설정하면 클러스터 프로젝트에 고정된 프로젝트별 이름이 있는 Google 관리 워크로드 아이덴티티 풀이 할당됩니다. 클러스터의 애플리케이션은 Google 관리 워크로드 아이덴티티 풀에서 아이덴티티를 가져와 Google Cloud API 호출을 인증합니다. Google 관리형 워크로드 아이덴티티 풀의 문법은 PROJECT_ID.svc.id.goog이며 여기서 PROJECT_ID는 클러스터 프로젝트 ID입니다.

Fleet 워크로드 아이덴티티 제휴를 사용하면 Fleet 호스트 프로젝트의 Google 관리형 워크로드 아이덴티티 풀이 클러스터가 다른 프로젝트에 있는지 또는 Google Cloud외부에 있는지에 관계없이 Fleet에 등록하는 모든 클러스터의 워크로드 아이덴티티 풀이 됩니다. Fleet의 모든 클러스터는 FLEET_HOST_PROJECT_ID.svc.id.goog 워크로드 ID 풀을 사용합니다. 여기서 FLEET_HOST_PROJECT_ID는 Fleet 호스트 프로젝트의 프로젝트 ID입니다.

팀 범위를 사용하는 경우 원하는 경우 클러스터가 Google 관리 풀 외에도 사용할 수 있는 자체 관리 IAM 워크로드 아이덴티티 풀을 구성할 수 있습니다. 이 자체 관리 풀은 특정 ID를 가져오는 워크로드를 더 명시적으로 제어합니다.

Fleet의 각 애플리케이션은 Fleet의 워크로드 ID 풀에서 고유한 제휴 ID를 가져와Google Cloud 및 개발자가 개발한 기타 서비스에 인증하는 데 사용할 수 있습니다. 애플리케이션에 IAM에서 인식할 수 있는 주 구성원 식별자가 부여됩니다. 이 식별자는 다음 문법을 사용합니다.

PREFIX://iam.googleapis.com/projects/FLEET_PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_IDENTITY_POOL_NAME/SELECTOR

이 구문에는 다음과 같은 필드가 있습니다.

  • PREFIX: SELECTOR 필드에서 선택한 Kubernetes 리소스의 유형에 따라 principal 또는 principalSet입니다.
  • FLEET_PROJECT_NUMBER: Fleet 호스트 프로젝트의 프로젝트 번호입니다.

  • WORKLOAD_IDENTITY_POOL_NAME: Fleet의 워크로드 아이덴티티 풀입니다. 이 값은 다음과 같이 각 클러스터에서 설정한 워크로드 아이덴티티 풀에 따라 다릅니다.

    • Google 관리 워크로드 ID 풀: FLEET_HOST_PROJECT_ID.svc.id.goog

    • 자체 관리 워크로드 아이덴티티 풀 (미리보기): POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog입니다. 여기서 POOL_HOST_PROJECT_NUMBER은 자체 관리 워크로드 아이덴티티 풀을 만든 프로젝트의 프로젝트 번호입니다.

  • SELECTOR: 리소스 선택기. 지원되는 선택기 목록은 지원되는 주 구성원 식별자 섹션을 참고하세요. 예를 들어 subject/ns/NAMESPACE/sa/SERVICEACCOUNT는 특정 네임스페이스에서 특정 Kubernetes ServiceAccount를 선택합니다.

전체 Fleet이 Fleet 워크로드 ID 풀을 공유하므로 각 클러스터에 대한 액세스를 관리할 필요 없이 다른 프로젝트나 클라우드를 포함하여 Fleet의 모든 위치에서 애플리케이션에 동일한 리소스에 대한 액세스 권한을 제공할 수 있습니다.

ID 동일성 정보

다른 Fleet 지원 기능과 마찬가지로 Fleet 워크로드 아이덴티티 제휴는 서로 다른 클러스터에서 이름과 네임스페이스가 동일한 Kubernetes 객체가 동일한 것으로 간주되는 동일성의 원칙을 따릅니다. Fleet의 일반적인 동일성 원칙에 관해 자세히 알아보려면 동일성을 참고하세요.

GKE용 단일 프로젝트 워크로드 아이덴티티 제휴의 경우 해당 프로젝트에서 주 구성원 식별자를 공유하는 모든 항목에 ID 동질성이 적용됩니다. 그러나 Fleet 워크로드 아이덴티티 제휴를 사용하면 이 ID 동일성이 클러스터 프로젝트와 관계없이 전체 Fleet에서 주 구성원 식별자를 공유하는 모든 항목에 암시적으로 적용됩니다.

예를 들어 동일한 Fleet의 여러 클러스터에 배포된 백엔드가 있는 애플리케이션을 생각해 보겠습니다. backend Kubernetes 네임스페이스에서 default Kubernetes ServiceAccount를 선택하는 사용자 식별자에 역할을 부여하면 해당 서비스 계정을 사용하는 네임스페이스의 모든 애플리케이션에 동일한 액세스 권한이 부여됩니다.

Fleet가 Fleet 호스트 프로젝트에서만 클러스터를 실행하는 경우 ID 동일성의 의미는 GKE용 워크로드 아이덴티티 제휴와 동일합니다. 하지만 Fleet에 다른 프로젝트 또는Google Cloud외부에서 실행되는 클러스터가 있는 경우 이 암시적 ID 동일성이 Fleet에 등록된 모든 클러스터로 확장됩니다.

멀티 테넌트 또는 혼합 신뢰 환경의 ID 동일성

기본적으로 Fleet는 Fleet 호스트 프로젝트의 Google 관리형 워크로드 아이덴티티 풀을 사용하여 Fleet 전체의 워크로드에 ID를 제공합니다. Fleet에 등록되지 않은 독립형 클러스터를 비롯하여 Fleet 호스트 프로젝트의 모든 클러스터는 이 워크로드 ID 풀을 사용합니다. 이러한 독립형 클러스터가 신뢰 모델이 다른 워크로드를 실행하는 혼합 신뢰 환경에서는 이 암시적 ID 동일성으로 인해 의도치 않은 액세스가 발생할 수 있습니다.

Fleet를 사용하면 팀 범위 및 Fleet 네임스페이스를 사용하여 이 멀티 테넌트 모델을 관리할 수 있습니다. 팀 범위를 사용하면 조직의 특정 팀에서 사용할 클러스터와 같은 Fleet 리소스의 하위 집합을 지정할 수 있습니다. Fleet 네임스페이스를 사용하면 특정 팀 범위 내에서 Kubernetes 네임스페이스를 정의할 수 있으므로 특정 팀은 팀 범위의 네임스페이스에서만 워크로드를 실행할 수 있습니다. 자세한 내용은 Fleet팀 관리 개요를 참고하세요.

팀 범위를 사용하는 경우 Google에서 관리하는 워크로드 아이덴티티 풀 대신 사용할 Fleet의 특정 클러스터에 자체 워크로드 아이덴티티 풀을 구성하여 멀티테넌트 Fleet의 ID 동일성 복잡성을 완화할 수 있습니다. 따라서 이러한 워크로드의 주 구성원 식별자는 프로젝트의 독립형 클러스터의 주 구성원 식별자와 명시적으로 다릅니다. 이 명시적 ID 동일성을 사용하면 관리자가 ID 동일성이 적용되는 경계를 더 세부적으로 제어할 수 있습니다.

Google 관리 워크로드 ID 풀만 사용하거나 자체 관리 워크로드 ID 풀을 구성하는지에 따라 Fleet의 ID 동일성 모델이 다음과 같이 변경됩니다.

  • 암시적 ID 동일성: Fleet의 모든 워크로드가 Google에서 관리하는 워크로드 아이덴티티 풀을 사용합니다. 따라서 동일한 주 구성원 식별자를 공유하는 모든 워크로드는 암시적으로 동일한 액세스 권한을 공유합니다.

  • 명시적 ID 동일성 (미리보기): Fleet의 팀 범위에 대해 자체 관리 워크로드 ID 풀을 구성합니다. 자체 관리 풀은 특정 Fleet 네임스페이스에 자체 관리 풀을 사용하도록 클러스터를 구성한 경우에만 워크로드에 ID를 제공합니다. 다른 Kubernetes 네임스페이스 및 클러스터에서 실행되는 워크로드는 자체 관리 풀을 사용할 수 없습니다.

    따라서 자체 관리 풀을 사용하는 워크로드의 ID 동일성은 Google 관리 워크로드 ID 풀만 사용할 수 있는 워크로드의 ID 동일성과 다릅니다.

자체 관리 워크로드 아이덴티티 풀을 사용해야 하는 경우

모든 클러스터에서 동일한 신뢰 수준을 갖고 동일한 항목이 동일한 애플리케이션을 배포하는 경우 Google에서 관리하는 워크로드 ID 풀을 사용하세요. 예를 들어 각 클러스터에 복제된 애플리케이션을 배포하는 각 리전에 클러스터가 있는 팀별 Fleet가 있습니다.

다음과 같은 시나리오에서는 함대에 자체 관리형 워크로드 ID 풀을 구성하는 것이 좋습니다.

  • 플릿의 여러 신뢰 수준: 여러 신뢰 수준이 있는 클러스터를 실행합니다. 예를 들어 재무팀과 프런트엔드팀에 동일한 Fleet에 클러스터가 있는 시나리오를 생각해 보겠습니다. 자체 관리형 워크로드 아이덴티티 풀을 사용하면 플릿 네임스페이스별로 각 팀의 액세스 권한을 분리할 수 있습니다. 즉, 프런트엔드 클러스터의 클러스터 관리자도 명시적인 권한이 없으면 Fleet 네임스페이스에서 ID를 가져올 수 없습니다.
  • 프로젝트에 여러 신뢰 수준: Fleet 호스트 프로젝트는 Fleet 클러스터와 신뢰 수준이 다를 수 있는 독립형 클러스터를 실행합니다. 기본적으로 이러한 독립형 클러스터는 Fleet 호스트 프로젝트의 Google 관리 워크로드 아이덴티티 풀을 사용합니다. Fleet 클러스터도 Fleet 클러스터 프로젝트와 관계없이 이 워크로드 아이덴티티 풀을 사용합니다. Fleet에 자체 관리 워크로드 아이덴티티 풀을 설정하면 자체 관리 풀의 액세스 권한 부여가 의도치 않게 독립형 클러스터에 액세스 권한을 부여하지 않습니다.
  • 팀 범위 권장사항: 이미 Fleet팀 관리 기능을 사용하고 있으며 워크로드에 대한 액세스 권한을 부여하기 위한 권장 권장사항을 구현하려는 경우 자체 관리 워크로드 아이덴티티 풀을 설정하면 동일한 클러스터에서 워크로드를 실행하는 다른 팀 범위에 액세스 권한을 부여하지 않고도 팀 범위 내 특정 Fleet 네임스페이스의 워크로드에 대한 액세스 권한을 부여할 수 있습니다.

Fleet 워크로드 아이덴티티 제휴 작동 방식

다음 섹션에서는 인증 사용자 인증 정보의 흐름 및 지원되는 IAM 사용자 식별자를 비롯하여 Fleet 워크로드 ID 제휴의 작동 방식을 설명합니다.

사용자 인증 정보 흐름

특정 네임스페이스의 애플리케이션이 Fleet 워크로드 아이덴티티 제휴를 사용하여 인증하도록 하려면 다음 단계를 따르세요.

  1. 다음 정보가 포함된 ConfigMap을 해당 네임스페이스에 배포합니다.

    • 클러스터의 워크로드 아이덴티티 풀 및 ID 공급업체
    • 각 포드에서 Kubernetes가 ServiceAccount 토큰을 마운트하는 경로. 이 토큰은 서명된 JSON 웹 토큰(JWT)입니다.

    이 ConfigMap은 워크로드의 애플리케이션 기본 사용자 인증 정보(ADC) 파일로 작동합니다.

  2. 네임스페이스의 ServiceAccount와 같이 클러스터에 속한 주 구성원의 주 구성원 식별자에 특정Google Cloud 리소스에 대한 액세스 권한을 부여하는 IAM 허용 정책을 만듭니다.

  3. 네임스페이스에 속한 워크로드의 포드 사양에 다음 구성이 있는지 확인합니다.

    • 포드의 ConfigMap 마운트 경로로 설정된 GOOGLE_APPLICATION_CREDENTIALS 환경 변수
    • GOOGLE_APPLICATION_CREDENTIALS 환경 변수에 지정한 것과 동일한 경로에 마운트된 ServiceAccount 토큰 및 사용자가 만든 ConfigMap을 포함하는 예상 볼륨
    • 예상 볼륨을 참조하는 컨테이너의 볼륨 마운트

워크로드가 Google Cloud API를 호출하면 다음 단계가 수행됩니다.

  1. 인증 라이브러리는 Google Cloud 애플리케이션 기본 사용자 인증 정보 (ADC)를 사용하여 사용자 인증 정보를 찾습니다. ADC는 GOOGLE_APPLICATION_CREDENTIALS 환경 변수에 지정된 경로를 확인하여 인증 토큰을 찾습니다.
  2. ADC 인증 라이브러리는 ConfigMap의 데이터를 사용하여 포드에 마운트한 ServiceAccount JWT를 워크로드의 주 구성원 식별자를 참조하는 보안 토큰 서비스의 단기 제휴 액세스 토큰으로 교환합니다.
  3. ADC는 API 요청에 제휴 액세스 토큰을 포함합니다.
  4. IAM 허용 정책은 주 구성원이 리소스에서 요청된 작업을 수행하도록 승인합니다. Google Cloud

Fleet 워크로드 아이덴티티 제휴에 지원되는 주 구성원 식별자

다음 표에서는 IAM 허용 정책에서 Fleet의 주 구성원을 참조하는 데 사용할 수 있는 선택기를 설명합니다.

주 구성원 식별자 유형 구문
특정 Kubernetes ServiceAccount를 사용하는 모든 포드 이름별로 ServiceAccount를 선택합니다. 
principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/SERVICEACCOUNT

다음을 바꿉니다.

  • PROJECT_NUMBER: 숫자 프로젝트 번호입니다. 프로젝트 번호를 가져오려면 프로젝트 식별을 참조하세요.
  • PROJECT_ID: Google Cloud 프로젝트 ID입니다.
  • NAMESPACE: Kubernetes 네임스페이스입니다.
  • SERVICEACCOUNT: Kubernetes ServiceAccount 이름입니다.
UID로 ServiceAccount를 선택합니다. 
principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/kubernetes.serviceaccount.uid/SERVICEACCOUNT_UID

다음을 바꿉니다.

  • PROJECT_NUMBER: 숫자 프로젝트 번호입니다. 프로젝트 번호를 가져오려면 프로젝트 식별을 참조하세요.
  • PROJECT_ID: Fleet 프로젝트 ID입니다.
  • SERVICEACCOUNT_UID: API 서버에 있는 ServiceAccount 객체의 UID입니다.

다음 단계