Kubernetes로 워크로드 아이덴티티 제휴 구성

이 가이드에서는 워크로드 아이덴티티 제휴를 사용하여 Azure Kubernetes Service(AKS), Amazon Elastic Kubernetes, Service, 자체 호스팅 Kubernetes 클러스터에서 실행되는 워크로드가 Google Cloud에 인증하도록 하는 방법을 설명합니다.

Kubernetes를 사용하면 워크로드가 예상 볼륨에서 Kubernetes 서비스 계정 토큰을 가져올 수 있도록 클러스터를 구성할 수 있습니다. 워크로드 아이덴티티 제휴를 설정하면 워크로드에서 이러한 Kubernetes 서비스 계정 토큰을 사용하여 Google Cloud에 인증할 수 있습니다.

GKE를 사용하는 경우 워크로드 아이덴티티 제휴를 구성하는 대신 GKE용 워크로드 아이덴티티 제휴를 사용합니다.

시작하기 전에

워크로드 아이덴티티 제휴를 구성하기 전에 Kubernetes 클러스터가 다음 기준을 충족하는지 확인합니다.

GKE

Google Kubernetes Engine(GKE) 사용자의 경우 GKE 워크로드에서 Google Cloud API에 인증을 참조하세요.

AKS

클러스터가 다음 기준을 충족하는지 확인합니다.

  • OIDC 발급기관 기능을 사용 설정했습니다.

    워크로드 아이덴티티 제휴에서 OpenID Connect 메타데이터 및 클러스터의 JSON 웹 키 집합(JWKS)에 액세스할 수 있도록 이 기능을 사용 설정해야 합니다.

EKS

EKS 구성은 변경할 필요가 없습니다.

Kubernetes

클러스터가 다음 기준을 충족하는지 확인합니다.

  • Kubernetes 1.20 이상이 실행되고 있습니다.

    이전 버전의 Kubernetes는 이 문서의 안내와 호환되지 않는 다른 서비스 계정 토큰 형식을 사용했습니다.

  • ServiceAccount 토큰 볼륨 프로젝션을 지원하도록 kube-apiserver를 구성했습니다.

인터넷을 통해 클러스터에 액세스할 필요가 없습니다.

워크로드 아이덴티티 제휴 구성

Kubernetes 클러스터마다 이러한 단계를 한 번만 수행하면 됩니다. 그러면 여러 워크로드 포드와 여러 Google Cloud 프로젝트에서 같은 워크로드 아이덴티티 풀과 제공업체를 사용할 수 있습니다.

워크로드 아이덴티티 제휴 구성을 시작하려면 다음을 수행합니다.

  1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

    2. 전용 프로젝트를 사용하여 워크로드 아이덴티티 풀과 제공업체를 관리하는 것이 좋습니다.

  2. Make sure that billing is enabled for your Google Cloud project.

    3. Enable the IAM, Resource Manager, Service Account Credentials, and Security Token Service APIs.

    Enable the APIs

속성 매핑 및 조건 정의

Kubernetes 서비스 계정 토큰에는 다음을 포함한 여러 클레임이 있습니다.

  • sub: 서비스 계정의 네임스페이스와 이름을 포함합니다(예: system:serviceaccount:NAMESPACE:KSA_NAME). 여기서 NAMESPACE는 서비스 계정의 네임스페이스이고 KSA_NAME은 서비스 계정의 이름입니다.
  • "kubernetes.io".namespace: 서비스 계정의 네임스페이스를 포함합니다.
  • "kubernetes.io".serviceaccount.name: 서비스 계정의 이름을 포함합니다.
  • "kubernetes.io".pod.name: 포드의 이름을 포함합니다.

Google Cloud에서 sub를 주체 식별자(google.subject)로 사용하려면 다음 매핑을 사용합니다.

google.subject=assertion.sub

필요한 경우 추가 속성을 매핑할 수 있습니다. 그런 다음 리소스에 대한 액세스 권한을 부여할 때 이러한 속성을 참조할 수 있습니다. 예를 들면 다음과 같습니다.

