GKE 클러스터에서 Cloud Service Mesh 이그레스 게이트웨이 사용 시 권장사항
이 문서에서는 Cloud Service Mesh 이그레스 게이트웨이 및 기타 Google Cloud 컨트롤을 사용하여 Google Kubernetes Engine(GKE) 클러스터에 배포된 워크로드에서 아웃바운드 트래픽(이그레스)을 보호하는 방법을 설명합니다. 이러한 제어는 소스 애플리케이션의 ID, 팀의 네임스페이스, 대상 도메인, 기타 나가는 요청의 속성을 기준으로 외부 서비스에 대해 연결을 제한할 수 있습니다.
고유 클러스터에서 이그레스 제어 구성에 대해서는 청사진으로 사용할 수 있는 보조 튜토리얼이 있습니다.
이 문서의 주요 대상에는 하나 이상의 소프트웨어 제공 팀에서 사용되는 GKE 클러스터를 관리하는 네트워크, 플랫폼, 보안 엔지니어가 포함됩니다. 여기에 설명된 제어는 규정 준수를 입증해야 하는 조직에 특히 유용할 수 있습니다(예: GDPR 및 PCI).
소개
기존의 네트워크 보안에는 일련의 애플리케이션으로 보안 경계를 정의하는 방법이 사용되었습니다. 이러한 경계에 소스 및 대상 IP 주소에 따라 트래픽을 허용하거나 거부하는 방화벽이 사용되었고, 경계 내부에 포함된 애플리케이션과 트래픽은 신뢰하는 방식이 사용되었습니다. 하지만 이러한 신뢰는 위험을 수반합니다. 악의적인 내부자 또는 보안 경계를 훼손시키는 누구라도 네트워크 내부를 자유롭게 이동하고, 데이터를 액세스 및 유출하고, 타사 시스템을 공격하고, 관리 시스템을 조작할 수 있습니다.
Kubernetes 클러스터에서 실행되는 워크로드가 인터넷 호스트에 이그레스 연결을 수행할 때 기존의 IP 기반 보안 제어를 사용하면 다음과 같은 이유로 복잡한 문제가 발생할 수 있습니다.
포드 IP 주소는 연결을 수행하는 워크로드 아이덴티티를 정확하게 반영하지 않습니다. Kubernetes 환경에서 포드 IP 주소는 임시로 할당되며 포드가 들어오고 나감에 따라 자주 재사용됩니다.
특정 대상 호스트에 사용되는 소규모의 고정 IP 주소 집합을 식별하는 것이 불가능한 경우가 종종 있습니다. IP 주소는 자주 변경되고, 리전별로도 다르고, 큰 범위에서 가져올 수도 있고, 캐시, 프록시, CDN을 나타낼 수도 있습니다.
소스 IP의 공유 범위를 사용하고, 동일한 멀티 테넌트 클러스터를 공유하는 여러 팀의 외부 연결 요구사항이 서로 다를 수 있습니다.
Cloud Service Mesh는 Google에서 완전히 지원되는 오픈소스 Istio 서비스 메시 배포판입니다. 서비스 메시는 애플리케이션 통신 연결, 관리, 보안을 위한 단일 방법을 제공합니다. 서비스 메시는 애플리케이션 중심 방식에 따라 네트워크 IP 중심의 접근 방식 대신 신뢰할 수 있는 애플리케이션 ID를 사용합니다.
기존 애플리케이션 코드를 수정할 필요 없이 서비스 메시지를 투명하게 배포할 수 있습니다. 서비스 메시를 사용하면 네트워크 동작에 대해 선언적 제어를 제공함으로써 네트워크 관리자 책임 중 애플리케이션 기능을 제공 및 출시하는 개발 팀 업무를 분리하는 데 도움이 됩니다.
Cloud Service Mesh는 메시 에지에서 이그레스 게이트웨이라고 부르는 배포 옵션 독립형 전달 프록시를 제공합니다. 이 가이드에서는 이그레스 게이트웨이 프록시 기능을 Google Cloud 기능과 결합하여 GKE 클러스터에 배포되는 워크로드에서 아웃바운드 트래픽을 제어, 승인, 관측하는 방법을 설명합니다.
심층 방어 아키텍처
아래 다이어그램은 여러 팀에서 사용되는 클러스터에 대해 이그레스 트래픽의 세밀한 제어를 위한 심층 방어 접근 방법이 사용되는 아키텍처를 보여줍니다. 이러한 제어는 레이어 4(전송) 및 레이어 7(애플리케이션) 네트워크 제어 모두를 기반으로 합니다.
이 아키텍처에는 다음과 같은 리소스 및 제어가 사용됩니다.
비공개 GKE 클러스터: 비공개 GKE 클러스터의 노드에는 내부 IP 주소만 포함되며, 기본적으로 인터넷에 연결되지 않습니다.
Cloud NAT: Cloud NAT는 비공개 클러스터의 아웃바운드 인터넷 액세스를 허용합니다.
Virtual Private Cloud(VPC) 방화벽 규칙: GKE 클러스터의 노드 연결에 레이어 4(전송) 제어를 적용하도록 VPC 방화벽 규칙을 구성합니다. 서비스 계정 또는 네트워크 태그를 기준으로 VM에 VPC 방화벽 규칙을 적용할 수 있습니다.
서로 다른 서비스 계정을 포함하는 GKE 노드 풀: 노드가 속하는 노드 풀을 기준으로 서로 다른 방화벽 규칙을 적용하도록 구성할 수 있습니다.
Kubernetes 네임스페이스: 각 팀에 대해 네임스페이스를 만들어 격리 및 위임 관리 제어를 제공합니다. 네트워크 관리자는 전용 네임스페이스를 사용하여 이그레스 게이트웨이를 배포하고 외부 호스트 라우팅을 구성합니다.
Kubernetes 네트워크 정책: 네트워크 정책을 사용하면 레이어 4 제어를 포드에 적용할 수 있습니다. 각 네트워크 정책은 네임스페이스로 범위가 지정됩니다. 네임스페이스의 특정 포드로 더 세밀하게 범위를 지정할 수 있습니다.
이그레스 게이트웨이: 메시 내에서 포드를 나가는 트래픽은 전용 노드에서 실행되는 전용 이그레스 게이트웨이 프록시를 통해 전달됩니다. 트래픽에 따라 복제본 수가 확장 및 축소될 수 있도록 수평형 포드 자동 확장 처리를 사용하여 이그레스 게이트웨이를 배포합니다.
승인 정책: 메시 승인 정책을 사용하여 메시 내 포드 간 트래픽 및 메시를 나가는 트래픽에 레이어 7(애플리케이션) 제어를 적용합니다.
사이드카 리소스: 사이드카 리소스를 사용하여 각 워크로드 포드에서 실행되는 사이드카 프록시의 구성 범위를 제어합니다. 사이드카 리소스를 사용하여 네임스페이스, 포드 및 워크로드에 표시되는 외부 서비스를 구성할 수 있습니다.
비공개 Google 액세스: 이 옵션을 사용하면 비공개 클러스터의 노드 및 포드가 Google API에 액세스하고 Container Registry에서 Docker 이미지를 가져올 수 있습니다.
GKE 워크로드 아이덴티티: 워크로드 아이덴티티를 사용하면 보안 비밀을 처리할 필요 없이 최소 권한의 원칙에 따라 Identity and Access Management(IAM)를 사용하여 특정 워크로드에 API 권한을 부여할 수 있습니다.
이그레스 제어 구성
이그레스 게이트웨이를 사용하여 메시에서 이그레스 트래픽을 보호할 경우, 이 섹션에 설명된 심층 방어 제어를 구성하는 것이 좋습니다.
Cloud NAT에 비공개 GKE 사용
보안이 중요할 때 많은 조직의 첫 번째 요구사항은 해당 워크로드에 공개 IP 주소를 할당하지 않는 것입니다. 비공개 GKE 클러스터는 이러한 요구사항을 충족시켜 줍니다. VPC의 보조 범위의 IP 주소가 포드 및 서비스에 할당되도록 비공개 클러스터에 VPC 기반 모드를 구성할 수 있습니다. VPC 기반 포드 IP 주소는 기본적으로 VPC 네트워크 내에서 라우팅 가능합니다.
일부 워크로드는 VPC 네트워크 외부의 서비스 및 인터넷 액세스가 필요할 수 있습니다. 공개 IP 주소를 가질 필요 없이 워크로드가 외부 호스트에 연결하도록 허용하려면 네트워크 주소 변환(NAT)을 제공하도록 Cloud NAT를 구성합니다.
이그레스 게이트웨이가 외부 대상에 대해 충분한 수의 동시 연결을 수행할 수 있도록 Cloud NAT가 구성되었는지 확인합니다. VM당 최소 포트 수를 적절하게 설정하면 포트 소진 및 연결 재사용 지연 시간 관련 문제를 방지할 수 있습니다. 자세한 내용은 Cloud NAT 주소 및 포트 개요를 참조하세요. 이그레스 게이트웨이 복제본 수를 늘리면 엔드포인트에 독립적인 매핑 충돌 가능성을 줄이는 데 도움이 됩니다.
Google API 및 서비스를 위한 비공개 Google 액세스 구성
워크로드에 Google API 및 서비스에 대한 액세스가 필요할 수 있습니다. 커스텀 DNS 영역과 비공개 Google 액세스를 사용하면 4개의 IP 주소 집합을 사용하는 비공개 VPC 서브넷에서 Google API에 대한 연결을 허용할 수 있습니다. 이러한 IP 주소를 사용할 때는 포드가 외부 IP 주소를 가질 필요가 없으며 트래픽이 Google 네트워크를 벗어나지 않습니다. VPC 서비스 제어 사용 여부에 관계없이 private.googleapis.com(199.36.153.8/30) 또는 restricted.googleapis.com(199.36.153.4/30)을 사용할 수 있습니다.
워크로드 아이덴티티 및 IAM을 사용하여 Google API 및 서비스 추가 보안
GKE 워크로드가 Google API에 인증하고 관리자가 IAM을 사용하여 '최소 권한' 승인 제어를 적용할 수 있게 하려면 워크로드 아이덴티티를 사용하는 것이 좋습니다.
비공개 Google 액세스, 워크로드 아이덴티티, IAM을 사용할 때는 워크로드 포드가 이그레스 게이트웨이를 우회하고 Google API 및 서비스에 직접 연결하도록 허용해도 안전합니다.
관리 제어를 위해 Kubernetes 네임스페이스 사용
네임스페이스는 사용자, 팀, 테넌트가 많은 환경에 유용한 조직 리소스입니다. 네임스페이스는 가상 클러스터와 비슷하며, Kubernetes 리소스 그룹에 대한 관리 책임을 다른 관리자에게 위임할 수 있게 해줍니다.
네임스페이스는 관리 제어의 격리를 위해 중요한 기능입니다. 하지만 기본적으로 노드 격리, 데이터 영역 격리, 네트워크 격리를 제공하지 않습니다.
Cloud Service Mesh는 서비스 메시 내에서 Kubernetes 네임스페이스를 테넌시 단위로 사용하여 빌드됩니다. 메시 승인 정책 및 사이드카 리소스는 네트워크 트래픽의 네임스페이스, ID, 레이어 7(애플리케이션) 속성을 기준으로 가시성 및 액세스를 제한할 수 있습니다.
마찬가지로 Kubernetes 네트워크 정책을 사용하여 레이어 4(전송)에서의 네트워크 연결을 허용하거나 거부할 수 있습니다.
전용 게이트웨이 노드에서 이그레스 게이트웨이 실행
전용 게이트웨이 노드 풀의 노드에서 이그레스 게이트웨이를 실행하면 몇 가지 장점이 있습니다. 외부 연결 노드가 강화된 구성을 사용할 수 있고, 워크로드가 외부 호스트에 직접 연결하지 못하도록 방지하는 VPC 방화벽 규칙을 구성할 수 있습니다. 클러스터 자동 확장 처리를 사용하여 노드 풀을 독립적으로 자동 확장할 수 있습니다.
이그레스 게이트웨이의 개별 관리 제어를 위해서는 전용 istio-egress 네임스페이스에 배포합니다. 하지만 네임스페이스는 클러스터 전역 리소스이며, 이를 사용해서 배포를 실행할 노드를 제어하는 것이 가능하지 않습니다. 배포 제어를 위해서는 게이트웨이 노드 풀의 멤버로 라벨이 지정된 노드에서 실행되도록 이그레스 게이트웨이 배포에 대해 노드 선택기를 사용합니다.
게이트웨이 포드만 게이트웨이 노드에서 실행되는지 확인합니다. 다른 포드는 게이트웨이 노드에서 내보내야 합니다. 그렇지 않으면 이그레스 제어가 우회될 수 있습니다. taint 및 톨러레이션(toleration)을 사용하여 워크로드가 특정 노드에서 실행되지 않도록 방지할 수 있습니다. 게이트웨이 노드 풀에서 노드를 taint하고 이그레스 게이트웨이 배포에 해당 톨러레이션(toleration)을 추가해야 합니다.
특정 노드에 VPC 방화벽 규칙 적용
기본 노드 풀에서 실행되는 워크로드의 이그레스 트래픽이 게이트웨이 노드 풀에서 실행되는 이그레스 게이트웨이를 통과하도록 서비스 메시 라우팅을 구성합니다. 하지만 워크로드가 메시 프록시를 우회할 수 있는 방법이 많기 때문에 메시의 라우팅 구성을 보안 경계로 신뢰하지 않아야 합니다.
애플리케이션 워크로드가 외부 호스트에 직접 연결하지 못하도록 방지하려면 기본 노드 풀의 노드에 제한적인 이그레스 방화벽 규칙을 적용합니다. 여기에서 실행되는 이그레스 게이트웨이 포드가 외부 호스트에 연결할 수 있도록 게이트웨이 노드에 개별적인 방화벽 규칙을 적용합니다.
VPC 방화벽 규칙을 만들 때는 방화벽 규칙이 허용하거나 거부하는 포트 및 프로토콜과 규칙이 적용되는 트래픽 방향을 지정합니다. 이그레스 규칙은 나가는 트래픽에 적용되고 인그레스 규칙은 들어오는 트래픽에 적용됩니다. 이그레스 기본값은 allow이고, 인그레스 기본값은 deny입니다.
방화벽 규칙은 지정할 수 있는 우선순위 번호를 기준으로 적용됩니다. 방화벽 규칙은 스테이트풀(Stateful)입니다. 즉, VM의 특정 트래픽이 허용되면 동일 연결을 사용하는 반환 트래픽도 허용됩니다.
다음 다이어그램은 노드에 할당되는 서비스 계정을 기준으로 서로 다른 두 노드 풀의 노드에 방화벽 규칙을 개별적으로 적용하는 방법을 보여줍니다. 이 경우 기본 deny all 방화벽 규칙은 전체 VPC의 이그레스 액세스를 거부합니다. 클러스터 작동에 필요한 기본 방화벽 규칙을 재정의하지 않도록 방지하기 위해서는 deny all 규칙에 65535와 같은 낮은 우선순위를 사용해야 합니다. 추가적이고 더 높은 우선 순위의 이그레스 방화벽 규칙은 포트 80 및 443으로 외부 호스트에 직접 연결하도록 허용하기 위해 게이트웨이 노드에 적용됩니다. 기본 노드 풀에는 외부 호스트에 대한 액세스 권한이 없습니다.
포드 및 네임스페이스에 대해 Kubernetes 네트워크 정책을 방화벽으로 사용
Kubernetes 네트워크 정책을 사용하여 심층 방어 전략의 일부로 추가적인 보안 레이어를 적용할 수 있습니다. 네트워크 정책은 네임스페이스 범위로 지정되며, 레이어 4(전송)에서 작동합니다. 네트워크 정책을 사용하면 다음과 같이 인그레스 및 이그레스를 제한할 수 있습니다.
- 네임스페이스 사이
- 네임스페이스 내 포드
- 특정 포트 및 IP 블록
네트워크 정책에 따라 네임스페이스의 포드가 선택된 다음 명시적으로 허용되지 않는 연결은 거부됩니다. 여러 네트워크 정책이 적용될 때는 추가적으로 한 번에 결과가 적용됩니다. 정책의 적용 순서는 중요하지 않습니다.
보조 튜토리얼에는 다음과 같은 네트워크 정책 예시가 포함되어 있습니다.
- 워크로드 네임스페이스에서
istio-system및istio-egress네임스페이스로의 이그레스 연결을 허용합니다. 포드는istiod및 이그레스 게이트웨이에 연결할 수 있어야 합니다. - 워크로드가 워크로드 네임스페이스에서
kube-system네임스페이스의 포트 53으로 DNS 쿼리를 수행하도록 허용합니다. - 선택적으로 동일한 네임스페이스의 워크로드가 서로 연결하도록 허용합니다.
- 선택적으로 서로 다른 애플리케이션 팀에서 사용되는 네임스페이스 간의 이그레스 연결을 허용합니다.
- 워크로드 네임스페이스에서 Google API용 VIP로의 이그레스 연결을 허용합니다(비공개 Google 액세스를 사용하여 제공됨). Cloud Service Mesh는 관리형 CA를 제공하고 이를 API로 제공하므로, 사이드카 프록시가 여기에 연결할 수 있어야 합니다. 또한 일부 워크로드에 Google API 액세스가 필요할 수 있습니다.
- 사이드카 프록시 및 워크로드가 Google API에 대해 메타데이터 쿼리 및 인증을 수행할 수 있도록 워크로드 네임스페이스에서 GKE 메타데이터 서버로의 이그레스 연결을 허용합니다.
기본적으로 사이드카 프록시를 워크로드 포드에 삽입하면 프록시가 모든 인바운드 및 아웃바운드 TCP 트래픽을 캡처하도록 iptables 규칙이 프로그래밍됩니다. 하지만 앞에서 설명한 것처럼 워크로드가 프록시를 우회할 수 있는 방법이 있습니다. VPC 방화벽 규칙은 워크로드를 실행하는 기본 노드에서의 직접 이그레스 액세스를 방지합니다. 워크로드 네임스페이스에서 직접 외부 이그레스가 가능하지 않도록 그리고 istio-egress 네임스페이스에 대한 이그레스가 가능하도록 Kubernetes 네트워크 정책을 사용할 수 있습니다.
또한 네트워크 정책으로 인그레스를 제어할 경우에는 이그레스 정책에 맞게 인그레스 정책을 만들어야 합니다.
Cloud Service Mesh 구성 및 보안
서비스 메시에서 실행되는 워크로드는 해당 IP 주소를 기준으로 식별되지 않습니다. Cloud Service Mesh는 X.509 인증서 및 각 워크로드의 키 형태로 강력하고 확인 가능한 ID를 할당합니다. 워크로드 간 신뢰할 수 있는 통신은 인증 및 암호화된 상호 TLS(mTLS) 연결을 사용하여 설정됩니다.
각 애플리케이션에 대해 잘 정의된 ID와 함께 mTLS 인증을 사용하면 메시 승인 정책을 사용하여 워크로드가 외부 서비스와 통신하는 방법을 세밀하게 제어할 수 있습니다.
트래픽이 사이드카 프록시에서 직접 메시를 떠날 수 있지만, 추가 제어가 필요한 경우에는 이 가이드에 설명된 대로 이그레스 게이트웨이를 통해 트래픽을 라우팅하는 것이 좋습니다.
전용 네임스페이스에서 이그레스 제어를 위한 구성 관리
네트워크 관리자가 이그레스 관련 메시 구성을 위한 전용 istio-egress 네임스페이스를 사용하여 제어를 중앙에서 관리할 수 있도록 허용합니다. 앞에서 설명한 대로 istio-egress 네임스페이스에 이그레스 게이트웨이를 배포합니다. 이 네임스페이스에서 서비스 항목, 게이트웨이, 승인 정책을 만들고 관리할 수 있습니다.
외부 대상의 명시적 구성 필요
서비스 메시 레지스트리에 명시적으로 정의된 외부 호스트 경로만 사용하여 메시 프록시가 프로그래밍되었는지 확인합니다. 각 네임스페이스에 대해 아웃바운드 트래픽 정책 모드를 기본 사이드카 리소스의 REGISTRY_ONLY로 설정합니다. 메시에 대해 아웃바운드 트래픽 정책을 설정하는 것은 그 자체로 보안 경계 제어로 간주되지 않아야 합니다.
서비스 항목으로 외부 대상 정의
메시의 서비스 레지스트리에서 외부 호스트를 명시적으로 등록하도록 서비스 항목을 구성합니다. 기본적으로 서비스 항목은 모든 네임스페이스에 표시됩니다. exportTo 속성을 사용하여 서비스 항목이 표시되는 네임스페이스를 제어합니다. 서비스 항목은 메시 프록시에 구성된 아웃바운드 경로를 결정하지만, 그 자체로 워크로드가 연결할 수 있는 외부 호스트를 결정하기 위한 보안 제어로 간주되지는 않아야 합니다.
게이트웨이 리소스로 이그레스 게이트웨이 동작 구성
게이트웨이 리소스를 사용하여 이그레스 게이트웨이의 부하 분산 동작을 구성합니다. 특정 호스트, 프로토콜, 포트 집합에 대해 부하 분산기를 구성하고 이그레스 게이트웨이 배포와 연결할 수 있습니다. 예를 들어 모든 외부 호스트에 대해 포트 80 및 443으로 이그레스의 게이트웨이를 구성할 수 있습니다.
Cloud Service Mesh 1.6 이상에서는 기본적으로 자동 mTLS가 사용 설정됩니다. 자동 mTLS를 사용하면 클라이언트 사이드카 프록시가 서버에 사이드카가 있는지 자동으로 감지합니다. 클라이언트 사이드카는 사이드카가 있는 워크로드에는 mTLS를 전송하고, 사이드카 없는 워크로드에는 일반 텍스트 트래픽을 전송합니다. 자동 mTLS를 사용해도 사이드카 프록시에서 이그레스 게이트웨이로 전송되는 트래픽에는 mTLS가 자동으로 사용되지 않습니다. 이그레스 게이트웨이 연결의 보안 방법을 나타내기 위해서는 게이트웨이 리소스에서 TLS 모드를 설정해야 합니다. 가능한 모든 경우에 사이드카 프록시에서 이그레스 게이트웨이로의 연결에 mTLS를 사용합니다.
워크로드가 TLS(HTTPS) 연결을 스스로 시작하도록 허용할 수 있습니다. 일반적으로 포트 443으로 워크로드가 TLS 연결을 시작할 때는 해당 포트의 연결에 passthrough 모드를 사용하도록 게이트웨이를 구성해야 합니다. 하지만 passthrough 모드를 사용하면 워크로드 아이덴티티 또는 암호화된 요청의 속성을 기준으로 게이트웨이가 승인 정책을 적용할 수 없습니다. 또한 mTLS와 passthrough를 함께 사용하는 것이 불가능합니다.
게이트웨이를 통해 트래픽을 라우팅하도록 가상 서비스 및 대상 규칙 구성
가상 서비스 및 대상 규칙을 사용하여 이그레스 게이트웨이를 통해 사이드카 프록시에서 외부 대상으로 트래픽을 라우팅하도록 구성합니다. 가상 서비스는 특정 트래픽을 일치시키기 위한 규칙을 정의합니다. 그러면 일치된 트래픽이 대상으로 전송됩니다. 대상 규칙은 하위 집합(예를 들어 이그레스 게이트웨이 또는 외부 호스트)을 정의하고 대상으로 라우팅될 때 트래픽의 처리 방법을 정의할 수 있습니다.
사이드카 프록시에서 게이트웨이로의 트래픽 보안 방법을 명시적으로 지정하려면 여러 대상 호스트에 대해 단일 대상 규칙을 사용합니다. 앞에서 설명한 것처럼 선호되는 방법은 워크로드가 일반 텍스트 요청을 전송하고, 사이드카 프록시가 게이트웨이에 mTLS 연결을 시작하는 것입니다.
각 외부 호스트가 일반 HTTP 요청을 '업그레이드'하여 대상으로 전달할 때 TLS(HTTPS) 연결을 사용하기 위해 이그레스 게이트웨이를 구성할 수 있도록 대상 규칙을 사용합니다. 일반 텍스트 연결을 TLS로 업그레이드하는 것을 종종 TLS 시작이라고도 부릅니다.
사이드카 리소스로 프록시 구성 범위 제어
사이드카 프록시의 동작을 제어하기 위해 각 네임스페이스에 대해 기본 사이드카 리소스를 구성합니다. 사이드카 리소스의 이그레스 속성을 사용하여 프록시의 아웃바운드 리스너에 구성된 대상 호스트를 제어하고 최소화합니다. 일반적인 최소 구성에는 각 네임스페이스에 대해 다음 대상이 포함될 수 있습니다.
- 동일 네임스페이스의 포드
- Google API 및 서비스
- GKE 메타데이터 서버
- 서비스 항목을 사용하여 구성된 특정 외부 호스트
사이드카 프록시의 아웃바운드 리스너 구성은 그 자체로 보안 제어로 간주되지 않아야 합니다.
사이드카 리소스는 프록시 구성의 크기를 제한하기 위해 사용하는 것이 가장 좋습니다. 기본적으로 메시에서 각 사이드카 프록시는 다른 모든 프록시로 트래픽 전송을 허용하도록 구성됩니다. 프록시 구성을 통신이 필요한 호스트로만 제한하면 사이드카 프록시 및 제어 영역의 메모리 소비를 크게 줄일 수 있습니다.
승인 정책을 사용하여 이그레스 게이트웨이에서 트래픽 허용 또는 거부
AuthorizationPolicy는 메시 트래픽에 대해 액세스 제어 정책을 세밀하게 구성할 수 있게 해주는 리소스입니다. 소스, 대상 또는 트래픽 자체의 속성을 기준으로 트래픽을 허용 또는 거부하는 정책을 만들 수 있습니다(예: HTTP 요청의 호스트 또는 헤더).
소스 워크로드 아이덴티티 또는 네임스페이스를 기준으로 연결을 허용하거나 거부하려면 mTLS로 이그레스 게이트웨이 연결을 인증해야 합니다. 사이드카에서 이그레스 게이트웨이로 연결에는 mTLS가 자동으로 사용되지 않으므로 게이트웨이에 대한 연결 대상 규칙에 ISTIO_MUTUAL TLS 모드가 명시적으로 지정되어야 합니다.
승인 정책을 사용하여 게이트웨이에서 요청을 허용하거나 거부하려면 워크로드가 메시 외부의 대상에 일반 HTTP 요청을 전송해야 합니다. 그런 후 사이드카 프록시가 mTLS를 사용하여 요청을 게이트웨이로 전달하고, 게이트웨이는 외부 호스트에 대해 보안 TLS 연결을 시작할 수 있습니다.
다른 여러 팀 및 애플리케이션의 이그레스 요구사항을 지원하기 위해서는 네임스페이스 또는 워크로드별로 '최소 권한'의 승인 정책을 개별적으로 구성합니다. 예를 들어 다음과 같이 소스 워크로드의 네임스페이스 및 요청 속성을 기준으로 규칙을 지정하여 이그레스 게이트웨이에서 서로 다른 정책을 적용할 수 있습니다.
소스 네임스페이스가 team-x이고 대상 호스트가 example.com이면 트래픽을 허용합니다.
소스 네임스페이스가 team-y이고, 대상 호스트가 httpbin.org이고, 경로가 /status/418이면 트래픽을 허용합니다.
다른 모든 요청은 거부됩니다.
대상에 TLS(HTTPS) 연결을 시작하도록 이그레스 게이트웨이 구성
이그레스 게이트웨이가 외부 대상에 대해 TLS(HTTPS) 연결을 시작하도록 대상 규칙을 구성합니다.
이그레스 게이트웨이에서 TLS 대상이 작동하려면 워크로드가 일반 HTTP 요청을 전송해야 합니다. 워크로드가 TLS를 시작하면 이그레스 게이트웨이가 원래 TLS 위에 TLS를 래핑하고 외부 서비스에 대한 요청이 실패합니다.
워크로드가 일반 HTTP 요청을 전송하기 때문에 이를 게이트웨이로 전송할 때 mTLS 연결을 설정하도록 워크로드의 사이드카 프록시를 구성합니다. 그런 후 이그레스 게이트웨이가 mTLS 연결을 종료하고 대상 호스트에 대해 정규 TLS(HTTPS) 연결을 시작합니다.
이 방식의 장점은 다음과 같습니다.
승인 정책을 사용하여 소스 워크로드의 속성 및 요청을 기준으로 트래픽을 허용하거나 거부할 수 있습니다.
워크로드 포드와 이그레스 게이트웨이 사이의 트래픽은 암호화되고 인증되며(mTLS), 이그레스 게이트웨이와 대상 사이의 트래픽은 암호화됩니다(TLS/HTTPS).
메시 내에서 사이드카 프록시는 HTTP 요청의 속성(예: 헤더)을 관측하고 이에 따라 동작할 수 있으며, 관측 가능성 및 제어를 위해 추가적인 옵션을 제공합니다.
애플리케이션 코드는 단순화될 수 있습니다. 개발자가 인증서 또는 HTTPS 클라이언트 라이브러리를 처리할 필요가 없고 서비스 메시를 통해 표준 및 최신 암호화를 사용한 보안 통신을 보장할 수 있습니다.
이그레스 게이트웨이가 외부 서비스에 대해 시작하는 TLS 연결은 여러 포드의 트래픽에 재사용될 수 있습니다. 연결 재사용이 더 효율적이고 연결 제한에 도달할 위험을 줄여줍니다.
DNS, 호스트 이름, 와일드 카드
대상 호스트를 기준으로 트래픽을 라우팅, 거부, 허용할 때는 DNS 이름을 올바른 IP 주소로 분석하기 위해 DNS 시스템의 무결성을 완전히 신뢰할 수 있어야 합니다. Kubernetes Engine 클러스터에서 Kubernetes DNS 서비스는 DNS 쿼리를 처리하고, 다시 외부 쿼리를 GKE 메타데이터 서버 및 내부 DNS에 위임합니다. 사이드카 프록시가 DNS 쿼리를 수행할 수 있도록 외부 호스트로 라우팅할 때 서비스 항목의 변환 속성을 DNS로 설정합니다.
Cloud Service Mesh는 와일드 카드 호스트를 기준으로 트래픽을 라우팅할 수 있습니다. 가장 간단한 사례는 공통 이름을 공유하고 공통 서버 집합에 호스팅되는 호스트의 와일드 카드입니다. 예를 들어 단일 서버 집합이 *.example.com과 일치하는 도메인을 제공할 수 있으면, 와일드 카드 호스트를 사용할 수 있습니다.
표준 이그레스 게이트웨이는 Istio에서 사용되는 Envoy 프록시의 특정 제한 사항들로 인해 보다 일반적이고 임의적인 와일드 카드 호스트(예: *.com)를 기준으로 전달할 수 없습니다. Envoy는 미리 정의된 호스트, 미리 정의된 IP 주소, 요청의 원래 대상 IP 주소로만 트래픽을 라우팅할 수 있습니다.
이그레스 게이트웨이를 사용할 때는 게이트웨이의 IP로 바뀌기 때문에 요청의 원래 대상 IP가 손실되고, 임의 대상 호스트를 미리 구성할 수 없습니다.
관리에 정책 적용
Kubernetes 역할 기반 액세스 제어(RBAC) 사용
승인된 관리자만 이그레스 제어를 구성할 수 있습니다.
이그레스 제어가 승인되지 않은 방식으로 우회되지 않도록 방지하기 위해 Kubernetes 역할 기반 액세스 제어(RBAC)를 구성합니다. 네트워크 관리자만 istio-egress, istio-system,, kube-system 네임스페이스 및 다음 리소스를 관리할 수 있도록 RBAC 역할을 적용합니다.
- Sidecar
- ServiceEntry
- 게이트웨이
- AuthorizationPolicy
- NetworkPolicy
톨러레이션(toleration) 사용 제한
앞에서 설명한 것처럼, taint 및 톨러레이션(toleration)을 사용하여 워크로드 포드가 게이트웨이 노드에 배포되지 않도록 방지할 수 있습니다. 하지만 기본적으로 게이트웨이 노드에 대해 톨러레이션(toleration)을 사용하여 워크로드가 배포되는 것을 방지할 방법이 없으므로, 이그레스 제어 우회를 허용합니다. 배포 파이프라인으로 중앙화된 관리 제어를 적용할 수 있다면, 이를 사용해서 특정 톨러레이션(toleration) 키 사용을 제한할 수 있습니다.
또 다른 방법은 Kubernetes 관리 제어를 사용하는 것입니다. Anthos에는 Kubernetes 허용 컨트롤러로 작동하고 배포가 지정된 정책 제약조건을 충족하는지 확인하는 정책 컨트롤러라는 구성요소가 포함되어 있습니다.
트래픽 로깅 확인
네트워크 경계를 통과하는 모든 트래픽을 로깅해야 할 경우가 종종 있습니다. 일반적인 데이터 보호 규제에 따라 규정 준수를 입증해야 할 필요가 있을 때는 트래픽 로깅이 필요합니다. 트래픽 로그는 Cloud Logging으로 직접 전송되며 Google Cloud 콘솔의 Cloud Service Mesh 대시보드에서 이 로그에 액세스할 수 있습니다. 소스/대상, ID, 네임스페이스, 트래픽 속성, 지연 시간을 비롯하여 다양한 속성을 기준으로 로그를 필터링할 수 있습니다.
kubectl로 쉽게 디버깅하려면 accessLogFile 설정을 사용하여 Cloud Service Mesh를 설치할 때 stdout에 트래픽 로깅을 사용 설정합니다.
감사 로그는 Mesh CA가 워크로드에 대해 인증서를 만들 때 마다 Cloud Logging에 전송됩니다.
멀티 클러스터 메시에서 이그레스 게이트웨이에 대해 개별 클러스터 사용 고려
Cloud Service Mesh는 2개 이상의 GKE 클러스터에 배포될 수 있습니다. 멀티 클러스터 메시는 몇 가지 제한 사항과 함께 이그레스 트래픽 제어를 위해 새로운 가능성을 제시합니다.
이그레스 게이트웨이를 전용 노드 풀에 배포하는 대신 일반적인 워크로드를 실행하지 않는 개별 클러스터에 게이트웨이를 배포할 수 있습니다. 개별 클러스터를 사용하면 워크로드와 게이트웨이 사이에 비슷한 격리 수준을 제공하며, taint 및 톨러레이션(toleration)을 사용할 필요가 없습니다. 이그레스 게이트웨이는 개별 클러스터를 인그레스 게이트웨이 또는 다른 중앙 서비스와 공유할 수 있습니다.
멀티 클러스터 배포에서 Kubernetes 네트워크 정책을 사용할 수 있지만 레이어 4(전송)에서 작동하므로, 대상 네임스페이스 또는 포드를 기준으로 클러스터 간 연결을 제한할 수 없습니다.
다음 단계
- 보조 튜토리얼 확인
- GKE 강화 가이드 참조하기
- Anthos Config Management를 사용하여 모든 인프라에서 구성 및 정책을 관리하는 방법을 알아봅니다.
- 그 밖의 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항을 알아보려면 클라우드 아키텍처 센터를 확인하세요.