혼합 트러스트 Fleet 워크로드에서 Google Cloud API에 인증

이 페이지에서는 Fleet 전반에서 혼합 트러스트 모델을 사용하는 Fleet에서 Compute Engine API 또는 AI Platform API와 같은Google Cloud API를 인증하도록 애플리케이션을 구성하는 방법을 설명합니다. Fleet에 공유 트러스트 모델이 있는 경우 공유 트러스트 Fleet 워크로드에서 Google Cloud API에 인증을 참조하세요.

이 페이지는 플랫폼 관리자 및 운영자와 Fleet 워크로드에서 Google CloudAPI로 프로그래매틱 방식으로 인증하려는 보안 엔지니어를 대상으로 합니다. Google Cloud문서에서 참조하는 사용자 역할 및 예시 태스크에 대해 자세히 알아보려면 일반 GKE Enterprise 사용자 역할 및 태스크를 참조하세요.

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

혼합 트러스트 환경을 위한 Fleet 워크로드 아이덴티티 제휴 정보

Fleet 워크로드 아이덴티티 제휴를 사용하면 특정 네임스페이스의 워크로드와 같은 Fleet의 항목에Google Cloud API 및 리소스에 대한 IAM 역할을 부여할 수 있습니다. 기본적으로 Fleet 호스트 프로젝트는 Google에서 관리하는 워크로드 아이덴티티 풀을 사용하여 Fleet 전체에서 항목의 ID를 프로비저닝합니다. 그러나 멀티테넌트 Fleet과 같은 혼합 트러스트 환경이나 독립형 클러스터를 실행하는 Fleet 호스트 프로젝트에서는 워크로드 및 클러스터의 하위 집합에 대해 별도의 자체 관리형 워크로드 아이덴티티 풀을 구성하는 것이 좋습니다.

자체 관리형 워크로드 아이덴티티 풀을 사용하는 항목은 IAM 정책에서 Fleet 호스트 프로젝트의 Google 관리 워크로드 아이덴티티 풀을 사용하는 항목과 다른 식별자를 가집니다. 이렇게 하면 특정 Fleet 네임스페이스의 주 구성원에게 액세스 권한을 부여해도 식별자와 일치하는 다른 주 구성원에게 의도치 않게 액세스 권한이 부여되지 않습니다.

자체 관리형 워크로드 아이덴티티 풀을 사용하려면 팀 범위를 사용해야 합니다. 팀 범위를 사용하면 팀별로 Fleet 리소스 하위 집합에 대한 액세스를 제어할 수 있습니다. 특정 팀이 해당 클러스터에 워크로드를 배포할 수 있도록 특정 팀 범위를 특정 Fleet 구성원 클러스터에 바인딩합니다. 팀 범위 내에서 팀 구성원은 Fleet 네임스페이스에만 워크로드를 배포할 수 있습니다.

자체 관리형 워크로드 아이덴티티 풀을 사용하여 팀 범위 워크로드에 ID를 제공하면 다음과 같은 이점이 있습니다.

  • Fleet 네임스페이스의 항목에 대한 액세스 권한 부여가 의도치 않게 다른 네임스페이스 또는 클러스터의 항목에 적용되지 않도록 합니다.
  • Fleet 클러스터 집합을 팀 범위에 바인딩하고 해당 클러스터에서 자체 관리형 풀을 ID 공급업체로 설정하여 자체 관리형 풀에서 ID를 가져오도록 구성합니다.
  • 특정 클러스터에서 자체 관리형 풀을 ID 공급업체로만 설정하여 자체 관리형 풀에서 ID를 가져오도록 팀 범위에 바인딩된 클러스터의 하위 집합을 구성합니다.

혼합 트러스트 환경의 ID 동일성 예시

