Cloud Service Mesh 보안 권장사항

이 문서에서는 Google Kubernetes Engine(GKE)에서 실행되는 보안 Cloud Service Mesh 구성을 설정하고 관리하기 위한 권장사항을 설명합니다. 문서의 안내는 Cloud Service Mesh를 구성 및 설치하는 데 사용되는 설정 범위를 넘어, 다른 Google Cloud 제품 및 기능과 함께 Cloud Service Mesh를 사용하여 메시의 애플리케이션에 발생할 수 있는 보안 위협을 방지하는 방법을 설명합니다.

이 문서는 Cloud Service Mesh에서 정책을 관리하는 관리자와 서비스를 실행하는 사용자를 대상으로 합니다. 여기에 설명된 보안 방법은 규정 준수 요구사항을 충족하기 위해 서비스 메시 보안을 강화해야 하는 조직에게도 유용합니다.

이 문서는 다음과 같이 정리되어 있습니다.

소개

Cloud Service Mesh는 통합된 방식으로 서비스를 관찰, 관리, 보호하는 데 도움이 되는 기능과 도구를 제공합니다. 네트워크 IP 중심의 접근 방식보다는 애플리케이션 중심의 접근 방식에 따라 신뢰할 수 있는 애플리케이션 ID가 사용됩니다. 기존 애플리케이션 코드를 수정할 필요 없이 서비스 메시지를 투명하게 배포할 수 있습니다. Cloud Service Mesh는 네트워크 동작에 대해 선언적 제어를 제공하므로, 보안 및 네트워킹을 담당하는 관리자의 책임으로부터 애플리케이션 기능의 제공 및 출시하는 팀의 작업을 분리합니다.

Cloud Service Mesh는 정밀한 구성 및 토폴로지를 가능하게 해주는 오픈소스 Istio 서비스 메시를 기반으로 합니다. 조직의 구조에 따라 하나 이상의 팀 또는 역할이 메시 설치 및 구성을 담당할 수 있습니다. 애플리케이션 보호를 위해 기본 Cloud Service Mesh 설정이 선택되지만 경우에 따라 커스텀 구성을 사용하거나 특정 앱, 포트, IP 주소가 메시에 참여하지 못하도록 제외하는 예외를 부여해야 할 수 있습니다. 메시 구성과 보안 예외를 제어할 수 있도록 하는 것이 중요합니다.

공격 벡터 및 보안 위험

공격 벡터

Cloud Service Mesh 보안은 보안 위협이 조직의 보안 경계 내부 및 외부에서 시작된다고 가정하는 제로 트러스트 보안 모델을 따릅니다. 서비스 메시에서 애플리케이션에 위협이 될 수 있는 보안 공격 유형에 대한 예시는 다음과 같습니다.

  • 데이터 무단 반출 공격. 예를 들어 서비스 간 트래픽에서 민감한 정보 또는 사용자 인증 정보를 도청하는 공격입니다.
  • 중간자 공격. 예를 들어 악의적인 서비스가 서비스 간 통신을 확보하거나 수정하기 위해 적법한 서비스로 가장할 수 있습니다.
  • 권한 에스컬레이션 공격. 예를 들어 승격된 권한에 대한 불법 액세스를 통해 네트워크에서 작업을 수행하려는 공격입니다.
  • 서비스 거부(DoS) 공격.
  • 서비스를 손상시키고 조작하여 다른 서비스에서 공격을 시도하는 봇넷 공격입니다.

공격 대상을 기준으로 공격을 분류할 수도 있습니다.

  • 메시 내부 네트워크 공격. 메시 내부 서비스 간 또는 서비스-제어 영역 간 통신을 손상시키거나, 도청하거나, 스푸핑하려는 공격입니다.
  • 제어 영역 공격. 제어 영역이 오작동하도록 하거나(DoS 공격) 제어 영역에서 민감한 정보를 유출시키려는 공격입니다.
  • 메시 에지 공격. 메시 인그레스 또는 이그레스에서 통신을 손상시키거나, 도청하거나, 스푸핑하려는 공격입니다.
  • 메시 작업 공격. 메시 작업을 대상으로 하는 공격입니다. 공격자는 메시에서 악의적인 작업(예: 보안 정책 및 워크로드 이미지 수정)을 수행하기 위해 승격된 권한을 얻으려고 시도할 수 있습니다.

보안 위험

메시에는 보안 공격 외에도 다른 보안 위험이 있습니다. 다음 목록에서는 몇 가지 발생 가능한 보안 위험에 대해 설명합니다.

  • 불완전한 보안 보호. 서비스 메시에 보안을 위한 인증 및 승인 정책이 구성되지 않았을 수 있습니다. 예를 들어 메시의 서비스에 인증 또는 승인 정책이 정의되어 있지 않습니다.
  • 보안 정책 예외. 특정 사용 사례를 수용하기 위해 사용자는 특정 트래픽(내부 또는 외부)에 대한 보안 정책 예외를 만들어 Cloud Service Mesh 보안 정책에서 제외될 수 있습니다. 이러한 경우를 안전하게 처리하려면 정책에 대한 예외를 안전하게 처리 섹션을 참조하세요.
  • 이미지 업그레이드 태만. 메시에 사용된 이미지에서 취약점이 발견될 수 있습니다. 최신 취약점 수정을 통해 메시 구성요소 및 워크로드 이미지를 최신 상태로 유지해야 합니다.
  • 유지보수 부족(전문 기술 또는 리소스 없음). 최신 보안 보호 메커니즘을 활용하기 위해서는 메시 소프트웨어 및 정책 구성을 정기적으로 유지보수해야 합니다.
  • 가시성 부족. 잘못되거나 안전하지 않은 메시 정책 구성 및 비정상적인 메시 트래픽/작업이 메시 관리자의 눈에 띄지 않을 수 있습니다.
  • 구성 드리프트. 메시의 정책 구성이 정보 소스로부터 벗어날 수 있습니다.

