서비스 보안 사용 사례(기존)

이 문서에서는 일반적인 Cloud Service Mesh 보안 사용 사례를 설명합니다. 이 정보를 사용하면 니즈에 가장 적합한 보안 모델을 결정할 수 있습니다. 또한 이 문서에서는 사용 사례마다 구성해야 하는 항목을 개략적으로 설명합니다.

서비스 보안 개요는 Cloud Service Mesh 서비스 보안을 참조하세요.

참고: 이 가이드는 Google Cloud API가 포함된 Cloud Service Mesh만 지원하고 Istio API를 지원하지 않습니다. 자세한 내용은 Cloud Service Mesh 개요를 참조하세요.

이 문서는 부하 분산 API를 사용하는 구성에 적용됩니다. 이 문서는 기존 문서입니다.

메시의 서비스에 상호 TLS 사용 설정

서비스 메시에서 상호 TLS(mTLS)를 사용 설정하면 통신의 클라이언트와 서버가 모두 ID를 증명하고 통신을 암호화해야 합니다.

서비스 메시의 상호 TLS(mTLS) 인증(확대하려면 클릭)

다음 섹션에서는 전역 전달 규칙, 대상 HTTPS 프록시, URL 맵에 대해 다루지 않습니다. 메시를 만드는 데 이러한 Compute Engine API 리소스가 필요하지만 mTLS를 사용 설정할 때 이를 업데이트할 필요는 없습니다.

다음 Compute Engine API 리소스를 구성하면 앞선 패턴을 얻을 수 있습니다. 이 다이어그램에서는 사이드카 프록시를 사용하지만 mTLS로 프록시리스 gRPC 애플리케이션을 구성하면 동일한 리소스를 사용할 수 있습니다.

메시 내 mTLS의 Compute Engine API 리소스(확대하려면 클릭)

이러한 모델을 만들려면 다음 안내를 따르세요.

1. 클라이언트 전송 계층 보안(TLS) 정책을 만듭니다.
2. 서버 TLS 정책을 만듭니다.
3. 새 클라이언트 TLS 정책을 참조하도록 기존 전역 백엔드 서비스의 securitySettings 필드를 업데이트합니다.

4. 엔드포인트 정책을 만듭니다.

   1. server_tls_policy 필드에서 서버 TLS 정책을 참조합니다.

   2. EndpointMatcher를 정의하여 인바운드 트래픽에서 인증을 시행해야 하는 Cloud Service Mesh 클라이언트를 선택합니다.

      Cloud Service Mesh 클라이언트를 선택하는 방법은 Cloud Service Mesh 클라이언트 부트스트랩 구성에 지정된 라벨을 기반으로 합니다. 이러한 라벨을 수동으로 제공하거나 Google Kubernetes Engine(GKE) 배포에 제공되는 라벨을 기반으로 자동으로 채울 수 있습니다.

      위의 다이어그램에서 "mesh-service":"true" 라벨은 엔드포인트 정책과 Cloud Service Mesh 클라이언트에 구성되어 있습니다. 배포에 적합한 라벨을 선택할 수 있습니다.

   3. 필요한 경우 데이터 영역 항목의 지정된 포트에 인바운드 요청이 수신될 때만 정책을 적용하는 TrafficPortSelector를 정의합니다.

다음 다이어그램은 Envoy 또는 프록시리스 gRPC 애플리케이션 사용 여부와 상관없이 mTLS를 위해 구성한 Compute Engine 리소스를 보여줍니다.

메시 내 mTLS의 Compute Engine API 리소스(확대하려면 클릭)

다음 다이어그램에서는 트래픽 흐름을 보여주며 mTLS를 사용 설정하도록 구성한 Compute Engine API 리소스를 나열합니다. 서비스 B의 GKE pod와 함께 있는 로컬 사이드카 프록시가 통신의 엔드포인트입니다.

메시 내 mTLS의 Compute Engine API 리소스 및 트래픽 흐름(확대하려면 클릭)

엔드포인트 정책에서 다음을 수행합니다.