다음 상황을 살펴보세요.

  • Fleet 구성원 클러스터가 2개 있습니다(frontend-clusterfinance-cluster).
  • 자체 관리형 워크로드 아이덴티티 풀을 구성하지 않았습니다.
  • 팀 범위에서 finance-team 팀 범위와 finance-ns Fleet 네임스페이스를 만듭니다.
  • finance-cluster 클러스터를 finance-team 팀 범위에 바인딩합니다.
  • finance-ns Fleet 네임스페이스의 finance-sa Kubernetes ServiceAccount에 IAM 역할을 부여합니다.

다음 기준을 충족하는 모든 워크로드는 동일한 ID를 공유합니다.

  • finance-ns Fleet 네임스페이스에서 실행합니다.
  • finance-sa ServiceAccount를 사용합니다.

그러나 frontend-cluster 클러스터의 사용자가 finance-ns Kubernetes 네임스페이스와 finance-sa 서비스 계정을 만들면 finance-cluster 클러스터의 워크로드와 동일한 ID를 갖게 됩니다. 이는 전체 Fleet이 Fleet 호스트 프로젝트의 Google 관리 워크로드 아이덴티티 풀을 사용하고, 기본 식별자가 호스트 클러스터를 지정하지 않기 때문입니다.

위 시나리오에 다음과 같은 변경사항을 고려합니다.

  • Fleet에 자체 관리형 워크로드 아이덴티티 풀을 설정합니다.
  • Google 관리 풀 대신 자체 관리형 풀에서 ID를 가져오도록 finance-cluster 클러스터를 구성합니다.
  • 주 구성원 식별자에 Google 관리 풀 대신 자체 관리형 풀을 지정하는 IAM 역할 부여를 만듭니다.

이제 finance-clusterfinance-ns Fleet 네임스페이스에서 실행되는 워크로드가 자체 관리형 풀에서 ID를 가져옵니다. 하지만 frontend-cluster 클러스터의 finance-ns Kubernetes 네임스페이스에 있는 항목은 계속해서 Fleet 호스트 프로젝트의 Google 관리 워크로드 아이덴티티 풀에서 ID를 가져옵니다.

이번 변경사항으로 인해 다음과 같은 이점이 있습니다.

  • finance-ns Fleet 네임스페이스의 항목에 명시적으로 역할을 부여할 수 있습니다.
  • frontend-cluster 클러스터의 ID는 Google 관리 워크로드 아이덴티티 풀에서 가져오므로 frontend-cluster 클러스터의 항목은 동일한 액세스 권한을 얻을 수 없습니다.

시작하기 전에

  • 다음 명령줄 도구가 설치되었는지 확인합니다.

    • Google Cloud와 상호작용하는 명령줄 도구인 gcloud가 포함된 최신 버전의 Google Cloud CLI
    • kubectl

    Google Cloud과의 상호작용을 위해 Cloud Shell을 셸 환경으로 사용하는 경우 이러한 도구가 자동으로 설치됩니다.

  • 프로젝트에 사용할 수 있도록 gcloud CLI를 초기화했는지 확인합니다.

요구사항

Fleet에서 팀 범위 및 Fleet 네임스페이스와 같은 Fleet팀 관리 기능을 사용해야 합니다. 이 페이지의 안내는 팀 범위 및 Fleet 네임스페이스 예시를 구성하는 방법을 보여줍니다.

클러스터 준비

Fleet의 애플리케이션이 제휴된 아이덴티티를 수신하려면 먼저 실행되는 클러스터가 Fleet에 등록되어 있어야 하며 Fleet 워크로드 아이덴티티 제휴를 사용하도록 올바르게 구성되어야 합니다. 다음 섹션에서는 다양한 유형의 클러스터에 대해 Fleet 워크로드 아이덴티티 제휴를 설정하는 방법을 설명합니다.

GKE

GKE 클러스터의 경우 다음을 수행합니다.

  1. Google Kubernetes Engine 클러스터에서 아직 사용 설정되지 않았다면 GKE용 워크로드 아이덴티티 제휴를 사용 설정합니다.
  2. Fleet에 클러스터를 등록합니다.

