워크로드 아이덴티티 사용

이 페이지에서는 Google Kubernetes Engine(GKE) 애플리케이션을 통해 Google API에서 제공하는 서비스를 사용하는 권장 방법을 설명합니다.

개요

워크로드 아이덴티티는 향상된 보안 속성 및 관리 편의성으로 인해 GKE 내에서 실행되는 애플리케이션에서 Google Cloud 서비스에 액세스하는 데 권장되는 방식입니다. GKE에서 Google Cloud APIs에 액세스하는 다른 방법은 아래의 대안 섹션을 참조하세요.

용어

이 문서에서는 Kubernetes 서비스 계정Google 서비스 계정 을 구분합니다. Kubernetes 서비스 계정은 Kubernetes 리소스이고 Google 서비스 계정은 Google Cloud에만 해당됩니다. 다른 Google Cloud 문서에서는 Google 서비스 계정을 '서비스 계정'이라고 합니다.

개념

GKE에서 실행되는 애플리케이션은 Compute API, Storage 및 Database API, Machine Learning API와 같은 Google Cloud API를 사용하도록 인증해야 합니다.

워크로드 아이덴티티를 사용하면 Kubernetes 서비스 계정Google 서비스 계정 역할을 하도록 구성할 수 있습니다. Kubernetes 서비스 계정으로 실행되는 모든 애플리케이션은 Google Cloud APIs에 액세스할 때 자동으로 Google 서비스 계정으로 인증됩니다. 이렇게 하면 클러스터의 애플리케이션에 대해 세분화된 ID 및 승인을 할당할 수 있습니다.

Kubernetes 서비스 계정과 Google 서비스 계정 간의 안전한 매핑을 위해 워크로드 아이덴티티는 클러스터의 워크로드 아이덴티티 풀 개념을 도입하여 IAM(ID 및 액세스 관리)이 Kubernetes 서비스 계정 사용자 인증 정보를 신뢰하고 이해할 수 있도록 합니다.

GKE 클러스터에서 워크로드 아이덴티티를 사용 설정할 때는 클러스터의 워크로드 아이덴티티 풀을 my-pool.svc.id.goog로 설정합니다. 이렇게 하면 IAM은 Kubernetes 서비스 계정을 다음 구성원 이름으로 인증합니다.

serviceAccount:my-pool.svc.id.goog[k8s-namespace/ksa-name]

이 구성원 이름에서 각 항목의 의미는 다음과 같습니다.

  • my-pool.svc.id.goog는 클러스터에 설정된 워크로드 아이덴티티 풀 집합입니다.
  • ksa-name은 요청을 수행하는 Kubernetes 서비스 계정의 이름입니다.
  • k8s-namespace는 Kubernetes 서비스 계정이 정의된 Kubernetes 네임스페이스입니다.

Google Cloud 프로젝트별로 하나의 고정된 워크로드 아이덴티티 풀인 project-id.svc.id.goog만 있으며, 자동으로 생성됩니다.

클러스터 간 ID 공유

이름, 네임스페이스 이름, 워크로드 아이덴티티 풀을 공유하는 모든 Kubernetes 서비스 계정은 같은 구성원 이름으로 확인되므로 Google Cloud 리소스에 대한 액세스 권한을 공유합니다. 이는 여러 클러스터에 동일한 ID가 포함되는 경우 유용할 수 있지만 Kubernetes 서비스 계정 이름과 네임스페이스를 신중하게 관리하지 않으면 위험할 수 있습니다.

예를 들어 워크로드 아이덴티티가 클러스터에 사용 설정된 경우 다음 명령어를 사용하면 기본 서비스 계정과 네임스페이스를 사용하는 프로젝트의 모든 클러스터에 있는 모든 Kubernetes 워크로드에 대해 동일한 액세스 권한을 부여합니다.

gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:project-id.svc.id.goog[default/default]" \
  gsa-name@project-id.iam.gserviceaccount.com

