GKE용 워크로드 아이덴티티 제휴는 Google Kubernetes Engine(GKE)에서 실행되는 워크로드가 안전하고 관리 가능한 방식으로 Google Cloud 서비스에 액세스하는 데 권장되는 방식입니다.
GKE용 워크로드 아이덴티티 제휴는 Google Cloud 내부 및 외부 환경에서 실행되는 워크로드의 ID를 제공하는 IAM 워크로드 아이덴티티 제휴를 통해 사용할 수 있습니다. IAM 워크로드 아이덴티티 제휴를 사용하면 실행되는 워크로드(예: AWS, Azure, 자체 관리형 Kubernetes)에서 지원되는 Google Cloud API에 안전하게 인증할 수 있습니다. GKE에서 Google Cloud는 워크로드 아이덴티티 풀과 제공업체를 자동으로 관리하므로 외부 ID 공급업체가 필요하지 않습니다.
- 다른 환경의 워크로드 아이덴티티 제휴에 대한 자세한 내용은 워크로드 아이덴티티 제휴를 참조하세요.
- GKE용 워크로드 아이덴티티 제휴를 사용 설정하고 사용하려면 GKE 워크로드에서 Google Cloud API에 액세스를 참조하세요.
- Fleet의 클러스터에 워크로드 아이덴티티 제휴 지원을 제공하려면 Fleet 워크로드 아이덴티티를 사용합니다.
용어
이 문서에서는 Kubernetes 서비스 계정 및 Identity and Access Management(IAM) 서비스 계정을 구분합니다.
- Kubernetes 서비스 계정
- GKE 포드에서 실행되는 프로세스의 ID를 제공하는 Kubernetes 리소스입니다.
- IAM 서비스 계정
- 애플리케이션이 Google Cloud API에 대해 승인된 호출을 수행할 수 있게 해주는 Google Cloud 리소스입니다.
GKE용 워크로드 아이덴티티 제휴란 무엇인가요?
GKE에서 실행되는 애플리케이션은 Compute Engine API, BigQuery Storage API, Machine Learning API와 같은Google Cloud API에 액세스해야 할 수 있습니다.
GKE용 워크로드 아이덴티티 제휴를 사용하면 수동으로 구성하거나 덜 안전한 방법(예: 서비스 계정 키 파일)을 사용할 필요 없이 IAM 정책을 사용하여 GKE 클러스터의 Kubernetes 워크로드에 특정 Google Cloud API에 대한 액세스 권한을 부여할 수 있습니다. GKE용 워크로드 아이덴티티 제휴를 사용하면 클러스터의 애플리케이션마다 고유하고 세분화된 ID와 승인을 할당할 수 있습니다.
GKE용 워크로드 아이덴티티 제휴는 메타데이터 숨김을 대체합니다. 메타데이터 숨김으로 보호되는 민감한 메타데이터는 GKE용 워크로드 아이덴티티 제휴로도 보호됩니다.
GKE용 워크로드 아이덴티티 제휴 작동 방식
클러스터에서 GKE용 워크로드 아이덴티티 제휴를 사용 설정하면 GKE에서 다음을 수행합니다.
다음 형식으로 클러스터의 Google Cloud 프로젝트에 대해 고정된 워크로드 아이덴티티 풀을 만듭니다.
PROJECT_ID.svc.id.goog워크로드 아이덴티티 풀은 IAM이 Kubernetes 사용자 인증 정보를 파악하고 신뢰할 수 있게 해주는 이름 지정 형식을 제공합니다.
워크로드 아이덴티티 풀에서 GKE 클러스터를 ID 공급업체로 등록합니다.
모든 노드에서 워크로드의 사용자 인증 정보 요청을 가로채는 GKE 메타데이터 서버를 배포합니다.
Google Cloud 리소스에 IAM 허용 정책 만들기
GKE용 워크로드 아이덴티티 제휴를 사용하여 액세스 권한을 제공하려면 애플리케이션 ID에 해당하는 주 구성원에게 특정 Google Cloud 리소스에 대한 액세스 권한을 부여하는 IAM 허용 정책을 만듭니다. 예를 들어 database-reader Kubernetes ServiceAccount를 사용하는 모든 포드에 Cloud Storage 버킷에 대한 읽기 권한을 부여할 수 있습니다.
허용 정책을 지원하는 리소스 목록은 허용 정책을 허용하는 리소스 유형을 참조하세요.
또한 허용 정책에서 조건을 설정하여 액세스 범위를 제한할 수 있습니다. 예를 들어 mysql 클러스터에서 database-reader ServiceAccount를 사용하는 포드에 버킷에 대한 읽기 액세스 권한만 부여하려면 허용 정책에서 해당 조건을 설정하면 됩니다. 허용 정책에서 조건을 사용하는 방법은 조건부 역할 바인딩 관리를 참조하세요.
IAM 정책에서 Kubernetes 리소스 참조
IAM 정책에서 IAM 주 구성원 식별자를 사용하여 리소스를 선택해 Kubernetes 리소스를 참조합니다. 이 식별자에는 다음 구문이 있습니다.
PREFIX://iam.googleapis.com/projects/1234567890/locations/global/workloadIdentityPools/example-project.svc.id.goog/SELECTOR
이 예시에서는 다음 필드를 고려합니다.
PREFIX: 선택한 리소스에 따라principal또는principalSet여야 합니다.principal은 단일 ServiceAccount와 같은 특정 리소스에 사용됩니다.principalSet은 특정 클러스터의 모든 포드와 같이 지정된 리소스에 속하는 여러 리소스에 사용됩니다.SELECTOR: 주 구성원 유형을 선택하는 문자열입니다. 예를 들어kubernetes.serviceaccount.uid/SERVICEACCOUNT_UID는 UID별로 ServiceAccount를 선택합니다.
다음 표에서는 GKE에서 지원되는 주 구성원 유형을 보여줍니다.
| 주 구성원 식별자 유형 | 구문 |
|---|---|
| 특정 Kubernetes ServiceAccount를 사용하는 모든 포드 | 이름별로 ServiceAccount를 선택합니다.
principal://iam.googleapis.com/projects/
다음을 바꿉니다.
UID별로 ServiceAccount를 선택합니다. principal://iam.googleapis.com/projects/
다음을 바꿉니다.
|
| 서비스 계정 또는 클러스터에 관계없이 네임스페이스의 모든 포드 | principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/namespace/NAMESPACE 다음을 바꿉니다.
|
| 특정 클러스터의 모든 포드 | principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/kubernetes.cluster/https://container.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/clusters/CLUSTER_NAME 다음을 바꿉니다.
|
사용자 인증 정보 흐름
Google Cloud 클라이언트 라이브러리를 사용할 때와 같이 워크로드가 Google Cloud API에 액세스하려는 요청을 전송할 때 다음 인증 단계가 수행됩니다.
- 애플리케이션 기본 사용자 인증 정보(ADC)는 VM에서 실행되는 Compute Engine 메타데이터 서버에서 Google Cloud 액세스 토큰을 요청합니다.
- GKE 메타데이터 서버는 토큰 요청을 가로채고 Kubernetes API 서버에 요청 워크로드를 식별하는 Kubernetes 서비스 계정 토큰을 요청합니다. 이 사용자 인증 정보는 API 서버에서 서명한 JSON 웹 토큰(JWT)입니다.
- GKE 메타데이터 서버는 보안 토큰 서비스를 사용하여 JWT를 Kubernetes 워크로드 아이덴티티를 참조하는 단기 제휴 Google Cloud 액세스 토큰으로 교환합니다.
- GKE 메타데이터 서버는 워크로드에 제휴 액세스 토큰을 제공합니다.
그러면 워크로드는 워크로드의 IAM 주 구성원 식별자가 액세스할 수 있는 모든 Google Cloud API에 액세스할 수 있습니다.
ID 동일성
주 구성원 식별자의 메타데이터가 같은 Google Cloud 프로젝트에 속하기 때문에 워크로드 아이덴티티 풀을 공유하는 여러 클러스터의 워크로드에서 같으면 IAM은 이러한 워크로드를 같은 워크로드로 식별합니다. 예를 들어 클러스터 2개에 같은 네임스페이스가 있고 IAM에서 이 네임스페이스에 대한 액세스 권한을 부여하면 두 클러스터의 네임스페이스에 있는 워크로드에 액세스 권한이 부여됩니다. 조건부 IAM 정책을 사용하여 이 액세스 권한을 특정 클러스터로 제한할 수 있습니다.
예를 들어 다음 다이어그램을 고려해보세요. 클러스터 A, B, C는 같은 워크로드 아이덴티티 풀에 속합니다. Google Cloud는 클러스터 A와 클러스터 B의 backend 네임스페이스에 있는 back-ksa ServiceAccount를 같은 ID로 사용하는 애플리케이션을 식별합니다. IAM은 호출을 수행하는 각 클러스터를 구분하지 않습니다.
이러한 ID 동일성으로 인해 특정 워크로드 아이덴티티 풀에서 모든 클러스터를 신뢰할 수 있어야 합니다. 예를 들어 이전 예시에서 클러스터 C가 신뢰할 수 없는 팀에서 소유된 경우에도 backend 네임스페이스를 만들고 클러스터 A 및 클러스터 B와 마찬가지로 back-ksa ServiceAccount를 사용해서 Google Cloud API에 액세스할 수 있습니다.
신뢰할 수 없는 액세스를 방지하려면 클러스터를 서로 다른 프로젝트에 배치하여 서로 다른 워크로드 아이덴티티 풀을 확보하거나 네임스페이스 이름을 서로 다르게 하여 일반적인 주 구성원 식별자를 사용하지 않도록 합니다.
GKE 메타데이터 서버 이해
GKE용 워크로드 아이덴티티 제휴가 사용 설정된 GKE의 모든 노드는 메타데이터를 GKE 메타데이터 서버에 저장합니다. GKE 메타데이터 서버는 Kubernetes 워크로드에 필요한 Compute Engine 메타데이터 서버 엔드포인트의 하위 집합입니다.
GKE 메타데이터 서버는 모든 Linux 노드에서 하나의 포드 또는 클러스터의 모든 Windows 노드에서 기본 Windows 서비스를 사용하여 DaemonSet로 실행됩니다. 메타데이터 서버가 HTTP 요청을 http://metadata.google.internal(169.254.169.254:80)로 가로챕니다. 예를 들어 GET
/computeMetadata/v1/instance/service-accounts/default/token 요청은 포드가 가장하도록 구성된 IAM 서비스 계정의 토큰을 검색합니다.
GKE 메타데이터 서버에 대한 트래픽은 포드를 호스팅하는 VM 인스턴스를 벗어나지 않습니다.
다음 표에서는 GKE 메타데이터 서버에 사용 가능한 Compute Engine 메타데이터 서버 엔드포인트의 하위 집합에 대해 설명합니다. Compute Engine 메타데이터 서버에서 사용 가능한 엔드포인트의 전체 목록은 기본 VM 메타데이터 값을 참조하세요.
인스턴스 메타데이터
인스턴스 메타데이터는 다음 디렉터리에 저장됩니다.
http://metadata.google.internal/computeMetadata/v1/instance/
| 항목 | 설명 |
|---|---|
hostname |
노드의 호스트 이름입니다. |
id |
노드의 고유 ID입니다. |
service-accounts/ |
노드와 연결된 서비스 계정의 디렉터리입니다. 각 서비스 계정에 대한 다음 정보가 제공됩니다.
|
zone |
GKE 노드의 Compute Engine 영역입니다. |
인스턴스 속성
인스턴스 속성은 다음 디렉터리에 저장됩니다.
http://metadata.google.internal/computeMetadata/v1/instance/attributes/
| 항목 | 설명 |
|---|---|
cluster-location |
클러스터의 Compute Engine 영역 또는 리전입니다. |
cluster-name |
GKE 클러스터의 이름입니다. |
cluster-uid |
GKE 클러스터의 UID입니다. |
프로젝트 메타데이터
클러스터 프로젝트 메타데이터는 다음 디렉터리에 저장됩니다.
http://metadata.google.internal/computeMetadata/v1/project/
| 항목 | 설명 |
|---|---|
project-id |
Google Cloud 프로젝트 ID |
numeric-project-id |
Google Cloud 프로젝트 번호입니다. |
GKE용 워크로드 아이덴티티 제휴 제한사항
GKE에서 Google Cloud 프로젝트에 만드는 워크로드 아이덴티티 풀의 이름은 변경할 수 없습니다.
GKE가 노드 풀에서 GKE 메타데이터 서버를 사용 설정하면 포드가 더 이상 Compute Engine 메타데이터 서버에 액세스할 수 없습니다. 대신 GKE 메타데이터 서버가 호스트 네트워크에서 실행되는 포드를 제외하고 해당 포드에서 메타데이터 엔드포인트로 수행되는 요청을 가로챕니다.
GKE 메타데이터 서버는 새로 생성된 포드에서 요청 수락을 시작하는 데 몇 초 정도 걸립니다. 따라서 포드 수명의 처음 몇 초 내에 GKE용 워크로드 아이덴티티 제휴를 사용하여 인증을 시도하면 실패할 수 있습니다. 이 문제는 호출을 다시 시도하면 해결됩니다. 자세한 내용은 문제 해결을 참조하세요.
GKE 기본 제공 로깅 및 모니터링 에이전트는 노드의 서비스 계정을 계속 사용합니다.
GKE용 워크로드 아이덴티티 제휴를 사용하려면 요청 측정항목이 계속 출시되도록 Knative serving을 수동으로 설정해야 합니다.
GKE용 워크로드 아이덴티티 제휴는 각 노드의 메모리 문제를 방지하기 위해 GKE 메타데이터 서버 연결을 200개로 제한합니다. 노드가 이 한도를 초과하면 시간 초과가 발생할 수 있습니다.
Windows Server 노드의 GKE용 워크로드 아이덴티티 제휴는 GKE 버전 1.18.16-gke.1200, 1.19.8-gke.1300, 1.20.4-gke.1500 이상에서 제공됩니다.
GKE 메타데이터 서버는 클러스터의 총 Kubernetes 서비스 계정 수에 비례하는 메모리 리소스를 사용합니다. 클러스터에 3,000개가 넘는 Kubernetes 서비스 계정이 있으면 kubelet이 메타데이터 서버 포드를 종료할 수 있습니다. 완화 방법은 문제 해결을 참조하세요.
GKE용 워크로드 아이덴티티 제휴 대안
GKE용 워크로드 아이덴티티 제휴에 대한 다음 대안 중 하나를 사용해서 GKE에서 Google Cloud API에 액세스할 수 있습니다. 이러한 대안은 특정한 보안상의 절충이 필요하므로 GKE 워크로드 아이덴티티 제휴를 사용하는 것이 좋습니다.
노드의 Compute Engine 기본 서비스 계정을 사용합니다. 프로젝트에서 IAM 서비스 계정으로 노드 풀을 실행할 수 있습니다. 노드 풀을 만드는 동안 서비스 계정을 지정하지 않으면 GKE는 프로젝트에 Compute Engine 기본 서비스 계정을 사용합니다. Compute Engine 서비스 계정은 해당 노드에 배포된 모든 워크로드에서 공유됩니다. 따라서 권한이 초과 프로비저닝되어 최소 권한의 원칙에 위배되고 멀티 테넌트 클러스터에 적합하지 않게 됩니다.
서비스 계정 키를 내보내 포드에 볼륨으로 마운트하는 Kubernetes 보안 비밀로 저장합니다.