클러스터 생성 및 Fleet 등록 프로세스 중에 GKE용 워크로드 아이덴티티 제휴를 사용 설정할 수도 있습니다.

Google Cloud외부 클러스터

다음 유형의 클러스터는 Fleet 워크로드 아이덴티티 제휴를 자동으로 사용 설정하며 클러스터를 만드는 동안 Fleet에 등록됩니다.

  • VMware용 Google Distributed Cloud(소프트웨어 전용)
  • 베어메탈용 Google Distributed Cloud(소프트웨어 전용)
  • GKE on AWS
  • Azure 기반 GKE

연결된 클러스터

GKE Multi-Cloud API를 사용하여 등록된 EKS 및 AKS 연결 클러스터는 기본적으로 Fleet 워크로드 아이덴티티 제휴를 사용하도록 설정된 상태로 등록됩니다. 연결된 다른 클러스터는 필요한 요구사항을 충족하는 경우에만 사용 설정된 Fleet 워크로드 아이덴티티 제휴로 등록됩니다. 클러스터 등록에서 해당 클러스터 유형에 대한 안내를 따르세요.

IAM 워크로드 아이덴티티 풀 설정

이 섹션에서는 Fleet 호스트 프로젝트에 새 IAM 워크로드 아이덴티티 풀을 만들고 Fleet 서비스 에이전트에 새 풀에 대한 액세스 권한을 부여합니다.

  1. 워크로드 아이덴티티 풀 만들기

    gcloud iam workload-identity-pools create POOL_NAME \
        --location=global \
        --project=POOL_HOST_PROJECT_ID \
        --mode=TRUST_DOMAIN
    

    다음을 바꿉니다.

    • POOL_NAME: 새 워크로드 아이덴티티 풀의 이름입니다.
    • POOL_HOST_PROJECT_ID: 자체 관리형 워크로드 아이덴티티 풀을 만들려는 프로젝트의 프로젝트 ID입니다. Fleet 호스트 프로젝트를 비롯한 모든 Google Cloud 프로젝트를 사용할 수 있습니다.
  2. 새 워크로드 아이덴티티 풀에 대한 IAM 워크로드 아이덴티티 풀 관리자 역할(roles/iam.workloadIdentityPoolAdmin)을 Fleet 서비스 에이전트에 부여합니다.

    gcloud iam workload-identity-pools add-iam-policy-binding POOL_NAME \
        --project=POOL_HOST_PROJECT_ID \
        --location=global \
        --member=serviceAccount:service-FLEET_HOST_PROJECT_NUMBER@gcp-sa-gkehub.iam.gserviceaccount.com \
        --role=roles/iam.workloadIdentityPoolAdmin \
        --condition=None
    

    FLEET_HOST_PROJECT_NUMBER를 Fleet 호스트 프로젝트의 프로젝트 번호로 바꿉니다.

자체 관리형 풀을 Fleet 구성에 추가

