GKE의 서비스 계정 정보


이 페이지에서는 애플리케이션 ID를 제공하는 Google Kubernetes Engine(GKE)의 서비스 계정에 대해 설명합니다.

서비스 계정은 사용자가 아닌 애플리케이션에서 사용하도록 고안된 ID입니다. GKE에서는 Kubernetes 서비스 계정Identity and Access Management 서비스 계정과 상호작용합니다.

Kubernetes 서비스 계정 및 IAM 서비스 계정

다음 표에서는 Kubernetes 서비스 계정과 IAM 서비스 계정의 주요 차이점을 설명합니다.

GKE의 서비스 계정 유형
Kubernetes 서비스 계정
  • Kubernetes API 서버의 ServiceAccount 객체
  • 클러스터의 Kubernetes 네임스페이스로 범위 지정
  • 클러스터 내에서 사용할 포드에 ID 제공
IAM 서비스 계정
  • IAM API를 사용하여 관리
  • Google Cloud 프로젝트로 범위 지정
  • 프로젝트의 애플리케이션에 ID 제공

Kubernetes ServiceAccounts

Kubernetes 서비스 계정은 클러스터 수준에서 관리되며 Kubernetes API 서버에 ServiceAccount 객체로 존재합니다. Kubernetes 문서 및 GKE 문서에서는 이러한 Kubernetes 리소스를 IAM과 같은 다른 환경의 서비스 계정과 구분하기 위해 종종 ServiceAccount라는 용어를 사용합니다.

네임스페이스에 Kubernetes ServiceAccount를 만든 후 포드 매니페스트에서 serviceAccountName 필드를 사용하여 포드에 해당 ServiceAccount를 할당합니다. 노드의 kubelet 프로세스는 할당된 ServiceAccount에 대한 단기 Bearer 토큰을 가져오고 해당 토큰을 포드에 예상 볼륨으로 마운트합니다.

  • Kubernetes ServiceAccounts의 기본 사항을 알아보려면 Kubernetes 문서에서 서비스 계정을 참조하세요.
  • 새 ServiceAccounts를 만들고, 역할 기반 액세스 제어(RBAC)를 사용하여 권한을 부여하고, 포드에 ServiceAccounts를 할당하는 방법은 포드용 서비스 계정 구성을 참조하세요.
  • Kubernetes ServiceAccounts 관리 시 권장사항은 RBAC 권장사항을 참조하세요.

Kubernetes ServiceAccount 사용자 인증 정보 순환

Kubernetes 서비스 계정 사용자 인증 정보가 손상된 경우 다음 옵션 중 하나를 사용하여 사용자 인증 정보를 취소합니다.

  • 포드 다시 만들기: Bearer 토큰은 각각의 고유한 포드 UID에 결합되므로 포드를 다시 만들면 이전 사용자 인증 정보가 무효화됩니다.
  • Kubernetes 서비스 계정 다시 만들기: Bearer 토큰이 Kubernetes API에서 ServiceAccount 객체의 UID에 결합됩니다. ServiceAccount를 삭제하고 같은 이름으로 새 ServiceAccount를 만듭니다. 새 ServiceAccount의 UID가 다르기 때문에 이전 토큰은 무효화됩니다.
  • 사용자 인증 정보 순환 수행: 이 작업을 수행하면 클러스터에 있는 모든 Kubernetes 서비스 계정 사용자 인증 정보가 취소됩니다. 순환은 클러스터의 CA 인증서 및 IP 주소도 변경합니다. 자세한 내용은 사용자 인증 정보 순환을 참조하세요.

IAM 서비스 계정

IAM 서비스 계정은 IAM API를 사용하여 프로젝트 수준에서 관리됩니다. 이러한 서비스 계정을 사용하여 Google Cloud APIs를 프로그래매틱 방식으로 호출하고 Google Cloud 제품에서 실행되는 애플리케이션에 대한 권한을 관리하는 등의 작업을 수행할 수 있습니다.

자세한 내용은 IAM 서비스 계정 개요를 참조하세요.

GKE 서비스 에이전트

IAM 서비스 에이전트는 Google Cloud에서 관리하는 IAM 서비스 계정입니다.

GKE는 Kubernetes Engine 서비스 에이전트를 사용하여 노드, 디스크, 부하 분산기와 같은 클러스터 리소스의 수명 주기를 대신 관리합니다. 이 서비스 에이전트는 도메인이 container-engine-robot.iam.gserviceaccount.com이며 GKE API를 사용 설정하면 프로젝트에서 Kubernetes Engine 서비스 에이전트 역할(roles/container.serviceAgent)이 부여됩니다.

이 서비스 에이전트의 식별자는 다음과 같습니다.

service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com

PROJECT_NUMBER는 숫자형 프로젝트 번호입니다.

GKE 서비스 에이전트를 사용 중지한 경우 서비스 계정 사용 설정의 안내에 따라 복구할 수 있습니다.

프로젝트에서 서비스 에이전트의 권한을 삭제한 경우 오류 400/403: 계정에 대한 수정 권한 누락의 안내에 따라 이를 복구할 수 있습니다.

GKE 서비스 에이전트를 삭제한 경우 서비스 계정 삭제 취소의 안내에 따라 삭제를 취소할 수 있습니다.

기본 GKE 노드 서비스 계정

기본적으로 GKE 노드는 Compute Engine 기본 서비스 계정을 사용합니다. 기본적으로 이 서비스 계정에는 편집자 역할(roles/editor)이 부여되며 GKE 노드에 필요한 것보다 많은 권한을 포함합니다. 클러스터에서 노드를 실행하는 데 필요한 최소 권한을 사용하는 역할을 사용하는 것이 좋습니다.

사용자 관리형 서비스 계정으로 마이그레이션하는 경우가 아니면 기본 Compute Engine 서비스 계정을 중지하지 마세요.

최소 권한

GKE를 사용하려면 클러스터를 운영하기 위한 최소 IAM 권한 집합이 필요합니다. 최소 권한의 IAM 서비스 계정을 만드는 방법은 최소 권한 Google 서비스 계정 사용을 참조하세요.

특정 서비스 계정을 사용해야 하는 경우

사용하는 서비스 계정 유형은 다음과 같이 애플리케이션에 제공하려는 ID 유형에 따라 달라집니다.

  • 클러스터에서 사용할 포드에 대한 ID 제공: Kubernetes ServiceAccount를 사용합니다. 모든 Kubernetes 네임스페이스에는 default ServiceAccount가 있지만 각 네임스페이스의 각 워크로드에 대해 최소 권한의 새로운 ServiceAccounts를 만드는 것이 좋습니다.
  • 클러스터 외부에서 사용할 포드에 ID 제공: GKE용 워크로드 아이덴티티 제휴를 사용합니다. GKE용 워크로드 아이덴티티 제휴를 사용하면 ServiceAccount와 같은 Kubernetes 리소스를 IAM 정책의 주 구성원으로 지정할 수 있습니다. 예를 들어 포드에서 Secret Manager 또는 Spanner와 같은 Google Cloud API를 호출할 때 GKE용 워크로드 아이덴티티 제휴를 사용합니다.
  • 노드에 대한 기본 ID 제공: GKE 클러스터 또는 노드를 만들 때 커스텀 최소 권한의 IAM 서비스 계정을 사용합니다. 커스텀 IAM 서비스 계정을 사용하지 않으면 GKE는 프로젝트 내에서 광범위한 권한이 있는 Compute Engine 기본 서비스 계정을 사용합니다.

다음 단계