google.subject=assertion.sub,
attribute.namespace=assertion['kubernetes.io']['namespace'],
attribute.service_account_name=assertion['kubernetes.io']['serviceaccount']['name'],
attribute.pod=assertion['kubernetes.io']['pod']['name']

선택적으로 속성 조건을 정의합니다. 속성 조건은 어설션 속성 및 대상 속성을 확인할 수 있는 CEL 표현식입니다. 어설션 조건이 특정 사용자 인증 정보에 대해 true로 평가되면 해당 사용자 인증 정보가 수락됩니다. 그렇지 않으면 사용자 인증 정보가 거부됩니다.

속성 조건을 사용하여 워크로드 아이덴티티 제휴를 사용해 단기 Google Cloud 토큰을 받을 수 있는 Kubernetes 서비스 계정을 제한할 수 있습니다. 예를 들어 다음 조건은 backend 및 monitoring 네임스페이스에서 Kubernetes 서비스 계정에 대한 액세스를 제한합니다.

assertion['kubernetes.io']['namespace'] in ['backend', 'monitoring']

워크로드 아이덴티티 풀 및 공급업체 만들기

필요한 역할

워크로드 아이덴티티 제휴를 구성하는 데 필요한 권한을 얻으려면 관리자에게 프로젝트에 대한 다음 IAM 역할을 부여해 달라고 요청합니다.

역할 부여에 대한 자세한 내용은 프로젝트, 폴더, 조직에 대한 액세스 관리를 참조하세요.

커스텀 역할이나 다른 사전 정의된 역할을 통해 필요한 권한을 얻을 수도 있습니다.

또는 IAM 소유자(roles/owner) 기본 역할에는 ID 제휴를 구성하는 권한도 포함됩니다. 프로덕션 환경에서는 기본 역할을 부여하지 말아야 하지만 개발 환경 또는 테스트 환경에서는 부여해도 됩니다.

워크로드 아이덴티티 풀과 제공업체를 만들려면 다음을 수행합니다.

AKS

  1. AKS 클러스터의 발급기관 URL을 확인합니다.

    az aks show -n NAME -g RESOURCE_GROUP --query "oidcIssuerProfile.issuerUrl" -otsv

    다음을 바꿉니다.

    • NAME: 클러스터 이름
    • RESOURCE_GROUP: 클러스터의 리소스 그룹

    이 명령어는 발급기관 URL을 출력합니다. 다음 단계 중 하나에서 발급기관 URL이 필요합니다.

    명령어가 발급기관 URL을 반환하지 않으면 OIDC 발급기관 기능을 사용 설정했는지 확인합니다.

  2. 새 워크로드 아이덴티티 풀을 만듭니다.

    gcloud iam workload-identity-pools create POOL_ID \
    --location="global" \
    --description="DESCRIPTION" \
    --display-name="DISPLAY_NAME"

    다음을 바꿉니다.

    • POOL_ID: 풀의 고유 ID
    • DISPLAY_NAME: 풀 이름
    • DESCRIPTION: 선택한 풀에 대한 설명 (이 설명은 풀 ID에 액세스 권한을 부여할 때 표시됩니다.)

  3. AKS 클러스터를 워크로드 아이덴티티 풀 제공업체로 추가합니다.

    gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID \
    --location="global" \
    --workload-identity-pool="POOL_ID" \
    --issuer-uri="ISSUER" \
    --attribute-mapping="MAPPINGS" \
    --attribute-condition="CONDITIONS"

    다음을 바꿉니다.

    • PROVIDER_ID: 선택한 고유 워크로드 아이덴티티 풀 공급업체 ID
    • POOL_ID: 앞에서 만든 워크로드 아이덴티티 풀 ID
    • ISSUER: 앞에서 확인한 발급기관 URI입니다.
    • MAPPINGS: 이 가이드 앞부분에서 만든 쉼표로 구분된 속성 매핑의 목록
    • CONDITIONS: 이 가이드 앞부분에서 만든 속성 조건(선택사항). 속성 조건이 없는 경우 매개변수를 삭제하세요.