1. 엔드포인트 일치자를 사용하여 엔드포인트 집합을 선택하고 필요한 경우 엔드포인트의 포트를 선택합니다.

   1. 엔드포인트 일치자를 사용하면 Cloud Service Mesh 클라이언트가 구성을 수신할지 여부를 결정하는 규칙을 지정할 수 있습니다. 이 규칙은 데이터 영역 항목이 컨트롤 플레인(이 경우 Cloud Service Mesh)에 제공하는 xDS 메타데이터를 기반으로 합니다.

      다음과 같이 Cloud Service Mesh 클라이언트에 라벨을 추가할 수 있습니다.

      • Cloud Service Mesh 클라이언트 부트스트랩 파일에서 이 메타데이터를 수동으로 지정할 수 있습니다.

      • 또는 GKE를 사용할 때 키-값 쌍을 demo_server.yaml 또는 demo_client.yaml 파일의 env 섹션에 추가하면 메타데이터를 자동으로 채울 수 있습니다. 이 값은 Envoy 설정 가이드와 프록시리스 gRPC 설정 가이드에 나와 있습니다.

        예를 들어 Envoy의 경우 키 앞에 ISTIO_META_ 프리픽스를 추가할 수 있습니다. ISTIO_META_로 시작하는 프록시 환경 변수 이름은 생성된 부트스트랩에 포함되어 xDS 서버로 전송됩니다.

        - name: ISTIO_META_app
          value: 'review'
        - name: ISTIO_META_version
          value: 'canary'
        

   2. 포트를 지정하면 엔드포인트 정책에서 참조한 정책이 동일한 포트를 지정하는 인바운드 요청에만 시행됩니다. 포트를 지정하지 않으면 Cloud Service Mesh 클라이언트에 부트스트랩 정보로 제공되는 TRAFFICDIRECTOR_INBOUND_BACKEND_PORTS 필드에 있는 포트를 지정하는 인바운드 요청에 정책이 시행됩니다.

2. 요청에서 결정할 엔드포인트를 구성하는 클라이언트 TLS, 서버 TLS, 승인 정책을 참조합니다.

호환되지 않는 TLS 모드를 구성하면 통신이 중단될 수 있습니다. 예를 들어 전역 백엔드 서비스에서 OPEN을 설정하거나 클라이언트 TLS 정책 필드를 비워 두고 MTLS를 엔드포인트 정책의 서버 TLS 정책 값으로 설정하면 통신 시도가 실패합니다. 이는 mTLS 거부만 수락하도록 구성된 엔드포인트에서 인증되지 않은 통신 채널을 설정하려고 하기 때문입니다.

전역 백엔드 서비스와 엔드포인트 정책에 각각 연결된 클라이언트 TLS 정책과 서버 TLS 정책의 차이점은 다음과 같습니다.

• 클라이언트 TLS 정책은 전역 백엔드 서비스에 적용되며 서비스를 처리할 때 사용할 TLS 모드, ID, 피어 검증 접근방식을 Envoy 프록시 또는 프록시리스 클라이언트에 알려줍니다.
• 서버 TLS 정책은 엔드포인트 정책에 연결됩니다. 수신 연결에 사용할 TLS 모드, ID, 피어 검증 접근방식을 서버에 알려줍니다.

인그레스 게이트웨이에 TLS 사용 설정

메시 내부 통신에 mTLS를 설정한 후 메시에 들어오는 트래픽, 즉 인그레스 트래픽을 보호하는 것이 좋습니다. Cloud Service Mesh에서 인그레스 트래픽이 TLS 암호화 통신 채널을 사용하도록 데이터 영역을 구성할 수 있습니다.

이 목표를 달성하려면 다음 아키텍처 옵션 중 하나를 선택합니다.

• 메시의 서비스가 부하 분산기에서 전송되는 트래픽의 TLS를 종료합니다. 이 모델에서는 메시의 각 서비스가 부하 분산기 구성, 특히 부하 분산기의 URL 맵에서 백엔드로 구성됩니다.
• 인그레스 게이트웨이가 메시의 서비스로 트래픽을 전달하기 전에 부하 분산기에서 전송되는 트래픽의 TLS를 종료합니다. 이 모델에서는 메시의 전용 서비스, 인그레스 게이트웨이가 부하 분산기 구성, 특히 부하 분산기의 URL 맵에서 백엔드로 구성됩니다.

이 섹션에서는 두 옵션을 모두 설명합니다.

메시의 서비스가 부하 분산기에서 전송되는 트래픽의 TLS를 종료