서비스 메시 보호 방법

이 섹션에서는 서비스 메시 보호를 위한 운영 지침을 제공합니다.

보안 아키텍처

서비스 메시의 보안은 메시 시스템 및 애플리케이션의 여러 레이어에 있는 구성요소의 보안에 따라 달라집니다. 제안된 Cloud Service Mesh 보안 상황의 대략적인 의도는 서로 다른 레이어에서 여러 보안 메커니즘을 통합하여 서비스 메시를 보호함으로써 제로 트러스트 보안 모델에 따라 전체 시스템 보안을 공동으로 달성하기 위한 것입니다. 다음 다이어그램은 제안된 Cloud Service Mesh 보안 상황을 보여줍니다.

Cloud Service Mesh 보안 상황

Cloud Service Mesh는 다음과 같은 여러 레이어에서 보안을 제공합니다.

  • 메시 에지 보안
    • Cloud Service Mesh 인그레스 보안은 외부 트래픽에 대한 액세스 제어를 제공하고 메시에서 서비스로 노출되는 API에 대한 외부 액세스를 보호합니다.
    • Cloud Service Mesh 이그레스 보안은 내부 워크로드의 아웃바운드 트래픽을 규제합니다.
    • Cloud Service Mesh 사용자 인증은 Google 인프라와 통합되어 웹 브라우저에서 웹 애플리케이션을 실행하는 서비스에 대한 외부 호출을 인증합니다.
    • Cloud Service Mesh 게이트웨이 인증서 관리는 Certificate Authority Service를 사용하여 Cloud Service Mesh 인그레스 및 이그레스 게이트웨이에서 사용하는 비공개 키와 X.509 인증서를 보호하고 순환합니다.
    • Cloud Armor는 외부 DDoS 및 레이어 7 공격을 방어합니다. 이는 메시를 네트워크 공격으로부터 보호하기 위한 웹 애플리케이션 방화벽(WAF) 역할을 합니다. 예를 들어 삽입 및 원격 코드 실행 공격이 있습니다.
    • VPC 및 VPC 서비스 제어는 비공개 네트워크 액세스 제어를 통해 메시 에지를 보호합니다.
  • 클러스터 보안
    • Cloud Service Mesh 상호 TLS(mTLS)는 워크로드 간 트래픽 암호화 및 인증을 적용합니다.
    • Cloud Service Mesh 인증 기관 및 Certificate Authority Service와 같은 관리형 CA는 워크로드에서 사용하는 인증서를 안전하게 프로비저닝하고 관리합니다.
    • Cloud Service Mesh 승인은 ID 및 기타 속성을 기반으로 메시 서비스에 대해 액세스 제어를 적용합니다.
    • GKE Enterprise 보안 대시보드에서는 워크로드에 대한 보안 정책 및 Kubernetes 네트워크 정책 구성을 모니터링할 수 있습니다.
    • Kubernetes 네트워크 정책은 IP 주소, 포드 라벨, 네임스페이스 등을 기준으로 포드 액세스 제어를 적용합니다.
    • 제어 영역 보안은 제어 영역에 대한 공격을 방어합니다. 이 보호 기능은 공격자가 서비스 및 메시 구성 데이터를 수정, 악용, 유출하지 못하도록 방지합니다.
  • 워크로드 보안
    • 메시에서 실행되는 Cloud Service Mesh 바이너리에 공개적으로 알려진 취약점이 적용되지 않도록 Cloud Service Mesh 보안 출시 버전을 최신 상태로 유지합니다.
    • GKE용 워크로드 아이덴티티 제휴를 사용하면 워크로드가 Google 서비스를 안전하게 호출하기 위한 사용자 인증 정보를 가져올 수 있습니다.
    • Cloud Key Management Service(Cloud KMS)는 하드웨어 보안 모듈(HSM)을 통해 민감한 정보 또는 사용자 인증 정보를 보호합니다. 예를 들어 워크로드는 Cloud KMS를 사용하여 사용자 인증 정보 또는 기타 민감한 정보를 저장할 수 있습니다. 메시 워크로드에 인증서를 발급하는 데 사용되는 CA 서비스는 Cloud KMS로 관리되는 고객별 및 HSM 기반 서명 키를 지원합니다.
    • Kubernetes CNI(컨테이너 네트워크 인터페이스)는 권한이 있는 Cloud Service Mesh 초기 컨테이너의 필요성을 제거하여 권한 에스컬레이션 공격을 방지합니다.
  • 운영자 보안
    • Kubernetes 역할 기반 액세스 제어(RBAC)는 Kubernetes 리소스에 대한 액세스를 제한하고 악의적인 운영자 또는 운영자 명의 도용으로 인한 공격을 완화하도록 운영자 권한을 제한합니다.
    • GKE Enterprise 정책 컨트롤러는 메시에서 정책 구성을 검증하고 감사하여 잘못된 구성을 방지합니다.
    • Google Cloud Binary Authorization은 메시의 워크로드 이미지가 관리자 승인을 받은 이미지인지 확인합니다.
    • Google Cloud 감사 로깅은 메시 작업을 감사합니다.

