게이트웨이 보안

이 페이지에서는 Google Kubernetes Engine(GKE)에서 게이트웨이를 보호하는 다양한 방법을 설명합니다. 게이트웨이를 보호하는 방법에 대해서도 알아볼 수 있습니다.

게이트웨이 보안 작동 방식

게이트웨이는 부하 분산기의 프런트엔드를 나타냅니다. 보안 및 규정 준수 요구사항에 따라 두 가지 기본 방법으로 게이트웨이를 통해 트래픽을 보호할 수 있습니다.

  • TLS 종료: 게이트웨이는 관리형 또는 자체 관리형 SSL 인증서를 사용하여 게이트웨이 프런트엔드에서 클라이언트 TLS 연결을 종료합니다. 게이트웨이는 BackendTLSPolicy를 사용하여 게이트웨이와 백엔드 포드 간의 트래픽을 선택적으로 다시 암호화할 수 있습니다.
  • TLS 패스 스루: 암호화된 TLS 트래픽은 부하 분산기가 트래픽을 종료하거나 복호화하지 않고 게이트웨이를 통해 백엔드 포드로 직접 전달됩니다. TLSRoute 리소스를 사용하여 서버 이름 표시(SNI) 호스트 이름을 기준으로 트래픽을 라우팅합니다.

이 페이지에서는 게이트웨이 수준에서 업로드 및 관리되는 인증서를 사용하여 클라이언트-게이트웨이 경로를 보호하는 방법과 엔드 투 엔드 TLS 패스 스루를 구성하는 방법을 설명합니다. TLS 종료를 사용하여 포드 트래픽에 대한 게이트웨이를 보호하는 방법은 TLS를 사용하여 애플리케이션 트래픽에 대한 부하 분산기 보호를 참조하세요.

TLS 종료와 TLS 패스 스루 비교

GKE 게이트웨이는 TLS가 부하 분산기에서 복호화되는지 아니면 백엔드 워크로드로 직접 전달되는지에 따라 TLS 종료 및 TLS 패스 스루라는 두 가지 TLS 운영 모드를 지원합니다.

TLS 종료

TLS 종료를 사용하면 게이트웨이가 부하 분산기 프런트엔드에서 클라이언트의 TLS 연결을 종료합니다.

tls.mode 필드가 Terminate로 설정되고 protocol 필드가 HTTPS로 설정된 게이트웨이 리스너를 구성할 때 Kubernetes 보안 비밀, SSL 인증서 또는 인증서 관리자를 사용하여 TLS 인증서를 게이트웨이에 직접 연결합니다.

TLS 종료의 주요 특징은 다음과 같습니다.

  • 레이어 7 검사: 게이트웨이는 클라이언트 트래픽을 복호화하므로 HTTP 요청 속성(예: 헤더, 경로, 메서드)을 평가하고 HTTPRoute 리소스를 사용하여 트래픽을 라우팅할 수 있습니다.
  • 에지 보안: Google Cloud Armor 보안 정책, 웹 애플리케이션 방화벽(WAF) 규칙, Cloud CDN 에지 캐싱과의 통합을 지원합니다.
  • BackendTLSPolicy를 사용한 백엔드 암호화: 워크로드에 전송 중 엔드 투 엔드 암호화가 필요한 경우 BackendTLSPolicy 리소스를 구성하여 게이트웨이와 백엔드 포드 간의 트래픽을 다시 암호화할 수 있습니다.