Google Cloud 외부의 클라이언트에서 서비스를 사용할 수 있게 하려면 외부 애플리케이션 부하 분산기를 사용할 수 있습니다. 클라이언트는 트래픽을 부하 분산기의 전역 Anycast 가상 IP 주소(VIP)로 전송한 후 이 트래픽을 메시의 서비스로 전달합니다. 즉, 외부 클라이언트가 메시의 서비스에 연결해야 하는 경우 연결 두 개가 있습니다.

메시의 서비스에 대한 TLS(확대하려면 클릭)

내부 애플리케이션 부하 분산기를 사용할 때도 같은 패턴이 적용됩니다. 내부 클라이언트의 트래픽이 먼저 부하 분산기에 도달한 후 백엔드에 대한 연결이 설정됩니다.

두 연결을 모두 보호하려면 다음을 수행합니다.

1. 외부 애플리케이션 부하 분산기를 사용하여 클라이언트와 부하 분산기 간의 연결을 보호합니다.
2. 메시의 서비스와 연결을 설정하려고 할 때 HTTPS 또는 HTTP/2 프로토콜을 사용하도록 부하 분산기를 구성합니다.
3. Cloud Service Mesh 클라이언트가 HTTPS를 종료하고 클라이언트(이 경우 부하 분산기)에 인증서를 제공하도록 Cloud Service Mesh를 구성합니다.

1단계와 2단계에 대한 자세한 내용은 멀티 리전, 콘텐츠 기반 외부 HTTPS 부하 분산기 설정을 참조하세요.

Cloud Service Mesh 보안을 설정할 때 다양한 Compute Engine API 리소스를 구성할 수 있습니다. 이러한 리소스는 부하 분산기에 구성한 리소스와 별개입니다. 즉, 부하 분산 스키마가 다른 Compute Engine API 리소스 집합(전역 전달 규칙, 대상 프록시, URL 맵, 전역 백엔드 서비스)을 만듭니다.

• 한 리소스 집합에서 부하 분산 스킴 INTERNAL_MANAGED를 사용하는 부하 분산기를 구성합니다.
• 다른 리소스 집합에서는 부하 분산 스킴 INTERNAL_SELF_MANAGED를 사용하는 Cloud Service Mesh를 구성합니다.

3단계에서 Cloud Service Mesh 클라이언트가 HTTPS를 종료하고 클라이언트에 인증서를 제공하도록 Cloud Service Mesh를 구성합니다.

메시의 서비스에 대한 TLS의 Compute Engine API 리소스(확대하려면 클릭)

이 모델에서는 다음과 같은 작업을 수행하게 됩니다.

1. 서버 TLS 정책을 만듭니다. transportAuthentication에 terminationTls를 구성합니다.
2. 엔드포인트 정책을 만듭니다.
   1. authentication 필드에서 서버 TLS 정책을 참조합니다.
   2. EndpointMatcher를 정의하여 인바운드 트래픽에서 인증을 시행해야 하는 xDS 데이터 영역 항목을 선택합니다.
   3. 필요한 경우 Cloud Service Mesh 클라이언트의 지정된 포트에 인바운드 요청이 수신될 때만 정책을 적용하는 TrafficPortSelector를 정의합니다.

외부 애플리케이션 부하 분산기가 이미 메시의 서비스에 대한 TLS 연결을 시작하도록 구성되어 있으므로 Cloud Service Mesh에서 TLS 연결을 종료하도록 Cloud Service Mesh 클라이언트만 구성하면 됩니다.

인그레스 게이트웨이가 메시의 서비스로 트래픽을 전달하기 전에 부하 분산기에서 전송되는 트래픽의 TLS를 종료

인그레스 게이트웨이만 부하 분산기에 노출하려면 인그레스 게이트웨이 배포 패턴을 사용하면 됩니다. 이 패턴에서 부하 분산기는 메시의 서비스에 직접 주소를 지정하지 않습니다. 대신 미들 프록시는 메시 에지에 위치하고 Cloud Service Mesh에서 수신하는 구성에 따라 트래픽을 메시 내부의 서비스로 라우팅합니다. 미들 프록시는 Compute Engine 관리형 인스턴스 그룹의 가상 머신(VM) 인스턴스에 배포한 Envoy 프록시일 수 있습니다.

메시 내 mTLS를 사용한 인그레스 게이트웨이에 대한 TLS(확대하려면 클릭)

보안 관점에서 TLS를 종료하도록 인그레스 게이트웨이를 구성하고 필요한 경우 연결이 mTLS로 보호되도록 메시 내에서 연결을 구성합니다. 여기에는 인그레스 게이트웨이와 메시 내 서비스 간 연결과 메시 내 서비스 간의 연결이 포함됩니다.