제한사항

  • 현재까지는 Google Cloud 프로젝트별로 하나의 고정된 워크로드 아이덴티티 풀인 project-id.svc.id.goog만 있으며, 자동으로 생성됩니다.

  • 워크로드가 GKE On-Prem 클러스터에서 실행될 때는 워크로드 아이덴티티가 현재 지원되지 않습니다.

  • 워크로드 아이덴티티는 메타데이터 숨김을 사용해야 할 필요성을 대체하며, 따라서 두 접근 방법은 상호 호환되지 않습니다. 메타데이터 숨김으로 보호되는 민감한 메타데이터는 워크로드 아이덴티티로도 보호됩니다.

  • 노드 풀에서 GKE 메타데이터 서버를 사용 설정하면 Pod가 더 이상 Compute Engine 메타데이터 서버에 액세스할 수 없습니다. 대신 이러한 Pod에서 메타데이터 API로 전송된 요청은 GKE 메타데이터 서버로 라우팅됩니다. 호스트 네트워크에서 실행되는 Pod는 예외입니다(다음 항목 참조).

  • 워크로드 아이덴티티는 호스트 네트워크에서 실행 중인 Pod에서 사용할 수 없습니다. 이러한 Pod에서 메타데이터 API로 전송된 요청은 Compute Engine 메타데이터 서버로 라우팅됩니다.

  • GKE 메타데이터 서버가 새로 생성된 Pod에서 실행되는 데는 몇 초 정도 걸립니다. 따라서 Pod 수명의 처음 몇 초 내에 생성된 워크로드 아이덴티티를 사용하여 인증 또는 승인을 시도하면 실패할 수 있습니다. 이 문제는 호출을 다시 시도하면 해결됩니다.

  • GKE 로깅 및 모니터링 에이전트는 노드의 서비스 계정을 계속 사용합니다.

  • 워크로드 아이덴티티는 Windows 노드에서 지원되지 않습니다.

  • 요청 측정항목 출시를 계속하려면 메트릭 워크로드 아이덴티티에 Google Cloud의 Cloud Run for Anthos 수동 설정이 필요합니다.

  • 클러스터가 --disable-default-snat 플래그 없이 생성된 경우 워크로드 아이덴티티는 ip-masq-agent를 설치합니다.

시작하기 전에

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

다음 방법 중 하나를 사용하여 기본 gcloud 설정을 진행합니다.

  • gcloud init를 사용하여 기본값 설정 과정을 진행합니다.
  • gcloud config를 사용하여 프로젝트 ID, 영역, 리전을 개별적으로 설정합니다.

gcloud init 사용

One of [--zone, --region] must be supplied: Please specify location 오류가 표시되면 이 섹션을 완료합니다.

  1. gcloud init를 실행하고 다음 안내를 따르세요.

    gcloud init

    원격 서버에서 SSH를 사용하는 경우 --console-only 플래그를 사용하여 다음 명령어로 브라우저를 실행하지 못하게 할 수 있습니다.

    gcloud init --console-only
  2. 안내를 따라 gcloud에서 Google Cloud 계정을 사용하도록 승인합니다.
  3. 새 구성을 만들거나 기존 구성을 선택합니다.
  4. Google Cloud 프로젝트를 선택합니다.
  5. 기본 Compute Engine 영역을 선택합니다.

gcloud config 사용

  • 기본 프로젝트 ID를 설정합니다.
    gcloud config set project project-id
  • 영역 클러스터를 사용하는 경우 기본 컴퓨팅 영역을 설정합니다.
    gcloud config set compute/zone compute-zone
  • 리전 클러스터를 사용하는 경우 기본 컴퓨팅 리전을 설정합니다.
    gcloud config set compute/region compute-region
  • gcloud를 최신 버전으로 업데이트합니다.
    gcloud components update

클러스터에서 워크로드 아이덴티티 사용 설정

gcloud 도구를 사용하여 새 클러스터 또는 기존 클러스터에서 워크로드 아이덴티티를 사용 설정할 수 있습니다.

  1. IAM Service Account Credentials API를 사용 설정했는지 확인합니다.

    IAM Credentials API 사용 설정

  2. 워크로드 아이덴티티가 사용 설정된 새 클러스터를 만들려면 다음 명령어를 사용합니다.

    gcloud container clusters create cluster-name \
      --workload-pool=project-id.svc.id.goog
    

    다음을 바꿉니다.

    • cluster-name: 클러스터 이름입니다.
    • project-id: Google Cloud 프로젝트의 ID입니다.

    이 작업에는 프로젝트에 대한 container.clusters.create 권한이 필요합니다.

  3. 기존 클러스터에서 워크로드 아이덴티티를 사용 설정하려면 다음 명령어를 사용하여 클러스터를 수정합니다.

    gcloud container clusters update cluster-name \
      --workload-pool=project-id.svc.id.goog
    

    기존 노드 풀은 영향을 받지 않으며 새 노드 풀은 --workload-metadata=GKE_METADATA로 기본 설정됩니다.

    이 작업에는 클러스터에 대한 container.clusters.update 권한이 필요합니다.