아래 다이어그램은 Cloud Service Mesh의 통합 보안 솔루션의 통신 및 구성 흐름을 보여줍니다.

보안 다이어그램 트래픽 흐름

클러스터 보안

엄격한 상호 TLS 사용 설정

중간자(MitM) 공격은 통신을 도청하거나 조작하기 위해 두 통신 당사자 사이에 악의적인 항목을 삽입하려고 시도합니다. Cloud Service Mesh는 모든 통신 당사자에 mTLS 인증 및 암호화를 적용하여 MitM 및 데이터 무단 반출을 방지합니다. 허용 모드에서는 양측에서 지원할 경우 mTLS가 사용되지만 mTLS가 없는 연결이 허용됩니다. 반면에 엄격한 mTLS에서는 mTLS를 통해 트래픽을 암호화 및 인증해야 하고 일반 텍스트 트래픽이 허용되지 않습니다.

자세한 내용은 Cloud Service Mesh 예시: mTLS | 메시 전체 mTLS 적용을 참조하세요.

액세스 제어 사용 설정

인증 및 승인 정책과 같은 Cloud Service Mesh 보안 정책은 Cloud Service Mesh 보안 정책에서 서비스 또는 포드를 제외해야 하는 강력한 근거가 있지 않은 한 메시 내부 및 외부의 모든 트래픽에 적용되어야 합니다. 경우에 따라 일부 포트 및 IP 범위에 대해서는 Cloud Service Mesh 보안 정책을 우회해야 하는 적법한 이유가 있을 수 있습니다. 예를 들어 Cloud Service Mesh에서 관리되지 않는 서비스와 고유 연결을 설정해야 할 수 있습니다. 이러한 사용 사례에서 Cloud Service Mesh를 보호하려면 Cloud Service Mesh 정책 예외를 안전하게 처리를 참조하세요.

서비스 액세스 제어는 서비스에 대한 무단 액세스를 방지하는 데 매우 중요합니다. mTLS 시행은 요청을 암호화하고 인증하지만 서비스에 대한 액세스 제어를 적용하려면 메시에 Cloud Service Mesh 승인 정책이 있어야 합니다. 예를 들어 인증된 클라이언트에서 오는 승인되지 않은 요청을 거부합니다.

Cloud Service Mesh 승인 정책은 승인되지 않은 액세스로부터 서비스를 보호하기 위해 액세스 제어를 구성하는 유연한 방법을 제공합니다. Cloud Service Mesh 승인 정책은 인증된 결과로부터 파생되는 인증된 ID에 따라 적용되어야 합니다. Cloud Service Mesh 승인 정책에 따라 mTLS 또는 JSON 웹 토큰(JWT) 기반 인증을 함께 사용해야 합니다.

Cloud Service Mesh 인증 정책 적용

JSON 웹 토큰(JWT)

mTLS 인증 외에도 메시 관리자는 JWT 기반의 서비스 인증 및 요청 승인을 요구할 수 있습니다. Cloud Service Mesh는 JWT 제공업체로 작동하지 않지만 구성된 JSON 웹 키 집합(JWKS) 엔드포인트를 기준으로 JWT를 인증합니다. JWT 인증은 외부 트래픽의 경우 인그레스 게이트웨이에 적용되고 메시 내 트래픽의 경우 내부 서비스에 적용될 수 있습니다. JWT가 최종 호출자를 나타내기 위한 사용자 인증 정보로 사용되고 최종 호출자 대신 호출된다는 증명이 요청된 서비스에 요구되는 경우 mTLS 인증과 함께 JWT 인증을 조합할 수 있습니다. JWT 인증을 시행하면 유효한 사용자 인증 정보 없이 실제 최종 사용자를 대신하여 서비스에 액세스하는 공격을 방어합니다.

Cloud Service Mesh 사용자 인증

Cloud Service Mesh 사용자 인증은 워크로드에 대한 브라우저 기반 최종 사용자 인증 및 액세스 제어를 위한 통합 솔루션입니다. 서비스 메시를 기존 ID 공급업체(IdP)와 통합하여 표준 웹 기반 OpenID Connect(OIDC) 로그인 및 동의 흐름을 구현하고 Cloud Service Mesh 승인 정책을 사용하여 액세스를 제어합니다.

승인 정책 적용

Cloud Service Mesh 승인 정책은 다음을 제어합니다.

  • 서비스에 액세스할 수 있는 사용자 또는 대상
  • 액세스할 수 있는 리소스
  • 허용된 리소스에서 수행할 수 있는 작업

승인 정책은 서비스가 실행되는 실제 ID, 트래픽의 애플리케이션 레이어(레이어 7) 속성(예: 요청 헤더), IP 범위 및 포트와 같은 네트워크 레이어(레이어 3 및 레이어 4) 속성을 기반으로 액세스 제어를 구성하는 다양한 방법입니다.