EKS

  1. EKS 클러스터의 발급기관 URL을 확인합니다.

    aws eks describe-cluster --name NAME --query "cluster.identity.oidc.issuer" --output text

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

    이 명령어는 발급기관 URL을 출력합니다. 다음 단계 중 하나에서 발급기관 URL이 필요합니다.

  2. 새 워크로드 아이덴티티 풀을 만듭니다.

    gcloud iam workload-identity-pools create POOL_ID \
    --location="global" \
    --description="DESCRIPTION" \
    --display-name="DISPLAY_NAME"

    다음을 바꿉니다.

    • POOL_ID: 풀의 고유 ID
    • DISPLAY_NAME: 풀 이름
    • DESCRIPTION: 선택한 풀에 대한 설명 (이 설명은 풀 ID에 액세스 권한을 부여할 때 표시됩니다.)

  3. EKS 클러스터를 워크로드 아이덴티티 풀 제공업체로 추가합니다.

    gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID \
    --location="global" \
    --workload-identity-pool="POOL_ID" \
    --issuer-uri="ISSUER" \
    --attribute-mapping="MAPPINGS" \
    --attribute-condition="CONDITIONS"

    다음을 바꿉니다.

    • PROVIDER_ID: 선택한 고유 워크로드 아이덴티티 풀 공급업체 ID
    • POOL_ID: 앞에서 만든 워크로드 아이덴티티 풀 ID
    • ISSUER: 앞에서 확인한 발급기관 URI입니다.
    • MAPPINGS: 이 가이드 앞부분에서 만든 쉼표로 구분된 속성 매핑의 목록
    • CONDITIONS: 이 가이드 앞부분에서 만든 속성 조건(선택사항). 속성 조건이 없는 경우 매개변수를 삭제하세요.

Kubernetes

  1. Kubernetes 클러스터에 연결하고 kubectl을 사용하여 클러스터의 발급기관 URL을 확인합니다.

    kubectl get --raw /.well-known/openid-configuration | jq -r .issuer

    다음 단계 중 하나에서 발급기관 URL이 필요합니다.

  2. 클러스터의 JSON 웹 키 집합(JWKS)을 다운로드합니다.

    kubectl get --raw /openid/v1/jwks > cluster-jwks.json

    다음 단계 중 하나에서 워크로드 아이덴티티 제휴가 클러스터에서 발급한 Kubernetes 서비스 계정 토큰 신뢰성을 확인할 수 있도록 JWKS를 업로드합니다.

  3. 새 워크로드 아이덴티티 풀을 만듭니다.

    gcloud iam workload-identity-pools create POOL_ID \
    --location="global" \
    --description="DESCRIPTION" \
    --display-name="DISPLAY_NAME"

    다음을 바꿉니다.

    • POOL_ID: 풀의 고유 ID
    • DISPLAY_NAME: 풀 이름
    • DESCRIPTION: 선택한 풀에 대한 설명 (이 설명은 풀 ID에 액세스 권한을 부여할 때 표시됩니다.)

  4. Kubernetes 클러스터를 워크로드 아이덴티티 풀 제공업체로 추가하고 클러스터의 JWKS를 업로드합니다.

    gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID \
    --location="global" \
    --workload-identity-pool="POOL_ID" \
    --issuer-uri="ISSUER" \
    --attribute-mapping="MAPPINGS" \
    --attribute-condition="CONDITIONS" \
    --jwk-json-path="cluster-jwks.json"

    다음을 바꿉니다.

    • PROVIDER_ID: 선택한 고유 워크로드 아이덴티티 풀 공급업체 ID
    • POOL_ID: 앞에서 만든 워크로드 아이덴티티 풀 ID
    • ISSUER: 앞에서 확인한 발급기관 URI입니다.
    • MAPPINGS: 이 가이드 앞부분에서 만든 쉼표로 구분된 속성 매핑의 목록
    • CONDITIONS: 이 가이드 앞부분에서 만든 속성 조건(선택사항). 속성 조건이 없는 경우 매개변수를 삭제하세요.

