Overview
이 글에서는 Google Cloud Platform(GCP)에서 공유 VPC(Shared VPC)를 활용하여 서로 다른 서비스 프로젝트에 속한 GKE 클러스터를 생성하는 방법을 단계별로 정리한다.
GCP에서 공유 VPC는 네트워크 리소스를 중앙에서 통합적으로 관리하면서도 서비스 프로젝트별로 독립적인 리소스를 운영할 수 있게 해주는 강력한 기능이다.
이를 통해 조직은 보안 정책을 일관되게 유지하고, 여러 개발 환경(예: dev, prod)을 네트워크 관점에서 체계적으로 분리하면서도 효율적으로 협업할 수 있다.
주요 내용은 다음과 같다.
- 공유 VPC의 기본 개념 및 아키텍처 예시
- 호스트/서비스 프로젝트 구분
- GKE 클러스터 생성을 위한 IAM 역할 설정
- Terraform 자동화를 위한 권한 구성
- 실무에서 유의해야 할 권한 위임과 네트워크 관리 포인트
📅 관련 글
2023.04.06 - [GCP] - GCP란? - 서비스 계정 & Project 생성 / SDK(gcloud) 설치
2023.04.06 - [GCP] - GCP IAM이란?
2023.04.12 - [GCP] - GCP - SDK(gcloud) 계정 2개 등록하기
2023.05.05 - [GCP] - GCP vs AWS 리소스 비교
2023.05.19 - [GCP] - GCP BigQuery란? & Data Warehouse
2023.09.23 - [GCP] - BigQuery와 DataFlow를 활용한 Data ETL(GCP)
2023.10.03 - [GCP] - Shared VPC를 사용하여 GKE 클러스터 생성시 IAM 설정
2023.12.18 - [GCP] - GCP를 활용한 데이터 자동화(MongoDB, CloudSQL, GA, Dune)
2024.01.20 - [GCP] - Terraform 으로 GCS 생성후 Cloud CDN 생성(GCP)
2024.03.04 - [GCP] - GCP에서 딥러닝을 위한 GPU VM 서버 만들기(GCP)
2024.04.24 - [Migration] - AWS에서 GCP로 마이그레이션하는 방법 및 고려사항
공유 VPC란(Share VPC)?
공유 VPC는 여러 프로젝트에 리소스를 공통 VPC 네트워크에 연결할 수 있게 함으로써 해당 네트워크의 내부 IP를 사용하여 서로 안전하고 효율적으로 통신할 수 있다.
프로젝트(환경)별로 리소스를 분리하여 구성할 수 있다. 따라서 환경별로 리소스를 분리하여 관리할 수 있고 비용 관리 측면에도 용이하다.
공유 VPC를 사용하면 호스트 프로젝트를 지정한 후 하나 이상의 다른 서비스 프로젝트를 연결할 수 있다. 서브넷, 경로 방화벽과 같은 네트워크 리소스를 호스트 프로젝트에서만 제어하면 되기 때문에 네트워크 리소스 관리에 용이하다.
1. 기본 개념
공유 VPC 네트워크가 있는 호스트 프로젝트는 두 개의 서비스 프로젝트에 내부 연결을 제공하는 반면, 독립형 프로젝트는 공유 VPC를 사용하지 않는다.
2. 여러 호스트 프로젝트
공유 VPC를 사용하여 별도의 테스트 및 프로덕션 환경을 구축하는 방법을 보여준다. 아래의 경우에는 별도의 두 호스트 프로젝트인 테스트 환경과 프로젝트 환경을 사용한다.
공유 VPC를 활용하여 GKE 클러스터 설정 시 선행작업
호스트 프로젝트와 서비스 프로젝트 예시는 다음과 같다.
호스트 프로젝트(Host Project)
- `somaz-hp`
서비스 프로젝트(Service Project)
- `somaz-sp-dev`
- `somaz-sp-prod`
IAM 설정
서비스 프로젝트가 somaz-sp-dev 기준으로 작성한다. 나머지 서비스 프로젝트도 동일하다.
- `GCP API SA: <project-number>@cloudservices.gserviceaccount.com`
- `GKE API SA: service-<project-number>@container-engine-robot.iam.gserviceaccount.com`
1. 서비스 계정 변수 설정
GKE_SA=service-$(gcloud projects describe somaz-sp-dev --format 'value(projectNumber)')@container-engine-robot.iam.gserviceaccount.com
echo $GKE_SA
service-<project number>@container-engine-robot.iam.gserviceaccount.com
$ GCP_API_SA=$(gcloud projects describe somaz-sp-dev --format 'value(projectNumber)')@cloudservices.gserviceaccount.com
$ echo $GCP_API_SA
<project number>@cloudservices.gserviceaccount.com
2. 프로젝트에서 GKE API 사용 설정
gcloud services enable container.googleapis.com
# 확인
gcloud services list --enabled |grep Kubernetes
container.googleapis.com Kubernetes Engine API
3. 호스트 프로젝트 GKE API SA와 서비스 프로젝트 GCP API SA / GKE API SA에게 `roles/container.serviceAgent(=Kubernetes Egnine 서비스 에이전트)` 권한 부여 (호스트 프로젝트에 부여)
# Host Project GKE API 서비스 계정 권한 부여
gcloud projects add-iam-policy-binding somaz-hp --member serviceAccount:$GKE_SA --role roles/container.serviceAgent
# Service Project GKE API 서비스 계정, Google API 서비스 계정 권한 부여
gcloud projects add-iam-policy-binding somaz-hp --member serviceAccount:$GKE_SA --role roles/container.serviceAgent
gcloud projects add-iam-policy-binding somaz-hp --member serviceAccount:$GCP_API_SA --role roles/container.serviceAgent
# roles/container.serviceAgent 권한 부여 확인
gcloud projects get-iam-policy mgmt-2023 --flatten="bindings[].members" --format='table(bindings.role,bindings.members)' | grep 'roles/container.serviceAgent'
roles/container.serviceAgent serviceAccount:<project number>@cloudservices.gserviceaccount.com
roles/container.serviceAgent serviceAccount:service-<project number>@container-engine-robot.iam.gserviceaccount.com
roles/container.serviceAgent serviceAccount:service-<project number>@container-engine-robot.iam.gserviceaccount.com
4. 서비스 프로젝트 GKE API SA 에게 `roles/editor(=편집자)` 권한 부여 (서비스 프로젝트에 부여)
# Service Project Google API 서비스 계정 권한 부여
gcloud projects add-iam-policy-binding somaz-sp-dev --member serviceAccount:$GKE_SA --role roles/editor
# roles/editor 권한 부여 확인
gcloud projects get-iam-policy dev-dsp-1 --flatten="bindings[].members" --format='table(bindings.role,bindings.members)' | grep 'roles/editor'
5. 서비스 프로젝트 GKE API SA 과 GCP API SA 에 `roles/compute.networkUser(=Compute 네트워크 사용자)` 권한 부여(호스트 프로젝트에 부여)
# Service Project GKE API 서비스 계정, Google API 서비스 계정 권한 부여
gcloud projects add-iam-policy-binding somaz-hp --member serviceAccount:$GKE_SA --role roles/compute.networkUser
gcloud projects add-iam-policy-binding somaz-hp --member serviceAccount:$GCP_API_SA --role roles/compute.networkUser
# roles/compute.networkUser 권한 부여 확인
gcloud projects get-iam-policy mgmt-2023 --flatten="bindings[].members" --format='table(bindings.role,bindings.members)' | grep 'roles/compute.networkUser'
6. 서비스 프로젝트 GKE API SA 와 GCP API SA에 나머지 기타 권한 부여(호스트 프로젝트에 부여)
gcloud projects add-iam-policy-binding mgmt-2023 --member serviceAccount:$GKE_SA --role roles/compute.networkAdmin
gcloud projects add-iam-policy-binding mgmt-2023 --member serviceAccount:$GCP_API_SA --role roles/compute.viewer
gcloud projects add-iam-policy-binding mgmt-2023 --member serviceAccount:$GKE_SA --role roles/editor
7. Terraform 사용 시 사용하는 SA에게 `roles/compute.xpnAdmin(= Compute 공유 VPC 관리자)` 권한 부여(조직에 부여)
# Google 사용자에게 부여
gcloud organizations add-iam-policy-binding [ORGANIZATION_ID] \
--member="user:[USER_EMAIL]" \
--role="roles/compute.xpnAdmin"
# Google 서비스 어카운트(SA)에게 부여
gcloud organizations add-iam-policy-binding [ORGANIZATION_ID] \
--member="serviceAccount:[SERVICE_ACCOUNT]" \
--role="roles/compute.xpnAdmin"
8. Terraform으로 클러스터 생성 후에 Terraform GKE SA에게 Artifact Registry가 있는 프로젝트(대부분 호스트 프로젝트 사용)에 `roles/artifactregistry.reader(= Artifact Registry 리더)` 권한 부여(호스트 프로젝트에 부여)
Terraform GKE ServiceAccount
- `tf-gke-<cluster name>-<random>@<project>.iam.gserviceaccount.com`
gcloud projects add-iam-policy-binding somaz-hp --member serviceAccount:tf-gke-somaz-sp-dev-gke-tz9q@somaz-sp-dev.iam.gserviceaccount.com --role roles/artifactregistry.reader
gcloud projects get-iam-policy somaz-hp --flatten="bindings[].members" --format='table(bindings.role,bindings.members)' | grep 'roles/artifactregistry.reader'
roles/artifactregistry.reader serviceAccount:tf-gke-somaz-sp-dev-gke-tz9q@somaz-sp-dev.iam.gserviceaccount.com
마무리
공유 VPC를 통한 GKE 클러스터 구축은 단순한 리소스 배포를 넘어서 보안, 네트워크 구조, 권한 관리까지 아우르는 종합적인 아키텍처 설계 전략이다.
이번 글에서는 GKE를 공유 VPC 기반으로 구축하기 위한 IAM 권한 구성, Terraform 기반 자동화, 그리고 서비스 프로젝트 간 통합 운영 전략까지 다뤘다.
공유 VPC 구조를 통해 얻을 수 있는 이점은 다음과 같다.
- 중앙집중형 네트워크 관리: 방화벽, 라우팅, 서브넷 등 주요 리소스를 일괄 관리
- 보안 및 비용 최적화: 환경 간 트래픽 제어 및 VPC Peering 없이 통신 가능
- 프로젝트/조직 확장성 확보: 신규 프로젝트 추가 시 유연하게 네트워크 연결 가능
GCP 기반 클라우드 인프라를 운영하는 기업이라면, 공유 VPC는 필수적인 고려 대상이며, 특히 대규모 조직일수록 도입 효과가 더욱 뚜렷하다.
지금부터라도 공유 VPC 아키텍처를 도입하고, Terraform과 같은 IaC 도구와 결합해 안정적이고 확장 가능한 GKE 운영 환경을 구성해보자.
보안과 확장성, 두 마리 토끼를 잡는 방법 – 바로 공유 VPC 기반 GKE 아키텍처!
Reference
https://cloud.google.com/vpc/docs/shared-vpc?hl=ko
https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-shared-vpc?hl=ko
'GCP' 카테고리의 다른 글
| Terraform 으로 GCS 생성후 Cloud CDN 생성(GCP) (0) | 2024.01.22 |
|---|---|
| GCP를 활용한 데이터 자동화(MongoDB, CloudSQL, GA, Dune) (2) | 2023.12.22 |
| BigQuery와 DataFlow를 활용한 Data ETL(GCP) (0) | 2023.10.02 |
| GCP BigQuery란? & Data Warehouse (0) | 2023.05.21 |
| GCP vs AWS 리소스 비교 (1) | 2023.05.05 |