워크로드 아이덴티티로 애플리케이션 마이그레이션

환경에 적합한 마이그레이션 전략을 선택합니다. 노드 풀을 제자리에서 마이그레이션하거나 워크로드 아이덴티티가 사용 설정된 새 노드 풀을 만들 수 있습니다. 이 기능과 호환되도록 애플리케이션을 수정해야 하는 경우 새 노드 풀을 만드는 것이 좋습니다.

워크로드 아이덴티티가 사용 설정된 클러스터에 노드 풀을 추가하고 해당 풀로 워크로드를 수동으로 마이그레이션합니다. 이 작업은 클러스터에서 워크로드 아이덴티티가 사용 설정된 경우에만 성공합니다.

gcloud container node-pools create nodepool-name \
  --cluster=cluster-name \
  --workload-metadata=GKE_METADATA

클러스터에 워크로드 아이덴티티가 사용 설정된 경우 --workload-metadata=GCE_METADATA를 명시적으로 지정하여 특정 노드 풀에서 선택적으로 사용 중지할 수 있습니다. 자세한 내용은 클러스터 메타데이터 보호를 참조하세요.

옵션 2: 노드 풀 수정

기존 노드 풀을 수정하여 GKE_METADATA를 사용 설정합니다. 이 업데이트는 클러스터에서 워크로드 아이덴티티가 사용 설정된 경우에만 성공합니다. 노드 풀에 배포된 워크로드에 대해 즉시 워크로드 아이덴티티가 사용 설정됩니다. 이 변경사항으로 인해 워크로드가 Compute Engine 서비스 계정을 사용할 수 없으므로 주의해서 롤아웃해야 합니다.

gcloud container node-pools update nodepool-name \
  --cluster=cluster-name \
  --workload-metadata=GKE_METADATA

이 작업에는 프로젝트에 대한 container.nodes.update 권한이 필요합니다.

Google Cloud에 인증