이 섹션에서는 Fleet 워크로드 아이덴티티 제휴를 사용하여 자체 관리형 풀을 사용 설정하고 만든 풀을 Fleet 구성에 추가합니다. 이 섹션에서는 새 팀 범위와 Fleet 네임스페이스를 만드는 방법도 안내합니다. Fleet에 이미 팀 범위와 Fleet 네임스페이스가 구성되어 있으면 해당 단계를 건너뜁니다.

  1. Fleet 수준에서 Fleet 워크로드 아이덴티티 제휴를 사용 설정합니다.

    gcloud beta container fleet workload-identity enable \
      --project=FLEET_HOST_PROJECT_ID
    

    FLEET_HOST_PROJECT_ID를 Fleet 호스트 프로젝트의 프로젝트 ID로 바꿉니다.

  2. 자체 관리형 워크로드 아이덴티티 풀을 에이전트 구성에 추가합니다.

    gcloud beta container fleet workload-identity scope-tenancy-pool set POOL_NAME
    

    POOL_NAME을 자체 관리형 워크로드 아이덴티티 풀의 이름으로 바꿉니다. 이 값의 문법은 다음과 같습니다.

    POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog
    
  3. 새 팀 범위를 만듭니다. 기존 팀 범위 및 Fleet 네임스페이스가 있는 경우 워크로드 아이덴티티 풀 구성 확인 섹션으로 건너뜁니다.

    gcloud container fleet scopes create SCOPE_NAME
    

    SCOPE_NAME을 새 팀 범위의 이름으로 바꿉니다.

  4. 팀 범위에서 새 Fleet 네임스페이스를 만듭니다.

    gcloud container fleet scopes namespaces create NAMESPACE_NAME \
        --scope=SCOPE_NAME
    

    NAMESPACE_NAME을 새 Fleet 네임스페이스의 이름으로 바꿉니다.

  5. Fleet의 클러스터를 팀 범위에 바인딩합니다.

    gcloud container fleet memberships bindings create BINDING_NAME \
        --membership=FLEET_CLUSTER_NAME \
        --location=global \
        --scope=SCOPE_NAME
    

    다음을 바꿉니다.

    • BINDING_NAME: 새 멤버십 바인딩의 이름입니다.
    • FLEET_CLUSTER_NAME: 팀 범위에 바인딩할 기존 Fleet 클러스터의 이름입니다.

워크로드 아이덴티티 풀 구성 확인

이 섹션에서는 자체 관리형 워크로드 아이덴티티 풀 구성이 성공적으로 이루어졌는지 확인합니다.

  1. Fleet 멤버십 구성을 설명합니다.

    gcloud container fleet memberships describe FLEET_CLUSTER_NAME \
        --location=global
    

    FLEET_CLUSTER_NAME을 Fleet의 팀 범위에 바인딩된 기존 Fleet 클러스터의 이름으로 바꿉니다.

    출력은 다음과 비슷합니다.

    authority:
    ...
      scopeTenancyIdentityProvider: https://gkehub.googleapis.com/projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/FLEET_CLUSTER_NAME
      scopeTenancyWorkloadIdentityPool: POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog
      workloadIdentityPool: FLEET_HOST_PROJECT_ID.svc.id.goog
    ...
    

    이 출력에는 다음 필드가 포함되어야 합니다.

    • scopeTenancyIdentityProvider: 팀 범위 내의 Fleet 네임스페이스에서 실행되는 워크로드의 ID 공급업체입니다. 값은 클러스터의 리소스 식별자입니다.
    • scopeTenancyWorkloadIdentityPool: 팀 범위 내의 Fleet 네임스페이스에 있는 워크로드가 식별자를 가져오는 워크로드 아이덴티티 풀입니다. 값은 POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog 형식의 자체 관리형 워크로드 아이덴티티 풀입니다.
    • workloadIdentityPool: Fleet 호스트 프로젝트의 Google 관리 워크로드 아이덴티티 풀의 이름으로, 이 풀에서 Fleet의 다른 모든 워크로드가 기본적으로 ID를 가져옵니다.
  2. 선택사항: 워크로드 아이덴티티 풀에 Fleet 네임스페이스와 이름이 동일한 네임스페이스가 있는지 확인합니다.

    gcloud iam workload-identity-pools namespaces list \
        --workload-identity-pool=POOL_NAME \
        --location=global
    

    출력은 다음과 비슷합니다.

    ---
    description: Fleet namespace NAMESPACE_NAME
    name: projects/FLEET_HOST_PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_NAME/namespaces/NAMESPACE_NAME
    state: ACTIVE
    

이제 Fleet에서 자체 관리형 워크로드 아이덴티티 풀을 사용하여 Fleet 네임스페이스에서 실행되는 워크로드의 ID를 가져올 수 있습니다. 자체 관리형 풀을 사용하려면 다음 섹션에 설명된 대로 특정 클러스터가 ID를 가져오는 방법을 구성합니다.

워크로드에서 ID에 자체 관리형 풀을 사용하도록 설정