Kubernetes 워크로드에 대한 액세스 권한 부여

이 섹션에서는 워크로드 아이덴티티 제휴 직접 리소스 액세스 또는 서비스 계정 가장을 사용하여 Google Cloud API에 액세스하도록 Kubernetes 워크로드를 구성하는 방법을 설명합니다.

Google Cloud에 액세스해야 하는 Kubernetes 워크로드마다 이러한 단계를 한 번 수행해야 합니다.

워크로드 아이덴티티 제휴를 사용하는 것이 좋습니다. 하지만 ID 제휴를 사용할 때는 특정 API 메서드에 제한사항이 적용될 수 있습니다. 제한사항 목록은 ID 제휴: 제품 및 제한 사항을 참조하세요.

워크로드에 사용되는 메서드에 이러한 제한사항이 포함된 경우 대신 IAM 가장을 사용할 수 있습니다.

워크로드 아이덴티티 제휴를 사용하여 리소스에 대한 직접 액세스 권한 부여

이 섹션에서는 Google Cloud 리소스에 직접 액세스할 수 있도록 워크로드 아이덴티티 제휴를 사용해서 Kubernetes ServiceAccount에 IAM 역할을 부여합니다.

Kubernetes ServiceAccount를 만들고 여기에 역할을 부여하려면 다음을 수행합니다.

  1. Kubernetes ServiceAccount를 만듭니다.

    kubectl create serviceaccount KSA_NAME --namespace NAMESPACE

    다음을 바꿉니다.

    • KSA_NAME: ServiceAccount의 이름입니다.
    • NAMESPACE: 서비스 계정을 만들 네임스페이스입니다.

  2. Kubernetes ServiceAccount에 Google Cloud 리소스에 대한 IAM 액세스 권한을 부여합니다.

    최소 권한의 원칙에 따라 애플리케이션이 액세스해야 하는 리소스에 대해서만 역할을 부여하는 것이 좋습니다.

    다음 예시에서 이 명령어는 사용자가 만든 ServiceAccount에 Kubernetes Engine 클러스터 뷰어(roles/container.clusterViewer) 역할을 부여합니다. 이 명령어는 이 문서의 앞부분에서 매핑한 주체를 사용합니다.

    gcloud projects add-iam-policy-binding projects/PROJECT_ID \
    --role=roles/container.clusterViewer \
    --member=principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/MAPPED_SUBJECT \
    --condition=None

    다음을 바꿉니다.

    • PROJECT_NUMBER: 프로젝트 ID와 연결된 Google Cloud 프로젝트 번호입니다.

    • POOL_ID: 워크로드 아이덴티티 풀 ID입니다.

    • MAPPED_SUBJECT: google.subject에 매핑한 ID 토큰의 클레임에서 가져온 Kubernetes ServiceAccount입니다. 예를 들어 google.subject=assertions.sub를 매핑했고 ID 토큰에 "sub": "system:serviceaccount:default:my-kubernetes-serviceaccount"가 포함된 경우에는 MAPPED_SUBJECT가 system:serviceaccount:default:my-kubernetes-serviceaccount입니다.

    IAM 허용 정책을 지원하는 모든 Google Cloud 리소스에 대한 역할을 부여할 수 있습니다. 주 구성원 식별자 구문은 Kubernetes 리소스에 따라 다릅니다. 지원되는 식별자 목록은 GKE용 워크로드 아이덴티티 제휴의 주 구성원 식별자를 참조하세요.

이제 Kubernetes ServiceAccount를 사용하는 워크로드를 배포하여 액세스 권한을 부여한 Google Cloud 리소스에 액세스할 수 있습니다.

대안: IAM 서비스 계정 가장 기능을 사용하여 액세스 권한 부여