Cloud Service Mesh 승인 정책은 서비스 또는 데이터에 대한 무단 액세스를 방지하기 위해 인증 결과에서 파생된 인증된 ID를 기반으로 시행해야 합니다.

서비스에 대한 액세스를 허용하도록 승인 정책이 명시적으로 정의되어 있지 않으면 기본적으로 서비스에 대한 액세스가 거부되어야 합니다. 액세스 요청을 거부하는 승인 정책 예시는 승인 정책 권장사항을 참조하세요.

승인 정책은 가능한 한 신뢰를 제한해야 합니다. 예를 들어 서비스 A만 서비스 B의 /admin 경로에 액세스할 수 있도록 서비스에 의해 노출된 개별 URL 경로를 기준으로 서비스 액세스를 정의할 수 있습니다.

승인 정책은 Kubernetes 네트워크 정책과 함께 사용할 수 있습니다. 이 네트워크 정책은 네트워크 레이어(레이어 3 및 레이어 4)에서만 작동하며 Kubernetes 포드 및 Kubernetes 네임스페이스에서 IP 주소 및 포트의 네트워크 액세스를 제어합니다.

메시 서비스 액세스를 위한 토큰 교환 적용

토큰을 훔치고 훔친 토큰을 다시 사용하여 메시 서비스에 액세스하는 토큰 재생 공격을 방어하려면 메시 외부 요청의 토큰을 메시 에지에서 단기 메시 내부 토큰으로 교환해야 합니다.

메시 서비스에 액세스하기 위한 메시 외부의 요청이 메시 서비스에서 인증되고 승인되려면 JWT 또는 쿠키와 같은 토큰을 포함해야 합니다. 메시 외부의 토큰은 장기 지속될 수 있습니다. 토큰 재생 공격을 방어하려면 메시 외부 토큰을 메시 인그레스에서 제한된 범위의 단기 메시 내부 토큰으로 교환해야 합니다. 메시 서비스는 메시 내부 토큰을 인증하고 메시 내부 토큰을 기준으로 액세스 요청을 승인합니다.

Cloud Service Mesh는 Cloud Service Mesh에서 승인을 위해 사용되는 RequestContextToken(외부 토큰에서 교환된 단기 메시 내부 토큰)을 생성하는 IAP(Identity-Aware Proxy)와 통합을 지원합니다. 토큰 교환을 사용하면 공격자가 메시에서 훔친 토큰을 사용하여 서비스에 액세스할 수 없습니다. 교환된 토큰의 제한된 범위 및 수명은 토큰 재생 공격의 가능성을 크게 줄입니다.

Cloud Service Mesh 정책 예외를 안전하게 처리

서비스 메시에 대해 특수한 사용 사례가 있을 수 있습니다. 예를 들어 특정 네트워크 포트를 일반 텍스트 트래픽에 노출시켜야 할 수 있습니다. 특정 사용 시나리오를 충족하기 위해서는 경우에 따라 특정 내부 또는 외부 트래픽이 Cloud Service Mesh 보안 정책에서 제외되도록 허용하는 예외를 만들어야 할 수 있고, 이로 인해 보안 우려가 발생할 수 있습니다.

일부 포트 및 IP 범위에 대해 Cloud Service Mesh 보안 정책을 우회해야 하는 적법한 이유가 있을 수 있습니다. annotations(예: excludeInboundPorts, excludeOutboundPorts, excludeOutboundIPRanges)을 포드에 추가하여 Envoy 사이드카에서 트래픽 처리를 제외할 수 있습니다. 트래픽을 제외하는 주석 외에도 사이드카 삽입이 사용 중지된 애플리케이션을 배포하여 메시를 모두 우회할 수 있습니다. 예를 들어 sidecar.istio.io/inject="false" 라벨을 애플리케이션 포드에 추가할 수 있습니다.

Cloud Service Mesh 보안 정책을 우회하면 전체 시스템 보안에 부정적인 영향을 줍니다. 예를 들어 주석을 통해 네트워크 포트에 대해 Cloud Service Mesh mTLS 및 승인 정책을 우회할 경우 해당 포트의 트래픽에 대한 액세스를 제어할 수 없으며 도청 또는 트래픽 수정이 발생할 수 있습니다. 또한 Cloud Service Mesh 정책을 우회하면 네트워크 정책과 같은 비보안 정책에도 영향을 줍니다.

의도적인지 여부에 관계없이 포트 또는 IP에 대해 Cloud Service Mesh 보안 정책을 우회할 경우 메시를 보호하고 보안 예외, 잠재적인 보안 허점, 전반적인 보안 적용 상태를 모니터링할 수 있도록 다른 보안 수단을 마련해야 합니다. 이러한 시나리오에서 메시를 보호하기 위해 다음을 수행할 수 있습니다.

  • MitM 공격 방지를 위해 사이드카를 우회하는 트래픽이 고유하게 암호화되었고 인증되었는지 확인합니다.
  • Kubernetes 네트워크 정책을 적용하여 정책 예외로 포트 연결을 제한(예: 동일 네임스페이스에 있는 다른 서비스의 트래픽만 허용하도록 정책 예외로 포트 제한)하거나 Cloud Service Mesh 보안 정책이 적용된 포트만 트래픽이 통과하도록 허용합니다.
  • GKE Enterprise 정책 컨트롤러를 적용하여 Cloud Service Mesh 정책을 자동으로 검증합니다. 예를 들어 Cloud Service Mesh 사이드카가 항상 워크로드에 삽입되도록 합니다.