워크로드가 자체 관리형 풀을 사용하도록 하려면 Kubernetes ConfigMap을 사용하여 Fleet 구성원 클러스터에서 특정 Fleet 네임스페이스를 구성합니다. 이러한 클러스터별, 네임스페이스별 구성을 사용하면 전체 Fleet 네임스페이스에서 특정 클러스터의 특정 Fleet 네임스페이스에서 실행되는 워크로드까지 액세스 부여 범위를 더욱 줄일 수 있습니다.

  1. Fleet 구성원 클러스터에 연결합니다.

    gcloud container clusters get-credentials FLEET_CLUSTER_NAME \
        --project=CLUSTER_PROJECT_ID \
        --location=CLUSTER_LOCATION
    

    다음을 바꿉니다.

    • FLEET_CLUSTER_NAME: 이미 팀 범위에 바인딩된 Fleet 구성원 클러스터의 이름입니다.
    • CLUSTER_PROJECT_ID: 클러스터 프로젝트의 프로젝트 ID입니다.
    • CLUSTER_LOCATION: 클러스터의 위치입니다.
  2. 자체 관리형 워크로드 아이덴티티 풀의 전체 이름을 가져옵니다. 이 값은 나중에 필요합니다.

    kubectl get membership membership -o json | jq -r ".spec.scope_tenancy_workload_identity_pool"
    

    출력은 다음과 비슷합니다.

    POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog
    
  3. 팀 범위의 ID 공급업체 이름을 가져옵니다. 이 값은 나중에 필요합니다.

    kubectl get membership membership -o json | jq -r ".spec.scope_tenancy_identity_provider"
    

    출력은 다음과 비슷합니다.

    https://gkehub.googleapis.com/projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/FLEET_CLUSTER_NAME
    
  4. 텍스트 편집기에서 ConfigMap에 대해 다음 YAML 매니페스트를 self-managed-pool.yaml로 저장합니다:

    kind: ConfigMap
    apiVersion: v1
    metadata:
      namespace: NAMESPACE_NAME
      name: google-application-credentials
    data:
      config: |
        {
          "type": "external_account",
          "audience": "identitynamespace:SELF_MANAGED_POOL_FULL_NAME:IDENTITY_PROVIDER",
          "subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
          "token_url": "https://sts.googleapis.com/v1/token",
          "credential_source": {
            "file": "/var/run/secrets/tokens/gcp-ksa/token"
          }
        }
    

    다음을 바꿉니다.

    • NAMESPACE_NAME: Fleet 네임스페이스의 이름입니다.
    • SELF_MANAGED_POOL_FULL_NAME: 이 섹션의 이전 단계 출력에서 자체 관리형 워크로드 아이덴티티 풀의 전체 이름입니다. 예를 들면 example-pool.global.1234567890.workload.id.goog입니다.
    • IDENTITY_PROVIDER: 이 섹션의 이전 단계 출력에서 ID 공급업체 이름입니다. 예를 들면 https://gkehub.googleapis.com/projects/1234567890/locations/global/memberships/example-cluster.입니다.
  5. 클러스터에 ConfigMap을 배포합니다.

    kubectl create -f self-managed-pool.yaml
    

ConfigMap을 배포하면 해당 네임스페이스의 워크로드가 자체 관리형 워크로드 아이덴티티 풀을 사용하여 ID를 가져와야 한다고 GKE에 알립니다.

주 구성원에 IAM 역할 부여