구성 관점에서 다음 작업을 수행합니다.

1. 앞에서 설명한 대로 서비스 메시를 구성하고 메시 내 통신에 대한 mTLS를 사용 설정합니다.
2. 앞에서 설명한 대로 트래픽을 인그레스 게이트웨이로 라우팅하고 HTTPS 프로토콜을 사용하여 연결을 시작하도록 부하 분산기를 구성합니다.
3. 인그레스 게이트웨이와 해당 서버 TLS 정책을 나타내는 Compute Engine API 리소스 집합을 만듭니다.

3단계에서 다음과 같이 HTTPS를 종료하고 인증서를 제공하도록 Cloud Service Mesh를 구성합니다.

1. 전역 전달 규칙과 대상 HTTPS 프록시를 만들어 메시로의 인그레스 트래픽 경로를 나타냅니다.

2. 메시의 기존 URL 맵을 이 타겟 HTTPS 프록시에 연결합니다. URL 맵에는 메시 및 mTLS를 구성할 때 제공된 구성에 따라 메시의 다양한 전역 백엔드 서비스에 대한 참조가 이미 포함되어 있습니다.

3. 서버 TLS 정책을 만들고 serverCertificate를 구성합니다.

4. 서버 TLS 정책 리소스를 타겟 HTTPS 프록시에 연결합니다.

인그레스 게이트웨이 패턴은 공유 VPC를 사용하는 대규모 조직에 특히 유용합니다. 이러한 설정에서는 팀이 인그레스 게이트웨이를 통해서만 서비스에 대한 액세스를 허용할 수 있습니다. 위의 다이어그램에서 전역 전달 규칙을 구성하는 경우 메시를 구성할 때 제공된 주소(이 예시의 경우 메시 주소는 10.0.0.1)와 다른 IP 주소(이 예시의 경우 10.0.0.2)를 제공한다는 점에 유의하세요. Cloud Service Mesh로 구성된 xDS 데이터 영역 항목을 통해 통신하는 클라이언트에서 이 주소를 사용해 인그레스 게이트웨이에 액세스할 수 있습니다.

예를 들어 다음과 같이 가정합니다.

• 2개의 서비스 프로젝트(1 및 2)가 모두 동일한 공유 VPC 네트워크에 연결되어 있습니다.

• 서비스 프로젝트 1에는 Cloud Service Mesh에서 구성된 서비스 메시가 포함되어 있습니다.

  서비스 프로젝트 1에서 메시와 인그레스 게이트웨이를 구성했습니다. 이 인그레스 게이트웨이는 10.0.0.2 주소(VIP)에서 연결 가능합니다.

• 서비스 프로젝트 2에는 Cloud Service Mesh에서 구성된 서비스 메시가 포함되어 있습니다.

  서비스 프로젝트 2에는 자체 인그레스 게이트웨이가 있거나 없을 수 있습니다.

• Cloud Service Mesh는 각 서비스 프로젝트에서 Cloud Service Mesh 클라이언트를 구성합니다. 클라이언트는 동일한 네트워크를 사용하도록 부트스트랩됩니다.

이 구성을 제공하면 서비스 프로젝트 2 메시의 클라이언트는 10.0.0.2 VIP를 사용하여 서비스 프로젝트 1의 인그레스 게이트웨이와 통신할 수 있습니다. 그러면 서비스 프로젝트 1 소유자가 메시에 들어오는 트래픽과 관련된 라우팅, 보안, 기타 정책을 구성할 수 있습니다. 실제로 서비스 프로젝트 1 소유자가 메시의 클라이언트가 10.0.0.2의 서비스에 연결할 수 있음을 알릴 수 있습니다.

제한사항

Cloud Service Mesh 서비스 보안은 GKE에서만 지원됩니다. Compute Engine으로는 서비스 보안을 배포할 수 없습니다.

다음 단계

• Envoy 프록시로 Cloud Service Mesh 서비스 보안을 구성하려면 Envoy로 Cloud Service Mesh 서비스 보안 설정(기존)을 참조하세요.
• 프록시리스 gRPC 애플리케이션으로 Cloud Service Mesh 서비스 보안을 구성하려면 프록시리스 gRPC로 Cloud Service Mesh 서비스 보안 설정(기존)을 참조하세요.