IAM 서비스 계정 가장을 사용하도록 Kubernetes ServiceAccount를 구성하려면 다음을 수행합니다.

  1. Kubernetes ServiceAccount를 아직 만들지 않았으면 만듭니다.

    kubectl create serviceaccount KSA_NAME --namespace NAMESPACE

    다음을 바꿉니다.

    • KSA_NAME: ServiceAccount의 이름입니다.
    • NAMESPACE: 서비스 계정을 만들 네임스페이스입니다.

  2. 워크로드를 나타내는 IAM 서비스 계정을 만듭니다.

    서비스 계정은 워크로드 아이덴티티 풀과 동일한 프로젝트에 있을 필요가 없지만 이를 참조할 때 서비스 계정이 포함된 프로젝트를 지정해야 합니다.

    gcloud iam service-accounts create IAM_SA_NAME \
    --project=IAM_SA_PROJECT_ID

    다음을 바꿉니다.

    • IAM_SA_NAME: 서비스 계정의 이름입니다.
    • IAM_SA_PROJECT_ID: 서비스 계정의 프로젝트 ID입니다.

  3. Kubernetes 워크로드로 액세스하려는 특정 Google Cloud 리소스에 대한 액세스 권한을 IAM 서비스 계정에 부여합니다.

    gcloud projects add-iam-policy-binding IAM_SA_PROJECT_ID \
    --member="serviceAccount:IAM_SA_NAME@IAM_SA_PROJECT_ID.iam.gserviceaccount.com" \
    --role="ROLE"

    다음을 바꿉니다.

    • IAM_SA_PROJECT_ID: 서비스 계정을 만든 프로젝트의 ID입니다.
    • IAM_SA_NAME: 서비스 계정의 이름입니다.
    • ROLE: 역할 이름입니다(예: roles/container.clusterViewer).

  4. Kubernetes ServiceAccount에 IAM 서비스 계정을 가장하기 위한 액세스 권한을 부여합니다.

    gcloud iam service-accounts add-iam-policy-binding \
  IAM_SA_NAME@IAM_SA_PROJECT_ID.iam.gserviceaccount.com \
    --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/MAPPED_SUBJECT" \
    --role=roles/iam.workloadIdentityUser

    다음을 바꿉니다.

    • IAM_SA_NAME: 서비스 계정의 이름입니다.
    • PROJECT_ID: Kubernetes를 실행하는 프로젝트의 ID입니다.
    • IAM_SA_PROJECT_NUMBER: 서비스 계정을 만든 프로젝트의 프로젝트 번호입니다.
    • POOL_ID: 워크로드 아이덴티티 풀 ID입니다.
    • MAPPED_SUBJECT: google.subject에 매핑한 ID 토큰의 클레임에서 가져온 Kubernetes ServiceAccount입니다. 예를 들어 google.subject=assertions.sub를 매핑했고 ID 토큰에 "sub": "system:serviceaccount:default:my-kubernetes-serviceaccount"가 포함된 경우에는 MAPPED_SUBJECT가 system:serviceaccount:default:my-kubernetes-serviceaccount입니다.

    Google Cloud API에 액세스하도록 IAM 서비스 계정을 승인하는 방법에 대한 자세한 내용은 서비스 계정 이해를 참조하세요.

이제 Kubernetes ServiceAccount 및 IAM 서비스 계정을 사용하는 워크로드를 배포하여 액세스 권한을 부여한 Google Cloud 리소스에 액세스할 수 있습니다.

Kubernetes 워크로드 배포