이 섹션에서는 워크로드 아이덴티티를 사용하여 애플리케이션이 Google Cloud에 인증하는 방법을 설명합니다. 이렇게 하려면 애플리케이션에 Kubernetes 서비스 계정을 할당하고 Google 서비스 계정 역할을 하도록 구성합니다.

  1. 클러스터와 통신하도록 kubectl을 구성합니다.

    gcloud container clusters get-credentials cluster-name
    

    cluster-name을 앞의 단계에서 만든 클러스터의 이름으로 바꿉니다.

    이 작업에는 프로젝트에 대한 container.clusters.get 권한이 필요합니다.

  2. 다른 대부분의 리소스와 마찬가지로 Kubernetes 서비스 계정은 네임스페이스에 유지됩니다. Kubernetes 서비스 계정에 사용할 네임스페이스를 만듭니다.

    kubectl create namespace k8s-namespace
    

    이 작업을 수행하려면 클러스터 내에서 네임스페이스 RBAC 만들기 권한이 필요합니다.

  3. 애플리케이션에 사용할 Kubernetes 서비스 계정을 만듭니다.

    kubectl create serviceaccount --namespace k8s-namespace ksa-name
    

    다음을 바꿉니다.

    • k8s-namespace: 이전 단계에서 만든 Kubernetes 네임스페이스의 이름입니다.
    • ksa-name: Kubernetes 서비스 계정에 사용할 이름입니다.

    이 작업에는 네임스페이스 내에서 serviceaccounts RBAC 만들기 권한이 필요합니다.

    또는 기본 네임스페이스를 사용하거나 아무 네임스페이스의 기본 Kubernetes 서비스 계정을 사용할 수 있습니다.

  4. 애플리케이션용 Google 서비스 계정을 만듭니다. 기존 서비스 계정이 있는 경우 새 서비스 계정을 만드는 대신 해당 계정을 사용할 수 있습니다. 서비스 계정은 클러스터와 동일한 프로젝트에 있지 않아도 됩니다. 조직의 모든 Google 서비스 계정을 사용할 수 있습니다.

    gcloud

    gsa-name을 선택한 서비스 계정 이름으로 바꿉니다.

    gcloud iam service-accounts create gsa-name
    

    구성 커넥터

    클러스터에 구성 커넥터가 이미 설치되어 있는 경우 구성 커넥터 구성을 사용하여 워크로드 아이덴티티가 사용 설정된 새 GKE 클러스터를 만들 수 있습니다.

    참고: 이 단계에는 구성 커넥터가 필요합니다. 설치 안내를 따라 클러스터에 구성 커넥터를 설치합니다.

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
    kind: IAMServiceAccount
    metadata:
      name: [GSA_NAME]
    spec:
      displayName: [GSA_NAME]
    이 매니페스트를 배포하려면 머신에 service-account.yaml로 다운로드합니다. 선택한 서비스 계정 이름으로 gsa-name을 바꿉니다. 그런 다음 kubectl를 사용하여 매니페스트를 적용합니다.

    kubectl apply -f service-account.yaml

    이 작업에는 프로젝트에 대한 iam.serviceAccounts.create 권한이 필요합니다.

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

  5. Kubernetes 서비스 계정이 두 계정 간에 IAM 정책 binding을 만들어 Google 서비스 계정을 가장하도록 허용합니다. 이 바인딩은 Kubernetes 서비스 계정이 Google 서비스 계정으로 작동하도록 허용합니다.

    gcloud

    gcloud iam service-accounts add-iam-policy-binding \
      --role roles/iam.workloadIdentityUser \
      --member "serviceAccount:project-id.svc.id.goog[k8s-namespace/ksa-name]" \
      gsa-name@project-id.iam.gserviceaccount.com
    

    구성 커넥터

    참고: 이 단계에는 구성 커넥터가 필요합니다. 설치 안내를 따라 클러스터에 구성 커넥터를 설치합니다.

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
    kind: IAMPolicy
    metadata:
      name: iampolicy-workload-identity-sample
    spec:
      resourceRef:
        apiVersion: iam.cnrm.cloud.google.com/v1beta1
        kind: IAMServiceAccount
        name: [GSA_NAME]
      bindings:
        - role: roles/iam.workloadIdentityUser
          members:
            - serviceAccount:[PROJECT_ID].svc.id.goog[[K8S_NAMESPACE]/[KSA_NAME]]
    이 매니페스트를 배포하려면 머신에 policy-binding.yaml로 다운로드합니다. gsa-name, project-id, k8s-namespace, ksa-name를 사용자 환경에 해당하는 값으로 바꿉니다. 그런 후 다음을 실행합니다.

    kubectl apply -f policy-binding.yaml

    이 작업에는 프로젝트에 대한 iam.serviceAccounts.setIamPolicy 권한이 필요합니다.

  6. Google 서비스 계정의 이메일 주소를 사용하여 Kubernetes 서비스 계정에 iam.gke.io/gcp-service-account=gsa-name@project-id 주석을 추가합니다.

    kubectl

    kubectl annotate serviceaccount \
      --namespace k8s-namespace \
      ksa-name \
      iam.gke.io/gcp-service-account=gsa-name@project-id.iam.gserviceaccount.com
    

    yaml

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      annotations:
        iam.gke.io/gcp-service-account: gsa-name@project-id.iam.gserviceaccount.com
      name: ksa-name
      namespace: k8s-namespace
    

    이 작업을 수행하려면 Kubernetes 서비스 계정에 대한 RBAC 수정 권한이 필요합니다.

  7. cloud-sdk 컨테이너 이미지를 실행하는 Kubernetes 서비스 계정으로 Pod를 만들고 대화형 세션으로 연결하여 서비스 계정이 올바르게 구성되었는지 확인합니다.

    kubectl

    kubectl run -it \
      --image google/cloud-sdk:slim \
      --serviceaccount ksa-name \
      --namespace k8s-namespace \
      workload-identity-test
    

    yaml

    apiVersion: v1
    kind: Pod
    metadata:
      name: workload-identity-test
      namespace: k8s-namespace
    spec:
      containers:
      - image: google/cloud-sdk:slim
        name: workload-identity-test
        command: ["sleep","infinity"]
      serviceAccountName: ksa-name
    

    google/cloud-sdk 이미지에는 Google Cloud API를 사용하기에 편리한 gcloud 명령줄 도구가 포함됩니다. 이미지를 다운로드하는 데 다소 시간이 걸릴 수 있습니다.

    이 작업을 수행하려면 네임스페이스 내에서 Pod RBAC 만들기 권한이 필요합니다.

    이제 생성된 Pod 내에서 대화형 셸에 연결되었습니다. pod 내에서 다음 명령어를 실행합니다.

    gcloud auth list
    

    서비스 계정이 올바르게 구성되었다면 Google 서비스 계정 이메일 주소가 유일한 활성 ID로 표시됩니다. 이는 기본적으로 pod가 Google Cloud API를 호출할 때 Google 서비스 계정의 권한을 사용함을 보여줍니다.