Kubernetes 네트워크 정책 적용

Cloud Service Mesh는 기본 플랫폼(예: Kubernetes)을 기반으로 빌드됩니다. 따라서 Cloud Service Mesh 보안은 기본 플랫폼의 보안에 따라 결정됩니다. 예를 들어 사용자는 Kubernetes 리소스를 업데이트할 수 있는 사용자를 제어하지 않고도 서비스의 Kubernetes 배포를 변경하여 서비스의 사이드카를 우회할 수 있습니다.

서비스 메시에 대해 강력한 보안 상태를 형성하려면 기본 플랫폼의 보안 메커니즘을 Cloud Service Mesh 보안 정책과 함께 작동하도록 적용해야 합니다.

Kubernetes 네트워크 정책은 Kubernetes 포드 및 네임스페이스의 IP 주소 및 포트에 대한 네트워크 레이어(L3 및 L4)에서 작동합니다. 메시의 보안을 강화하기 위해 Kubernetes 네트워크 정책을 Cloud Service Mesh 정책과 함께 적용할 수 있습니다.

예를 들어 메시 관리자는 Cloud Service Mesh 보안 정책이 적용된 포트만 트래픽에 사용되도록 Kubernetes 네트워크 정책을 구성할 수 있습니다. 모든 트래픽에 Cloud Service Mesh mTLS를 적용해야 할 경우에는 관리자가 Cloud Service Mesh mTLS 정책으로 구성된 포트에서만 트래픽을 허용하도록 Kubernetes 네트워크 정책을 구성해야 해야 할 수 있습니다. 메시 관리자는 정책 예외로 포트 연결을 제한하도록 Kubernetes 네트워크 정책을 구성할 수도 있습니다. 예를 들어 이러한 포트의 연결을 네임스페이스 내부로 제한합니다.

제어 영역 액세스 보호

Cloud Service Mesh 컨트롤 플레인은 연결되는 모든 클라이언트를 인증합니다. 따라서 유효한 사용자 인증 정보(허용되는 CA에서 발급된 Kubernetes JWT 또는 X.509 인증서)를 사용하는 호출자만 Cloud Service Mesh 컨트롤 플레인에 액세스할 수 있습니다. TLS는 워크로드와 Cloud Service Mesh 컨트롤 플레인 간의 연결을 암호화합니다.

인증 메커니즘 외에도 클러스터 내 Cloud Service Mesh에 Kubernetes 네트워크 정책을 배포하여 데이터 영역이 컨트롤 플레인에 액세스할 수 있도록 하면서 메시 외부의 관리되지 않는 네임스페이스 및 클라이언트로부터 Cloud Service Mesh 시스템 네임스페이스(기본적으로 istio-system)를 격리시킬 수 있습니다. VPC 방화벽 규칙은 클러스터 외부 트래픽이 Istiod에 연결하지 못하도록 할 수 있습니다. 이러한 네트워크 격리 방법을 사용하면 메시 외부의 공격자가 유효한 사용자 인증 정보를 갖고 있더라도 제어 영역에 액세스할 수 없습니다. 관리형 제어 영역의 경우 Google에서 제어 영역에 대한 보안을 처리하므로 제어 영역에 대한 이러한 네트워크 격리 정책이 필요하지 않습니다.

네임스페이스 경계 적용

한 네임스페이스 사용자가 승인되지 않은 네임스페이스의 리소스를 액세스/업데이트하지 못하도록 하려면 다음 안내를 따르세요.

Kubernetes RBAC 정책 적용

메시 관리자는 Kubernetes RBAC 정책을 적용하여 Kubernetes 리소스에 액세스하고 업데이트할 수 있는 사용자를 제어해야 합니다. Kubernetes 액세스 제어는 메시의 보안 위험을 완화할 수 있습니다. 예를 들어 승인되지 않은 사용자는 Kubernetes 배포를 변경하고 Cloud Service Mesh 정책 시행을 우회할 수 없어야 합니다. 사용자가 액세스해야 하는 네임스페이스보다 많은 네임스페이스에 액세스할 수 없도록 사용자의 역할은 네임스페이스에 제한되어야 합니다. RBAC 구성에 대한 자세한 가이드 및 예시는 역할 기반 액세스 제어 구성을 참조하세요. GKE용 워크로드 아이덴티티 제휴를 사용 설정한 후 Kubernetes 서비스 계정이 IAM 서비스 계정으로 작동하도록 허용할 수도 있습니다.

메시 에지 보안

또한 대부분의 공격이 클러스터 외부에서 시작되므로 메시 에지에서의 보안 확인도 중요합니다.

클러스터 인그레스 액세스 제어

Cloud Service Mesh는 인그레스 게이트웨이를 통해 들어오는 외부 트래픽을 수신합니다. 인그레스 게이트웨이로 노출되는 서비스에는 외부 소스의 공격이 발생할 수 있습니다. 보안 관리자는 항상 인그레스 게이트웨이를 통해 외부 트래픽에 노출되는 서비스가 공격을 방어하기에 충분히 안전한지 확인해야 합니다.