다음 다이어그램은 백엔드 암호화와 함께 TLS 종료를 사용할 때 GKE 게이트웨이가 두 트래픽 경로를 모두 암호화하는 방법을 보여줍니다. 외부 클라이언트는 암호화된 HTTPS 요청(https://example.com)을 Virtual Private Cloud(VPC) 네트워크의 게이트웨이로 전송하고, 여기서 부하 분산기가 TLS 연결을 종료합니다. 그런 다음 부하 분산기는 별도의 재암호화된 연결을 설정하여 트래픽을 GKE 클러스터의 백엔드 Store 포드로 전달합니다.

TLS 종료를 사용한 클라이언트-게이트웨이 및 게이트웨이-백엔드 암호화

암호화 외에도 승인 정책을 사용하여 클라이언트-게이트웨이 경로를 보호할 수 있습니다. 승인 정책은 트래픽이 백엔드 포드로 라우팅되기 전에 수신 요청을 검사하고 클라이언트 ID, HTTP 헤더, 요청된 경로를 기반으로 액세스 제어를 적용하여 제로 트러스트 아키텍처를 지원합니다.

TLS 종료 및 백엔드 TLS를 구성하는 방법에 대한 자세한 내용은 게이트웨이 보안을 참조하세요.

TLS 패스 스루

TLS 패스스루를 사용하면 게이트웨이가 부하 분산기에서 페이로드를 복호화하지 않고 암호화된 TLS 트래픽을 백엔드 워크로드에 직접 프록시합니다.

tls.mode 필드가 Passthrough로 설정되고 protocol 필드가 TLS로 설정된 게이트웨이 리스너를 구성하면 게이트웨이가 TLS를 종료하거나 SSL 인증서를 보유하지 않습니다. 대신 부하 분산기는 TLS ClientHello 핸드셰이크에서 암호화되지 않은 서버 이름 표시(SNI) 호스트 이름만 검사하고 TLSRoute 리소스를 사용하여 암호화되지 않은 원시 TCP 스트림을 백엔드 포드로 라우팅합니다.

TLS 패스 스루의 주요 특징은 다음과 같습니다.

  • 엔드 투 엔드 암호화: 클라이언트에서 백엔드 포드로 전송되는 동안 트래픽이 암호화된 상태로 유지됩니다. 백엔드 애플리케이션은 인증서를 관리하고 TLS를 종료하며 페이로드를 복호화합니다.
  • 게이트웨이에서 인증서 관리 필요 없음: 인증서 또는 Kubernetes 보안 비밀을 게이트웨이 리스너에 연결하지 않습니다.
  • 레이어 4 프록시: 부하 분산기는 TLSRoute 리소스를 사용하여 암호화된 TCP 스트림을 전달하고 암호화되지 않은 TLS 핸드셰이크 메타데이터(예: SNI 호스트 이름)를 기반으로 트래픽을 라우팅합니다.
  • 보안 절충점: TLS 패스 스루는 클라우드 인프라와 비공개 키를 공유할 수 없는 규정 준수 요구사항이나 HTTP가 아닌 TLS 기반 프로토콜에 적합합니다. 하지만 레이어 7 부하 분산기 검사 및 Google Cloud Armor WAF 규칙과 같은 에지 보안 서비스는 제외됩니다.

다음 다이어그램은 TLS 패스 스루를 사용할 때 게이트웨이가 클라이언트에서 백엔드 포드로 트래픽을 암호화하고 라우팅하는 방법을 보여줍니다. 클라이언트는 store.example.com SNI 호스트 이름이 포함된 암호화된 TLS 요청을 게이트웨이로 전송합니다. 게이트웨이는 복호화 없이 암호화된 스트림을 대상 Store 포드로 직접 전달합니다.

클라이언트에서 백엔드 포드로의 엔드 투 엔드 암호화된 TLS 패스 스루

TLSRoute를 사용하여 TLS 패스 스루 게이트웨이를 배포하는 방법에 대한 자세한 내용은 TLS 패스 스루 게이트웨이 배포를 참조하세요.

이점

Gateway API를 사용하면 게이트웨이와 상호작용하는 다양한 역할에 유연성을 제공하여 다양한 방법으로 애플리케이션을 보호할 수 있습니다.

도메인 및 TLS 구성 소유자

Gateway API 모델에는 게이트웨이를 사용하거나 배포하는 다음과 같은 두 가지 역할이 있습니다.

  • 플랫폼 관리자: 클러스터 운영자는 전체 클러스터의 관리자입니다. 정책, 네트워크 액세스, 애플리케이션 권한을 관리합니다.
  • 애플리케이션 개발자: 애플리케이션 개발자는 자신의 애플리케이션 및 서비스 구성을 정의합니다.

다음은 두 애플리케이션 store-v1 및 store-v2의 TLS와 도메인 소유권에 영향을 미치는 게이트웨이 및 HTTPRoute 리소스의 필드를 보여주는 다이어그램입니다.

이 다이어그램에서 클러스터 운영자는 다음을 제어합니다.

  • 애플리케이션 개발자가 각 네임스페이스에서 앱에 사용할 수 있는 도메인
  • 다른 도메인을 종료하는 특정 인증서
  • 게이트웨이 소유자가 제공한 인증서
  • HTTPRoute 소유자가 인증서 생성을 위한 자체 호스트 이름을 지정할 수 있는지 여부

게이트웨이 정의에서 허용하는 경우 애플리케이션 개발자가 인증서를 생성하는 호스트 이름을 제어합니다.

이러한 운영 태스크를 분리하면 애플리케이션 개발자가 보다 분산된 제어를 위해 자체 HTTPRoute를 배포 및 관리할 수 있으며, 플랫폼 관리자가 TLS의 중앙 집중식 제어를 위해 게이트웨이를 배포 및 관리할 수 있습니다.

게이트웨이 인증서 관리

다음 방법 중 하나를 사용하여 게이트웨이를 보호할 수 있습니다.

Compute Engine API를 통해 Kubernetes 보안 비밀 또는 SslCertificate 리소스를 사용하는 경우 단일 게이트웨이에 인증서를 최대 15개까지 연결할 수 있습니다.

할당량 상향 요청 시 인증서 관리자를 통해 부하 분산기당 인증서를 최대 10,000,000개까지 연결할 수 있습니다.

Google Cloud SSL 인증서에 대한 자세한 내용은 SSL 인증서 개요를 참고하세요.

Kubernetes 보안 비밀

Gateway API 사양에서는 인증서를 저장하고 게이트웨이에 연결하기 위한 Kubernetes 보안 비밀을 지원합니다. Gateway.spec.tls.certificateRef 필드를 사용하여 Kubernetes 보안 비밀 하나 이상을 게이트웨이 하나와 연결할 수 있습니다.

Kubernetes 보안 비밀을 통해 보호되는 게이트웨이 리소스에는 다음과 같은 요구사항이 있습니다.

  • 게이트웨이 리스너 port 및 protocol을 443 및 HTTPS로 설정해야 합니다.
  • listener.tls.mode 필드를 Terminate로 설정해야 합니다.
  • listeners.tls 블록에서 TLS 사용자 인증 정보를 참조해야 합니다.

Kubernetes 보안 비밀을 사용하여 보호되는 게이트웨이 리소스에는 다음과 같은 제한사항이 있습니다.

  • HTTP와 HTTPS를 함께 사용하여 여러 리스너를 지정할 수 있지만 HTTPS 리스너만 지정된 보안 비밀을 사용하여 트래픽을 종료합니다.
  • 동일한 게이트웨이에서 HTTPS를 사용하는 리스너가 여러 개 있는 경우 리스너마다 고유한 호스트 이름이 있어야 합니다.
  • 단일 호스트 이름만 생략하거나 포트와 프로토콜 쌍마다 *를 할당할 수 있습니다.
  • 기본 인증서는 게이트웨이당 하나만 할당할 수 있습니다.

Kubernetes 보안 비밀을 사용하여 게이트웨이를 보호하는 방법은 Kubernetes 보안 비밀을 사용한 게이트웨이 보호를 참조하세요.

SSL 인증서

SSL 인증서는 부하 분산기에 인증서를 저장하고 전달합니다. SSL 인증서는 자체 관리형 인증서나 Google 관리 인증서일 수 있습니다.

  • 자체 관리형 SSL 인증서는 사용자가 직접 가져와 프로비저닝하고 갱신하는 인증서입니다.
  • Google 관리형 SSL 인증서는 Google Cloud 에서 자동으로 가져오고 관리하며 갱신하는 인증서입니다.

이 두 인증서 유형의 차이점에 대해 자세히 알아보려면 SSL 인증서 개요를 참조하세요.

SSL 인증서의 범위 및 위치는 이를 사용하는 게이트웨이의 범위 및 위치와 일치해야 합니다. 예를 들어 전역 SSL 인증서는 리전 게이트웨이에 사용될 수 없습니다.

다음 표에는 각 GatewayClass의 SSL 인증서 범위 및 위치 요구사항이 나와 있습니다.

GatewayClass SSL 인증서 범위 SSL 인증서 위치
gke-l7-global-external-managed 전역 SSL 인증서 전역
gke-l7-global-external-managed-mc
gke-l7-gxlb
gke-l7-gxlb-mc
gke-l7-regional-external-managed 지역 SSL 인증서 게이트웨이와 동일한 리전이어야 합니다.
gke-l7-regional-external-managed-mc
gke-l7-cross-regional-internal-managed-mc
gke-l7-rilb
gke-l7-rilb-mc

Google 관리형 SSL 인증서는 리전 게이트웨이와 호환되지 않습니다. 리전 게이트웨이를 보호하려면 인증서 관리자를 대신 사용하세요.

SSL 인증서를 사용하여 게이트웨이를 보호하는 방법은 SSL 인증서를 사용한 게이트웨이 보호를 참조하세요.

인증서 관리자

인증서 관리자는 TLS 인증서를 관리하는 중앙 위치입니다.

인증서 관리자를 사용하여 게이트웨이를 보호하면 다음이 가능합니다.

  • 인증서 관리자에서 만든 게이트웨이에서 CertificateMap을 직접 참조할 수 있습니다.
  • 자체 인증서를 관리할 수 있습니다.
  • 인증서 전파 시간을 개선할 수 있습니다.
  • 만료된 인증서 및 인증서 전파에 Cloud Monitoring을 사용할 수 있습니다.

인증서 관리자에서는 자체 관리형 SSL 인증서와 Google 관리 SSL 인증서를 모두 지원합니다. 인증서 관리자를 사용하여 게이트웨이를 보호하는 방법은 인증서 관리자를 사용한 게이트웨이 보호를 참조하세요.

GatewayClass TLS 지원

다음 표에서는 GKE가 각 GatewayClass에 지원하는 TLS 종료 방법을 설명합니다.

GatewayClass gke-l7-global-external-managed
gke-l7-global-external-managed-mc
gke-l7-gxlb
gke-l7-gxlb-mc 		gke-l7-regional-external-managed
gke-l7-regional-external-managed-mc
gke-l7-rilb
gke-l7-rilb-mc 		gke-l7-cross-regional-internal-managed-mc
클라이언트-게이트웨이 TLS 지원됨 지원됨
백엔드 TLS에 대한 게이트웨이 지원됨 지원됨
Google Cloud 인증서 리소스 전역 SSL 인증서
CertificateMap		 지역 SSL 인증서
TLS 패스 스루(TLSRoute) 지원되지 않음 지원됨 지원됨
Kubernetes 보안 비밀을 사용하는 자체 관리형 인증서 지원됨 지원됨 지원되지 않음
자체 관리형 Compute Engine SSL 인증서 지원됨 지원됨 지원되지 않음
Google 관리형 Compute Engine SSL 인증서 지원됨 지원되지 않음 지원되지 않음
인증서 관리자를 사용하는 자체 관리형 SSL 인증서 지원됨 지원됨 지원됨
인증서 관리자를 사용하는 Google 관리형 SSL 인증서 지원됨 지원됨 지원됨

승인 및 액세스 제어

GKE 게이트웨이는 GCPAuthzPolicy 커스텀 리소스를 사용하여 ID 기반 액세스 제어를 지원합니다. 이 리소스를 사용하면 플랫폼 관리자가 북남 트래픽에 대한 명시적인 ALLOW 또는 DENY 규칙을 정의할 수 있습니다.

또한 게이트웨이는 GCPAuthzExtension 리소스를 사용하여 Service Extensions와 통합할 수 있습니다. 이 리소스를 사용하면 게이트웨이가 외부, 커스텀 또는 서드 파티 승인 엔진(예: Identity-Aware Proxy)에 인라인 콜아웃을 수행하여 요청을 실시간으로 평가할 수 있습니다.

다음 단계