코드에서 워크로드 아이덴티티 사용

코드에서 Google Cloud 서비스로 인증하는 것은 Compute Engine 메타데이터 서버를 사용하여 인증하는 것과 동일한 프로세스입니다. 워크로드 아이덴티티를 사용할 때 인스턴스 메타데이터 서버에 대한 요청은 GKE 메타데이터 서버로 라우팅됩니다. 인스턴스 메타데이터 서버를 사용하여 인증하는 기존 코드(예: Google Cloud 클라이언트 라이브러리를 사용하는 코드)는 수정 없이도 작동합니다.

GKE 메타데이터 서버 이해

GKE 메타데이터 서버는 Kubernetes에 사용하도록 설계된 새로운 메타데이터 서버입니다. 이 서버는 각 클러스터 노드에서 하나의 Pod를 사용하는 daemonset로 실행됩니다. 메타데이터 서버는 GET /computeMetadata/v1/instance/service-accounts/default/token과 같은 요청을 포함하여 http://metadata.google.internal(169.254.169.254:80)에 대한 HTTP 요청을 가로채서 Pod가 역할을 수행하도록 구성된 Google 서비스 계정의 토큰을 검색합니다. 메타데이터 서버에 대한 트래픽은 Pod를 호스팅하는 VM 인스턴스를 벗어나지 않습니다.

GKE 메타데이터 서버는 Kubernetes 워크로드에 관련성이 높고 안전한 Compute Engine 메타데이터 서버 엔드포인트의 하위 집합만 구현합니다.

  • /computeMetadata/v1/instance/attributes/cluster-location
  • /computeMetadata/v1/instance/attributes/cluster-name
  • /computeMetadata/v1/instance/attributes/cluster-uid
  • /computeMetadata/v1/instance/hostname
  • /computeMetadata/v1/instance/id
  • /computeMetadata/v1/project/numeric-project-id
  • /computeMetadata/v1/project/project-id
  • /computeMetadata/v1/instance/service-accounts
  • /computeMetadata/v1/instance/service-accounts/default
  • /computeMetadata/v1/instance/service-accounts/default/aliases
  • /computeMetadata/v1/instance/service-accounts/default/email
  • /computeMetadata/v1/instance/service-accounts/default/identity
  • /computeMetadata/v1/instance/service-accounts/default/identity?audience=audience
  • /computeMetadata/v1/instance/service-accounts/default/scopes
  • /computeMetadata/v1/instance/service-accounts/default/token
  • /computeMetadata/v1/instance/service-accounts/default/token?scopes=comma-separated-list-of-scopes

액세스 권한 취소

  1. IAM을 사용하여 Google 서비스 계정에 대한 액세스 권한을 취소합니다.

    gcloud

    gcloud iam service-accounts remove-iam-policy-binding \
      --role roles/iam.workloadIdentityUser \
      --member "serviceAccount:project-id.svc.id.goog[k8s-namespace/ksa-name]" \
      gsa-name@gsa-project-id.iam.gserviceaccount.com
    

    다음을 바꿉니다.

    • project-id: GKE 클러스터의 프로젝트 ID 컨테이너입니다.
    • k8s-namespace: Kubernetes 서비스 계정이 있는 Kubernetes 네임스페이스의 이름입니다.
    • ksa-name: 액세스 권한이 취소될 Kubernetes 서비스 계정의 이름입니다.
    • gsa-name: Google 서비스 계정의 이름입니다.
    • gsa-project-id: Google 서비스 계정이 포함된 프로젝트 ID입니다.

    구성 커넥터

    구성 커넥터를 사용하여 서비스 계정을 만든 경우 kubectl로 서비스 계정을 삭제합니다.

    kubectl delete -f service-account.yaml
    

    이 작업을 수행하려면 서비스 계정에 대한 iam.serviceAccounts.setIamPolicy 권한이 필요합니다.

    캐시된 토큰이 만료되기까지 최대 30분이 걸릴 수 있습니다. 다음 명령어를 사용하여 캐시된 토큰이 만료되었는지 여부를 확인할 수 있습니다.

    gcloud auth list
    

    명령어의 결과에 더 이상 gsa-name@project-id.iam.gserviceaccount.com이 포함되지 않으면 캐시된 토큰이 만료된 것입니다.

  2. Kubernetes 서비스 계정에서 주석을 삭제합니다. IAM에서 액세스 권한을 취소했기 때문에 이 단계는 선택사항입니다.

    kubectl annotate serviceaccount \
      --namespace k8s-namespace \
      ksa-name \
      iam.gke.io/gcp-service-account-
    