인그레스는 외부 호출자에 노출되는 서비스에 대한 인증 및 승인을 적용해야 합니다.

  • 클러스터 인그레스 보안 정책을 적용합니다. 클러스터가 외부 트래픽을 수신해야 할 경우에는 메시 관리자가 Cloud Service Mesh 게이트웨이 TLS, 인증, 승인 정책을 포함하여 외부 요청을 인증하도록 인그레스 보안 정책을 적용하고 인그레스 게이트웨이에서 노출되는 서비스에 액세스하도록 외부 요청이 승인되었는지 확인해야 합니다. 인그레스 보안 정책을 적용하면 유효한 사용자 인증 정보 또는 권한 없이 서비스에 액세스하려고 시도하는 메시 외부의 공격이 방어됩니다.
  • Cloud Armor를 웹 기반 공격(예: 삽입 공격 및 원격 실행 공격)을 방어하기 위한 웹 애플리케이션 방화벽(WAF)으로 사용합니다. 자세한 내용은 에지에서 메시로: GKE 인그레스를 통해 서비스 메시 애플리케이션 노출을 참조하세요.

클러스터 이그레스 트래픽 규제

이그레스 보안 정책은 데이터 무단 반출 공격을 방어하고, 이그레스 트래픽 필터링을 적용하고, 이그레스 트래픽에 대한 TLS 시작을 적용할 수 있기 때문에 클러스터 이그레스 보안은 메시 보안의 핵심입니다. 보안 관리자는 클러스터 이그레스 트래픽을 규제하고 감사해야 합니다.

이그레스 트래픽 제한을 위한 VPC 방화벽 사용 외에도 메시 관리자는 클러스터에 대해 이그레스 보안 방화벽을 적용하고 이그레스 게이트웨이를 통과하도록 아웃바운드 트래픽을 구성해야 합니다.

이그레스 정책은 다음과 같은 공격을 완화할 수 있습니다.

  • 데이터 무단 반출 공격.
  • CVE가 패치되지 않으면 공격자가 서비스 포드를 악용할 수 있습니다. 손상된 포드는 공격자가 제어하는 봇넷이 되어 스팸을 보내거나 DoS 공격을 실행할 수 있습니다.

이그레스 게이트웨이에 적용된 승인 정책은 승인된 서비스만 메시 외부의 특정 호스트로 트래픽을 보내도록 허용할 수 있습니다. 한편, 메시에서 나가는 트래픽의 경우에는 개별 사이드카에서 TLS 시작을 처리하는 대신 이그레스 게이트웨이에서 TLS를 시작할 수 있습니다. 이렇게 하면 mTLS의 클라이언트 인증서를 애플리케이션이 실행되는 네임스페이스에서 격리할 수 있으므로 보다 안전하고 일정한 방식으로 TLS 트래픽을 시작할 수 있습니다.

비공개 클러스터 또는 VPC 서비스 제어를 사용하여 외부 액세스 차단

인그레스 및 이그레스 보안 정책을 적용하는 것 외에도 가능한 한 비공개 클러스터 또는 VPC 서비스 제어를 사용하여 외부 액세스를 차단합니다. 보안 정책은 메시 보안 관리자가 제어하지만 비공개 클러스터 구성 또는 VPC 서비스 제어는 조직 보안 관리자가 적용할 수 있습니다.

VPC 서비스 제어를 적용하여 다음 목적에 따라 서비스의 보안 경계를 정의할 수 있습니다.

  • 서비스가 외부 리소스에 액세스하지 못하도록 제한합니다.
  • 외부 사용자가 보안 경계의 서비스에 액세스하지 못하도록 제한합니다.

VPC 서비스 제어는 데이터 무단 반출 공격을 방어하고 외부 공격자가 메시 내의 서비스에 액세스하지 못하도록 방지하는 데 도움이 됩니다.

외부 DDoS 공격 방어

외부 DDoS 공격이 인그레스 게이트웨이 및 백엔드 서비스에 과부하를 발생시키면 적법한 요청이 처리되지 않습니다. Cloud Armor를 사용하여 DDoS 공격을 방어할 수 있습니다. Cloud Armor는 네트워크 레이어(L3 및 L4) DDoS 공격뿐만 아니라 애플리케이션 레이어(L7) DDoS 공격을 방어합니다.

메시 관리 및 자동화 보안

관리 작업과 메시를 중심으로 빌드하는 모든 자동화(예: CI/CD)의 보안을 고려하는 것이 중요합니다. 다음 연습은 서비스가 추가 공격에 노출되는 위험 없이 메시가 안전하게 작동할 수 있도록 보장하는 것을 목표로 합니다.

메시 작업에 사용되는 역할 분류

역할 기반 액세스 제어와 동일한 원칙에 따라 해당 역할별로 메시 사용자를 분류해야 합니다. 각 역할에는 해당 역할에 필요한 최소 권한 집합만 부여해야 합니다.

예를 들어 서비스 배포를 수행하는 사용자 집합에는 인증 및 승인 정책을 업데이트할 수 있는 권한이 없어야 합니다.

운영자는 여러 카테고리로 분류됩니다. 예를 들어 클러스터 운영자와 네임스페이스 운영자가 있습니다. 승인되지 않은 리소스에 불법적으로 액세스하지 못하도록 운영자의 권한 에스컬레이션을 방지하는 것이 중요합니다.

메시 관리자는 Kubernetes RBAC 정책을 사용하여 리소스 액세스를 승인된 사용자로만 제한할 수 있습니다.

