GKE의 서비스 계정 정보

이 페이지에서는 Google Kubernetes Engine(GKE)의 서비스 계정과 애플리케이션에 ID를 제공하는 방법을 설명합니다. 개인 사용자 인증 정보를 사용하지 않고 GKE 내 리소스에 대한 액세스를 인증하기 위해 다양한 유형의 서비스 계정과 각 계정을 언제 사용해야 하는지에 대해 알아봅니다.

이 페이지는 GKE 애플리케이션과 상호작용하기 위해 서비스 계정을 만들고 관리하는 보안 전문가 및 운영자를 대상으로 합니다. Google Cloud 콘텐츠에서 참조하는 일반적인 역할 및 예시 태스크에 대해 자세히 알아보려면 일반 GKE Enterprise 사용자 역할 및 태스크를 참조하세요.

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 문서에서는 IAM과 같은 다른 환경의 서비스 계정과 이러한 Kubernetes 리소스를 구분하기 위해 ServiceAccount라는 용어를 자주 사용합니다.

네임스페이스에서 Kubernetes ServiceAccount를 만든 다음 포드 매니페스트의 serviceAccountName 필드를 사용하여 해당 ServiceAccount를 포드에 할당합니다. 노드의 kubelet 프로세스는 할당된 ServiceAccount에 대한 단기 Bearer 토큰을 가져오고 해당 토큰을 포드에 예상 볼륨으로 마운트합니다. 기본적으로 이 프로젝션 볼륨의 이름은 kube-api-access- 프리픽스로 시작합니다. 이 프리픽스로 시작하는 볼륨은 GKE에서 관리하므로 이러한 볼륨의 크기를 수정할 수 없습니다. 디스크 사용량을 더 정확하게 모니터링하려면 모니터링 구성에서 kube-api-access- 프리픽스로 시작하는 볼륨을 제외하세요.

단기 Bearer 토큰은 OpenID Connect (OIDC) 제공업체인 API 서버에서 서명된 JSON 웹 토큰(JWT)입니다. Bearer 토큰을 검증하려면 GKE API에서 projects.locations.clusters.getJwks 메서드를 호출하여 클러스터의 공개 검증 키를 가져옵니다.

보안 침해된 Kubernetes ServiceAccount 사용자 인증 정보

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

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

IAM 서비스 계정

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

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

GKE 서비스 에이전트

IAM 서비스 에이전트는 Google Cloud 에서 관리하는 IAM 서비스 계정입니다. GKE는 다음 두 서비스 에이전트를 사용합니다.

Kubernetes Engine 서비스 에이전트

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는 숫자형 프로젝트 번호입니다.

Kubernetes Engine 기본 노드 서비스 에이전트

GKE는 Kubernetes 버전 1.33 이상을 사용하는 클러스터의 Kubernetes 노드 로깅 및 모니터링을 지원하기 위해 Kubernetes Engine 기본 노드 서비스 에이전트를 사용합니다. 이 서비스 에이전트는 도메인이 gcp-sa-gkenode.iam.gserviceaccount.com이며 GKE API를 사용 설정하면 프로젝트에서 Kubernetes Engine 기본 노드 서비스 에이전트 역할 (roles/container.defaultNodeServiceAgent)이 부여됩니다.

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

service-PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com

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

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

기본 GKE 노드 서비스 계정

GKE는 노드에 연결된 IAM 서비스 계정을 사용하여 로깅 및 모니터링과 같은 시스템 태스크를 실행합니다. 적어도 이러한 노드 서비스 계정에는 프로젝트에 대한 Kubernetes Engine 기본 노드 서비스 계정(roles/container.defaultNodeServiceAccount) 역할이 있어야 합니다. 기본적으로 GKE는 프로젝트에 자동으로 생성되는 Compute Engine 기본 서비스 계정을 노드 서비스 계정으로 사용합니다.

조직에서 iam.automaticIamGrantsForDefaultServiceAccounts 조직 정책 제약조건을 적용하는 경우 프로젝트의 기본 Compute Engine 서비스 계정에 GKE에 필요한 권한이 자동으로 부여되지 않을 수 있습니다.

프로젝트 또는 조직의 다른 기능에 Compute Engine 기본 서비스 계정을 사용하는 경우 서비스 계정에 GKE에 필요한 것보다 많은 권한이 있을 수 있으며, 이로 인해 보안 위험이 발생할 수 있습니다.

Compute Engine 기본 서비스 계정에 roles/container.defaultNodeServiceAccount 역할을 부여하려면 다음 단계를 완료합니다.

콘솔

  1. 시작 페이지로 이동합니다.

    시작 페이지로 이동

  2. 프로젝트 번호 필드에서 클립보드에 복사를 클릭합니다.
  3. IAM 페이지로 이동합니다.

    IAM으로 이동

  4. 액세스 권한 부여를 클릭합니다.
  5. 새 주 구성원 필드에 다음 값을 지정합니다. 
    PROJECT_NUMBER-compute@developer.gserviceaccount.com
     PROJECT_NUMBER를 복사한 프로젝트 번호로 바꿉니다.
  6. 역할 선택 메뉴에서 Kubernetes Engine 기본 노드 서비스 계정 역할을 선택합니다.
  7. 저장을 클릭합니다.

gcloud

  1. Google Cloud 프로젝트 번호를 찾습니다. 
    gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)"

    PROJECT_ID를 프로젝트 ID로 바꿉니다.

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

    12345678901
  2. Compute Engine 기본 서비스 계정에 roles/container.defaultNodeServiceAccount 역할을 부여합니다. 
    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com" \
    --role="roles/container.defaultNodeServiceAccount"

    PROJECT_NUMBER를 이전 단계의 프로젝트 번호로 바꿉니다.

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

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

사용하는 서비스 계정 유형은 애플리케이션에 제공하려는 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 기본 서비스 계정을 사용합니다.

다음 단계