Google Cloud 리소스에 액세스할 수 있는 Kubernetes 워크로드를 배포하려면 다음을 수행합니다.

  1. 사용자 인증 정보 구성 파일을 만듭니다.

    gcloud iam workload-identity-pools create-cred-config \
    projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID \
    --service-account=SERVICE_ACCOUNT_EMAIL \
    --credential-source-file=/var/run/service-account/token \
    --credential-source-type=text \
    --output-file=credential-configuration.json

    다음을 바꿉니다.

    • PROJECT_NUMBER: 워크로드 아이덴티티 풀이 포함된 프로젝트의 프로젝트 번호
    • POOL_ID: 워크로드 아이덴티티 풀의 ID
    • PROVIDER_ID: 워크로드 아이덴티티 풀 공급업체의 ID
    • SERVICE_ACCOUNT_EMAIL: IAM 서비스 계정 가장을 사용하도록 Kubernetes ServiceAccount를 구성한 경우 서비스 계정의 이메일 주소입니다. 직접 리소스 액세스를 사용하도록 Kubernetes ServiceAccount를 구성한 경우 이 플래그를 생략합니다.

    사용자 인증 정보 구성 파일을 사용하면 Cloud 클라이언트 라이브러리, gcloud CLI, Terraform에서 다음을 확인할 수 있습니다.

    • 외부 사용자 인증 정보를 가져올 위치
    • 사용할 워크로드 아이덴티티 풀 및 공급업체
    • 가장할 서비스 계정

  2. 사용자 인증 정보 구성 파일을 ConfigMap으로 가져오기

    kubectl create configmap CONFIGMAP_NAME \
  --from-file credential-configuration.json \
  --namespace NAMESPACE

    다음을 바꿉니다.

    • CONFIGMAP_NAME: ConfigMap 이름입니다.
    • NAMESPACE: ConfigMap을 만들 네임스페이스입니다.

  3. 워크로드를 배포하고 Kubernetes 서비스 계정과 ConfigMap을 사용하도록 합니다.

    매니페스트를 만들고 다음과 같이 구성합니다.

    • 워크로드가 로컬 파일에서 Kubernetes 서비스 계정 토큰을 가져올 수 있도록 예상 토큰 볼륨을 마운트합니다. Kubernetes 서비스 계정 토큰이 워크로드 아이덴티티 풀 공급업체에서 예상하는 대상을 사용하도록 볼륨을 구성합니다.
    • 워크로드가 워크로드 아이덴티티 제휴 사용을 위해 필요한 구성에 액세스할 수 있도록 사용자 인증 정보 구성 파일이 포함된 ConfigMap을 마운트합니다.
    • 워크로드에서 파일을 찾을 수 있도록 사용자 인증 정보 구성 파일의 경로가 포함된 GOOGLE_APPLICATION_CREDENTIALS 환경 변수를 추가합니다.

    다음은 Kubernetes 서비스 계정과 ConfigMap을 사용하여 Google Cloud CLI가 Google Cloud에 인증하도록 하는 매니페스트 예시입니다.

    apiVersion: v1
kind: Pod
metadata:
  name: example
  namespace: NAMESPACE
spec:
  containers:
  - name: example
    image: google/cloud-sdk:alpine
    command: ["/bin/sh", "-c", "gcloud auth login --cred-file $GOOGLE_APPLICATION_CREDENTIALS && gcloud auth list && sleep 600"]
    volumeMounts:
    - name: token
      mountPath: "/var/run/service-account"
      readOnly: true
    - name: workload-identity-credential-configuration
      mountPath: "/etc/workload-identity"
      readOnly: true
    env:
    - name: GOOGLE_APPLICATION_CREDENTIALS
      value: "/etc/workload-identity/credential-configuration.json"

  serviceAccountName: KSA_NAME
  volumes:
  - name: token
    projected:
      sources:
      - serviceAccountToken:
          audience: https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID
          expirationSeconds: 3600
          path: token
  - name: workload-identity-credential-configuration
    configMap:
      name: CONFIGMAP_NAME

    다음 클라이언트 라이브러리 중 하나를 사용하는 도구와 워크로드에서 자동으로 사용자 인증 정보를 찾을 수 있도록 같은 방법을 사용할 수 있습니다.

    C++

    C++용 Google Cloud 클라이언트 라이브러리는 버전 v2.6.0부터 워크로드 아이덴티티 제휴를 지원합니다. 워크로드 아이덴티티 제휴를 사용하려면 gRPC 버전 1.36.0 이상을 사용하여 클라이언트 라이브러리를 빌드해야 합니다.

    Go

    Go용 클라이언트 라이브러리에서 golang.org/x/oauth2 모듈 버전 v0.0.0-20210218202405-ba52d332ba99 이상을 사용하면 워크로드 아이덴티티 제휴가 지원됩니다.

    클라이언트 라이브러리에서 사용하는 이 모듈 버전을 확인하려면 다음 명령어를 실행합니다.

    cd $GOPATH/src/cloud.google.com/go