정책 구성 자동 검증

운영자가 실수로 Cloud Service Mesh 정책을 잘못 구성하여 심각한 보안 이슈가 발생할 수 있습니다. 메시 관리자는 잘못된 구성을 방지하고 Cloud Service Mesh 정책을 자동으로 검증하기 위해 정책 컨트롤러를 사용하여 정책 구성에 제약조건을 적용할 수 있습니다.

Cloud Service Mesh 보안 정책 업데이트 및 Cloud Service Mesh 정책 검증 자동화를 위해 개별 사용자에게 너무 많은 신뢰 권한을 부여하지 않도록 하려면 메시 관리자가 정책 컨트롤러를 사용하여 Cloud Service Mesh 정책에 제약조건을 구현해야 합니다.

정책 컨트롤러는 오픈소스 Gatekeeper 프로젝트를 기반으로 하며 잘못된 리소스가 적용되지 않도록 거부하는 Kubernetes 허용 컨트롤러로 실행되거나 관리자에게 위반 사항에 대한 알림을 표시할 수 있도록 감사 모드로 실행될 수 있습니다. 정책 컨트롤러는 배포의 주석이 Cloud Service Mesh 정책을 우회하지 않는지 확인하고, Cloud Service Mesh 정책이 예상한 대로 작동하는지 검증하고, 배포에 루트 기능(예: NET_ADMIN 및 NET_RAW)이 포함되지 않는지 확인하는 등 메시에서 리소스 배포를 자동으로 검증할 수 있습니다.

또한 정책 컨트롤러는 제약조건에 대해 기존 Cloud Service Mesh 리소스를 감사하여 정책 구성 오류를 감지할 수도 있습니다.

다음은 GKE Enterprise 정책 컨트롤러의 몇 가지 보안 정책 적용 예시입니다.

정책 컨트롤러에 제공된 제약조건 템플릿 라이브러리에는 즉시 사용 가능한 Cloud Service Mesh 보안 제약조건 번들과 함께 사용하여 인증, 승인, 트래픽 정책 등의 특정 Cloud Service Mesh 보안 권장사항을 적용할 수 있는 제약조건 템플릿 집합이 포함되어 있습니다. 다음은 번들에 포함된 몇 가지 제약조건 예시입니다.

  • 메시 수준의 엄격한 mTLS PeerAuthentication을 적용합니다.
  • 모든 PeerAuthentication으로 엄격한 mTLS를 덮어쓸 수 없도록 적용합니다.
  • 메시 수준 기본 거부 AuthorizationPolicy를 적용합니다.
  • AuthorizationPolicy 안전 패턴을 적용합니다.
  • Cloud Service Mesh 사이드카가 항상 워크로드에 삽입되도록 적용합니다.

메시 관리자는 예외 및 긴급 상황 처리를 위해 다음을 수행할 수 있습니다.

구성 동기화를 사용하는 GitOps 방식으로 구성 드리프트 방지

구성 드리프트는 메시의 정책 구성이 정보 소스에서 벗어나는 경우에 발생합니다. 구성 동기화를 사용하여 구성 드리프트를 방지할 수 있습니다.

감사 로깅 및 모니터링 적용

메시 관리자는 다음을 모니터링해야 합니다.

이러한 관측 가능성 리소스는 보안 구성이 예상대로 작동하는지 확인하고 보안 정책 적용에 대한 예외를 모니터링하는 데 사용할 수 있습니다. 예를 들어 사이드카를 거치지 않은 액세스 권한과 유효한 사용자 인증 정보가 없지만 서비스에 도달한 액세스 등이 있습니다.

Prometheus와 같은 오픈소스 관측 가능성 소프트웨어를 Cloud Service Mesh와 함께 사용할 수 있지만 Google Cloud 운영 제품군(이전의 Stackdriver)을 사용하는 것이 좋습니다. Google Cloud에 기본 제공되는 관측 가능성 솔루션은 완전 관리형이며 쉽게 사용 가능한 로깅, 측정항목 수집, 모니터링, 알림을 제공합니다.

클러스터 내 인증서의 인증 기관 보호

기본적으로 Cloud Service Mesh에는 Cloud Service Mesh 인증 기관이라고 부르는 Google 관리형 인증 기관(CA)이 사용됩니다.

Istiod의 일부로 호스팅되는 비관리형 Istio 인증 기관(CA)을 사용하는 경우에는 CA 서명 키는 Kubernetes 보안 비밀에 저장되고 istio-system 네임스페이스에서 보안 비밀 리소스에 액세스할 수 있는 운영자가 액세스할 수 있습니다. 이러한 상황은 운영자가 Istiod CA와 별개로 CA 키를 사용하고 워크로드 인증서를 개별적으로 서명할 수 있으므로 위험한 상황입니다. 또한 자체 관리형 CA 서명 키가 운영 오류로 인해 실수로 유출될 위험이 있습니다.

CA 서명 키를 보호하기 위해 메시 관리자는 CA 키 순환과 같이 Google에서 보호 및 관리되는 메시 CA 또는 Certificate Authority Service(CA 서비스)를 사용하도록 메시를 업그레이드할 수 있습니다. Mesh CA와 달리 CA 서비스는 Cloud HSM에서 지원하는 Cloud KMS를 통해 고객별 HSM 지원 서명 키를 지원합니다.

워크로드 보안