이 섹션에서는 Fleet 네임스페이스에 Kubernetes ServiceAccount를 만들고 ServiceAccount에 IAM 역할을 부여합니다. 그러면 이 ServiceAccount를 사용하는 포드는 역할이 부여된 Google Cloud 리소스에 액세스할 수 있습니다.

  1. Fleet 네임스페이스에 Kubernetes ServiceAccount를 만듭니다.

    kubectl create serviceaccount SERVICEACCOUNT_NAME \
        --namespace=NAMESPACE_NAME
    

    다음을 바꿉니다.

    • SERVICEACCOUNT_NAME: 새 ServiceAccount의 이름입니다.
    • NAMESPACE_NAME: Fleet 네임스페이스의 이름입니다.
  2. ServiceAccount에 IAM 역할을 부여합니다. 다음 예시 명령어는 버킷에 대한 스토리지 객체 뷰어 역할(roles/storage.objectViewer)을 서비스 계정에 부여합니다.

    gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME \
        --member=principal://iam.googleapis.com/projects/FLEET_HOST_PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog/subject/ns/NAMESPACE_NAME/sa/SERVICEACCOUNT_NAME \
        --role=roles/storage.objectViewer \
        --condition=None
    

member 플래그에는 사용자가 만든 새 ServiceAccount의 주 구성원 식별자가 포함됩니다. 워크로드에서 Google CloudAPI로 전송하는 요청은 제휴된 액세스 토큰을 사용합니다. 이 제휴 액세스 토큰에는 요청을 전송하는 항목의 주 구성원 식별자가 포함됩니다. 대상 리소스에 역할을 부여하는 허용 정책의 주 구성원이 제휴 액세스 토큰의 주 구성원과 일치하면 인증 및 승인을 계속할 수 있습니다.

자체 관리형 풀을 사용하는 워크로드 배포

Fleet 네임스페이스에 적용하는 Kubernetes 매니페스트는 자체 관리형 풀에서 ID를 가져오도록 구성해야 합니다. Google Cloud API를 호출해야 하는 배포하는 워크로드에는 다음 필드가 포함되어야 합니다.

  • metadata.namespace: Fleet 네임스페이스의 이름입니다.
  • spec.serviceAccountName: Fleet 네임스페이스의 Kubernetes ServiceAccount 이름입니다.
  • spec.containers.env: 애플리케이션 기본 사용자 인증 정보(ADC) 파일의 경로를 나타내는 GOOGLE_APPLICATION_CREDENTIALS라는 환경 변수입니다.
  • spec.containers.volumeMounts: 컨테이너가 ServiceAccount의 Bearer 토큰을 사용할 수 있는 읽기 전용 볼륨입니다.
  • spec.volumes: ServiceAccount 토큰을 포드에 마운트하는 예상되는 볼륨입니다. 토큰의 대상은 자체 관리형 워크로드 아이덴티티 풀입니다. Fleet 워크로드 아이덴티티 제휴 구성이 포함된 ConfigMap이 볼륨의 소스입니다.

올바르게 구성된 매니페스트 파일의 예시는 워크로드에서 인증 확인 섹션을 참조하세요.

워크로드에서 인증 확인

