프로덕션 배포: GCP 환경에서의 보안 접근 구성
Apache Airflow Official Documentation (in-repo snapshot) — Apache Software Foundation administration-and-deployment/production-deployment.rst (Secured Server and Service Access on Google Cloud 절)
이 모듈을 다 읽으면
- GCP 배포에서 네트워크 분리보다 IAM/서비스 계정 기반 신원 증명을 우선해야 하는 이유를 설명할 수 있다
- 서비스 계정 키를 직접 발급/저장하는 대신 임퍼스네이션을 권장하는 이유를 설명할 수 있다
- Compute Engine 인스턴스 SSH 접근과 AWS 자원 접근에 쓰는 Airflow 컴포넌트를 설명할 수 있다
Airflow 환경이 Google Cloud에 배포되거나 Google 서비스/API에 연결될 때, 네트워크 분리보다 IAM 기반 신원 증명을 중심에 두고, 서비스 계정 키를 직접 다루기보다 임퍼스네이션과 전용 Hook을 활용하는 것이 핵심 보안 원칙이다.
IAM과 서비스 계정
내부 네트워크 분리나 방화벽을 1차 보안 메커니즘으로 신뢰해서는 안 된다. 조직의 데이터를 보호하려면 모든 요청에 발신자 신원이 담겨 있어야 한다. Google Cloud에서 이 신원은 IAM과 서비스 계정이 제공한다. 각 Compute Engine 인스턴스에는 연결된 서비스 계정 신원이 있어, 워크로드가 Google API나 서드파티 서비스에 대해 자신의 신원을 증명할 수 있는 암호화 자격증명을 제공한다. 각 인스턴스는 단명(short-lived) 자격증명에만 접근하며, Google 관리형 서비스 계정 키를 쓴다면 개인 키는 항상 에스크로에 보관되어 직접 접근할 수 없다.
Kubernetes Engine(GKE)을 쓴다면 Workload Identity로 개별 파드에 신원을 할당할 수 있다.
핵심 포인트
- 네트워크 분리/방화벽이 아니라 IAM/서비스 계정 기반 발신자 신원 증명이 1차 보안 메커니즘이어야 한다
- Compute Engine 인스턴스는 단명 자격증명만 가지며, Google 관리형 키의 개인 키는 에스크로에 보관되어 직접 접근 불가하다
- GKE에서는 Workload Identity로 개별 파드 단위 신원을 할당할 수 있다
서비스 계정 임퍼스네이션
다른 서비스 계정에 대한 접근이 필요하다면, 기본 신원의 토큰을 다른 서비스 계정으로 교환하는 임퍼스네이션(impersonation)을 쓸 수 있다. 이렇게 하면 계정 키는 여전히 Google이 관리하며 워크로드가 직접 읽을 수 없다.
서비스 계정 키를 직접 생성해 메타데이터 DB나 시크릿 백엔드에 저장하는 것은 권장되지 않는다. 시크릿 백엔드를 쓰더라도 서비스 계정 키 자체는 결국 워크로드에서 사용 가능한 상태가 되기 때문이다 — 임퍼스네이션은 이 노출 자체를 없앤다.
핵심 포인트
- 임퍼스네이션은 서비스 계정 키를 발급/저장하지 않고 토큰 교환만으로 다른 서비스 계정 권한을 쓰는 방식이다
- 시크릿 백엔드에 저장하더라도 서비스 계정 키 자체는 워크로드에 노출되므로, 임퍼스네이션이 이 노출을 원천적으로 없앤다
Compute Engine 인스턴스 접근과 AWS 연동
Compute Engine 인스턴스에 SSH 연결을 맺으려면 인스턴스의 네트워크 주소와 접근 자격증명이 필요하다. 이를 간소화하려면 ``SSHHook`` 대신 ``ComputeEngineHook``을 쓸 수 있다. 이 Hook은 Google OS Login 서비스를 통한 인증을 지원하는데, 단명 SSH 키를 메타데이터 서비스에 저장하고, 접근·sudo 권한 체크를 위한 PAM 모듈을 제공하며, ``nsswitch`` 사용자 조회도 메타데이터 서비스로 처리하는 견고한 방식이다. 또한 인프라가 커지면서 생기는 "검색(discovery)" 문제도 해결해준다 — 네트워크 주소 대신 인스턴스 이름을 쓸 수 있기 때문이다.
Web Identity Federation 덕분에 Google Cloud Platform 신원을 Amazon Web Service 신원으로 교환할 수 있어, 사실상 AWS 플랫폼에 대한 접근이 가능해진다.
핵심 포인트
- GCE SSH 접근에는 범용 SSHHook 대신 ComputeEngineHook을 쓰면 Google OS Login 기반의 단명 키/PAM/nsswitch 통합을 활용할 수 있다
- ComputeEngineHook은 인스턴스 이름으로 접근할 수 있게 해줘 인프라 확장 시 주소 관리 문제를 해결한다
- Web Identity Federation으로 GCP 신원을 AWS 신원으로 교환해 AWS 자원에 접근할 수 있다