워크로드 보안은 워크로드 포드를 손상시킨 후 손상된 포드를 사용하여 클러스터에 대해 공격을 시작하는 공격(예: 봇넷 공격)을 방어합니다.

포드 권한 제한

Kubernetes 포드에는 노드 또는 클러스터의 다른 포드에 영향을 주는 권한이 있을 수 있습니다. 손상된 포드가 클러스터에 대한 공격을 시작하지 못하도록 방지하기 위해 워크로드 포드에 보안 제한을 적용하는 것이 중요합니다.

포드에서 워크로드에 대해 최소 권한 원칙을 적용하려면 다음 안내를 따르세요.

  • 메시에 배포된 서비스를 가능한 한 최소 권한으로 실행해야 합니다.
  • 권한이 있는 모드로 실행되는 Kubernetes 포드는 호스트에서 네트워크 스택 및 기타 커널 기능을 조작합니다. GKE Enterprise 정책 컨트롤러를 사용하여 포드에서 권한이 있는 컨테이너를 실행하지 못하도록 방지할 수 있습니다.
  • 초기화 컨테이너를 사용하여 사이드카로의 iptables 트래픽 리디렉션을 구성하도록 Cloud Service Mesh를 구성할 수 있습니다. 이렇게 하려면 워크로드 배포를 수행하는 사용자에게 NET_ADMIN 및 NET_RAW 기능으로 컨테이너를 배포할 수 있는 권한이 있어야 합니다. 승격된 권한으로 컨테이너 실행 위험이 방지되도록 메시 관리자는 대신 Istio CNI 플러그인을 사용 설정하여 사이드카로 트래픽 리디렉션을 구성할 수 있습니다.

컨테이너 이미지 보호

공격자가 취약한 컨테이너 이미지를 악용하여 공격을 시작할 수 있습니다. 관리자는 Binary Authorization을 적용하여 컨테이너 이미지의 무결성을 확인하고 신뢰할 수 있는 컨테이너 이미지만 메시에 배포되도록 해야 합니다.

메시 취약점 완화

  • 컨테이너 분석. 컨테이너 분석은 GKE 워크로드의 취약점을 스캔하고 표시할 수 있습니다.
  • CVE(Common Vulnerabilities and Exposures) 처리. 컨테이너 이미지에서 취약점이 발견되면 메시 관리자는 최대한 빨리 취약점을 수정해야 합니다. 관리형 데이터 영역이 있는 관리형 Cloud Service Mesh의 경우 Google에서 메시 이미지에 영향을 주는 CVE 패치를 자동으로 처리합니다.

GKE용 워크로드 아이덴티티 제휴를 사용하여 Google 서비스에 안전하게 액세스

메시 워크로드가 Google 서비스에 안전하게 액세스하도록 하기 위해 GKE용 워크로드 아이덴티티 제휴를 사용하는 것이 좋습니다. Kubernetes 보안 비밀에 서비스 계정 키를 저장하고 이 서비스 계정 키를 사용하여 Google 서비스에 액세스하는 것은 사용자 인증 정보 유출, 권한 에스컬레이션, 정보 공개, 부인 방지 위험으로 인해 안전하지 않습니다.

보안 대시보드 및 원격 분석을 통해 보안 상태 모니터링

서비스 메시에는 보안 예외 및 잠재적인 허점이 있을 수 있습니다. 적용된 보안 정책, 보안 예외, 메시의 잠재적인 보안 허점을 포함하여 메시의 보안 상태를 표시하고 모니터링하는 것이 중요합니다. GKE Enterprise 보안 대시보드 및 원격 분석을 사용하여 메시 보안 상태를 표시하고 모니터링할 수 있습니다.

원격 분석은 메시의 서비스 상태 및 성능을 모니터링하여 메시 관리자가 SLO, 비정상 트래픽, 서비스 중단, 토폴로지 등의 서비스 동작을 관찰할 수 있게 해줍니다.

GKE Enterprise 보안 대시보드는 액세스 제어 정책(Kubernetes 네트워크 정책, Binary Authorization 정책, 서비스 액세스 제어 정책) 및 인증 정책(mTLS)을 포함하여 서비스 메시에서 워크로드에 적용된 보안 정책을 분석하고 시각화합니다.

민감한 사용자 데이터 및 사용자 인증 정보 보안

민감한 사용자 데이터 또는 사용자 인증 정보는 Kubernetes 보안 비밀을 사용하거나 포드에 직접 저장하는 것과 같이 클러스터 영구 스토리지에 저장될 경우 포드 또는 악의적인 작업으로부터 시작되는 공격에 취약할 수 있습니다. 또한 서비스 인증을 위해 네트워크로 전송될 경우 네트워크 공격에도 취약합니다.

  • 가능한 경우 Secret Manager 및 Cloud KMS와 같은 보호되는 스토리지에 민감한 사용자 데이터 및 사용자 인증 정보를 저장하세요.
  • 민감한 정보에 액세스하는 Kubernetes 포드에 개별 네임스페이스를 지정하고 다른 네임스페이스에서 액세스할 수 없도록 Kubernetes 정책을 정의합니다. 작업에 사용되는 역할을 분류하고 네임스페이스 경계를 적용합니다.
  • 권한이 높은 장기 토큰의 유출을 방지하려면 토큰 교환을 적용합니다.

다음 단계