이 섹션에서는 예시 Cloud Storage 버킷의 콘텐츠를 나열하여 자체 관리형 워크로드 아이덴티티 풀을 올바르게 구성했는지 확인할 수 있는 선택적 안내를 제공합니다. 버킷을 만들고, 버킷에 대한 역할을 Fleet 네임스페이스의 ServiceAccount에 부여하고, 포드를 배포하여 버킷에 액세스하려고 합니다.

  1. Cloud Storage 버킷을 만듭니다.

    gcloud storage buckets create gs://FLEET_HOST_PROJECT_ID-workload-id-bucket \
        --location=LOCATION \
        --project=FLEET_HOST_PROJECT_ID
    
  2. 버킷에 대한 roles/storage.objectViewer 역할을 Fleet 네임스페이스의 ServiceAccount에 부여합니다.

    gcloud storage buckets add-iam-policy-binding gs://FLEET_HOST_PROJECT_ID-workload-id-bucket \
        --condition=None \
        --role=roles/storage.objectViewer \
        --member=principal://iam.googleapis.com/projects/FLEET_PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog/subject/ns/NAMESPACE_NAME/sa/SERVICEACCOUNT_NAME
    

    다음을 바꿉니다.

    • FLEET_HOST_PROJECT_NUMBER: Fleet 호스트 프로젝트의 프로젝트 번호입니다.
    • POOL_NAME: 자체 관리형 워크로드 아이덴티티 풀의 이름입니다.
    • NAMESPACE_NAME: 포드를 실행하려는 Fleet 네임스페이스의 이름입니다.
    • SERVICEACCOUNT_NAME: 포드에서 사용해야 하는 Kubernetes ServiceAccount의 이름입니다.
  3. 다음 매니페스트를 pod-bucket-access.yaml로 저장합니다.

    apiVersion: v1
    kind: Pod
    metadata:
      name: bucket-access-pod
      namespace:  NAMESPACE_NAME
    spec:
      serviceAccountName: SERVICEACCOUNT_NAME
      containers:
      - name: sample-container
        image: google/cloud-sdk:slim
        command: ["sleep","infinity"]
        env:
        - name: GOOGLE_APPLICATION_CREDENTIALS
          value: /var/run/secrets/tokens/gcp-ksa/google-application-credentials.json
        volumeMounts:
        - name: gcp-ksa
          mountPath: /var/run/secrets/tokens/gcp-ksa
          readOnly: true
      volumes:
      - name: gcp-ksa
        projected:
          defaultMode: 420
          sources:
          - serviceAccountToken:
              path: token
              audience: POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog
              expirationSeconds: 172800
          - configMap:
              name: my-cloudsdk-config
              optional: false
              items:
              - key: "config"
                path: "google-application-credentials.json"
    

    다음을 바꿉니다.

    • NAMESPACE_NAME: 포드를 실행하려는 Fleet 네임스페이스의 이름입니다.
    • SERVICEACCOUNT_NAME: 포드에서 사용해야 하는 Kubernetes ServiceAccount의 이름입니다.
    • POOL_NAME: 자체 관리형 워크로드 아이덴티티 풀의 이름입니다.
    • FLEET_HOST_PROJECT_NUMBER: Fleet 호스트 프로젝트의 프로젝트 번호입니다.
  4. 클러스터에 포드를 배포합니다.

    kubectl apply -f pod-bucket-access.yaml
    
  5. 포드에서 셸 세션을 엽니다.

    kubectl exec -it bucket-access-pod -n NAMESPACE_NAME -- /bin/bash
    
  6. 버킷의 객체를 나열해 봅니다.

    curl -X GET -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
        "https://storage.googleapis.com/storage/v1/b/FLEET_HOST_PROJECT_ID-workload-id-bucket/o"
    

    출력은 다음과 같습니다.

    {
      "kind": "storage#objects"
    }
    

원하는 경우 다른 Fleet 구성원 클러스터의 유사한 네임스페이스와 ServiceAccount가 동일한 ID를 어설션할 수 없는지 확인할 수 있습니다. Fleet 워크로드 아이덴티티 제휴를 사용하지만 Fleet 네임스페이스 또는 자체 관리형 풀 구성이 없는 클러스터에서 다음 단계를 따르세요.

  1. 자체 관리형 워크로드 아이덴티티 풀을 설정하는 Fleet 네임스페이스와 동일한 이름으로 새 Kubernetes 네임스페이스를 만듭니다.
  2. 이전 섹션에서 IAM 역할을 부여한 ServiceAccount와 동일한 이름으로 새 Kubernetes ServiceAccount를 만듭니다.
  3. 동일한 ServiceAccount 및 네임스페이스를 사용하지만 spec.volumes.projected.sources.serviceAccountToken 필드에서 Google 관리 워크로드 아이덴티티 풀을 지정하는 포드를 배포합니다. 이 풀의 문법은 다음과 같습니다.

    FLEET_HOST_PROJECT_ID.svc.id.goog
    
  4. 포드의 셸 세션에서 Cloud Storage 버킷에 액세스하려고 시도합니다.

Google 관리 워크로드 아이덴티티 풀을 사용하는 포드의 기본 식별자는 자체 관리형 풀을 사용하는 포드의 기본 식별자와 다르므로 출력은 401: Unauthorized 오류여야 합니다.

다음 단계