문제 해결

애플리케이션이 Google Cloud에 인증할 수 없으면 다음 설정이 올바르게 구성되었는지 확인합니다.

  1. GKE 클러스터가 포함된 프로젝트에서 IAM Service Account Credentials API를 사용 설정했는지 확인합니다.

    IAM Credentials API 사용 설정

  2. 워크로드 아이덴티티 풀이 설정되어 있는지 확인하여 클러스터에서 워크로드 아이덴티티가 사용 설정되었는지 확인합니다.

    gcloud container clusters describe cluster-name \
      --format="value(workloadIdentityConfig.workloadPool)"
    
  3. 애플리케이션이 실행되는 노드 풀에서 GKE 메타데이터 서버(GKE_METADATA)가 구성되어 있는지 확인합니다.

    gcloud container node-pools describe node-pool-name \
      --cluster=cluster-name \
      --format="value(config.workloadMetadataConfig.mode)"
    
  4. Kubernetes 서비스 계정이 올바르게 주석 처리되었는지 확인합니다.

    kubectl describe serviceaccount \
      --namespace k8s-namespace \
      ksa-name
    

    다음과 같은 형식의 주석이 있어야 합니다.

    iam.gke.io/gcp-service-account: gsa-name@project-id.iam.gserviceaccount.com
    
  5. Google 서비스 계정이 올바르게 구성되어 있는지 확인합니다.

    gcloud iam service-accounts get-iam-policy \
      gsa-name@project-id.iam.gserviceaccount.com
    

    다음 형식의 바인딩이 있는지 확인합니다.

    - members:
      - serviceAccount:project-id.svc.id.goog[k8s-namespace/ksa-name]
      role: roles/iam.workloadIdentityUser
    
  6. 클러스터 네트워크 정책이 있는 경우 포트 988에서 127.0.0.1/32로 이그레스가 허용되는지 확인합니다.

    kubectl describe networkpolicy network-policy-name
    

클러스터에서 워크로드 아이덴티티 사용 중지

  1. 각 노드 풀에서 워크로드 아이덴티티를 사용 중지합니다.

    gcloud container node-pools update nodepool-name \
      --cluster=cluster-name \
      --workload-metadata=GCE_METADATA
    

    클러스터의 모든 노드 풀에 이 명령어를 반복합니다.

  2. 클러스터에서 워크로드 아이덴티티를 사용 중지:

    gcloud container clusters update cluster-name \
      --disable-workload-identity
    

    이 작업에는 클러스터에 대한 container.clusters.update 권한이 필요합니다.

조직에서 워크로드 아이덴티티 사용 중지

보안 측면에서 워크로드 아이덴티티는 GKE가 Google Cloud 리소스에 인증하고 승인할 수 있는 Kubernetes 서비스 계정 ID를 사용할 수 있도록 허용합니다. 서비스 계정 생성 사용 중지 또는 서비스 계정 키 생성 사용 중지와 같이 워크로드를 Google Cloud 리소스에서 격리하기 위한 작업을 수행한 관리자는 조직의 워크로드 아이덴티티를 사용 중지할 수도 있습니다.

조직에서 워크로드 아이덴티티 사용 중지 지침을 참조하세요.

워크로드 아이덴티티의 대안

GKE에서 Cloud API에 액세스하는 두 가지 대체 방법이 있습니다. 이러한 대안에는 절충이 필요하므로 워크로드 아이덴티티가 출시된 후에는 더 이상 이러한 방법을 권장하지 않습니다.

  1. 서비스 계정 키를 내보내 Kubernetes 보안 비밀로 저장합니다. Google 서비스 계정 키는 10년 후에 만료되며 수동으로 순환됩니다. 서비스 계정 키를 내보내면 보안 침해가 감지되지 않을 경우 보안 침해 범위가 확대될 가능성이 있습니다.

  2. 노드의 Compute Engine 서비스 계정을 사용합니다. 프로젝트에서 IAM 서비스 계정으로 노드 풀을 실행할 수 있습니다. 노드 풀을 만드는 동안 서비스 계정을 지정하지 않으면 GKE는 프로젝트의 Compute Engine 기본 서비스 계정을 사용합니다. Compute Engine 서비스 계정은 해당 노드에 배포된 모든 워크로드에서 공유됩니다. 이로 인해 권한이 과도하게 프로비저닝될 수 있습니다.

다음 단계