go list -m golang.org/x/oauth2

    자바

    Java용 클라이언트 라이브러리에서 com.google.auth:google-auth-library-oauth2-http 아티팩트 버전 0.24.0 이상을 사용하면 워크로드 아이덴티티 제휴가 지원됩니다.

    클라이언트 라이브러리에서 사용하는 이 아티팩트의 버전을 확인하려면 애플리케이션 디렉터리에서 다음 Maven 명령어를 실행합니다.

    mvn dependency:list -DincludeArtifactIds=google-auth-library-oauth2-http

    Node.js

    Node.js용 클라이언트 라이브러리에서 google-auth-library 패키지 버전 7.0.2 이상을 사용하면 워크로드 아이덴티티 제휴가 지원됩니다.

    클라이언트 라이브러리에서 사용하는 이 패키지의 버전을 확인하려면 애플리케이션 디렉터리에서 다음 명령어를 실행합니다.

    npm list google-auth-library

    GoogleAuth 객체를 만들 때 프로젝트 ID를 지정하거나 GoogleAuth가 프로젝트 ID를 자동으로 찾도록 허용할 수 있습니다. 프로젝트 ID를 자동으로 찾으려면 구성 파일의 서비스 계정에 프로젝트에 대한 브라우저 역할(roles/browser) 또는 동등한 권한이 있는 역할이 있어야 합니다. 자세한 내용은 google-auth-library 패키지용 README를 참조하세요.

    Python

    Python용 클라이언트 라이브러리에서 google-auth 패키지 버전 1.27.0 이상을 사용하면 워크로드 아이덴티티 제휴가 지원됩니다.

    클라이언트 라이브러리에서 사용하는 이 패키지의 버전을 확인하려면 패키지가 설치된 환경에서 다음 명령어를 실행합니다.

    pip show google-auth

    인증 클라이언트의 프로젝트 ID를 지정하려면 GOOGLE_CLOUD_PROJECT 환경 변수를 설정하거나 클라이언트가 프로젝트 ID를 자동으로 찾도록 허용할 수 있습니다. 프로젝트 ID를 자동으로 찾으려면 구성 파일의 서비스 계정에 프로젝트에 대한 브라우저 역할(roles/browser) 또는 동등한 권한이 있는 역할이 있어야 합니다. 자세한 내용은 google-auth 패키지 사용자 가이드를 참조하세요.

    gcloud

    워크로드 아이덴티티 제휴를 사용하여 인증하려면 gcloud auth login 명령어를 사용합니다.

    gcloud auth login --cred-file=FILEPATH.json

    FILEPATH를 사용자 인증 정보 구성 파일의 경로로 바꿉니다.

    gcloud CLI에서 워크로드 아이덴티티 제휴는 gcloud CLI 버전 363.0.0 이상에서 지원됩니다.

    Terraform

    버전 3.61.0 이상을 사용하는 경우 Google Cloud 공급업체가 워크로드 아이덴티티 제휴를 지원합니다.

    terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 3.61.0"
    }
  }
}

    bq

    워크로드 아이덴티티 제휴를 사용하여 인증하려면 다음과 같이 gcloud auth login 명령어를 사용합니다.

    gcloud auth login --cred-file=FILEPATH.json

    FILEPATH를 사용자 인증 정보 구성 파일의 경로로 바꿉니다.

    bq에서 워크로드 아이덴티티 제휴는 gcloud CLI 버전 390.0.0 이상에서 지원됩니다.

  4. 선택적으로 다음 명령어를 실행하여 인증이 올바르게 작동하는지 확인합니다.

    kubectl exec example --namespace NAMESPACE -- gcloud auth print-access-token

다음 단계