Istio API를 사용하는 Cloud Service Mesh 보안 권장사항

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

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

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

• 소개
• 공격 벡터 및 보안 위험
  • 공격 벡터
  • 보안 위험
• 서비스 메시 보호 방법
  • 보안 아키텍처
  • 클러스터 보안
    • 엄격한 상호 TLS 사용 설정
    • 액세스 제어 사용 설정
      • Cloud Service Mesh 인증 정책 적용
      • JSON 웹 토큰(JWT)
      • Cloud Service Mesh 사용자 인증
      • 승인 정책 적용
      • 메시 서비스 액세스를 위한 토큰 교환 적용
    • Cloud Service Mesh 정책 예외를 안전하게 처리
      • Kubernetes 네트워크 정책 적용
    • 네임스페이스 경계 적용
      • Kubernetes RBAC 정책 적용
  • 메시 에지 보안
    • 클러스터 인그레스 액세스 제어
    • 클러스터 이그레스 트래픽 규제
    • 비공개 클러스터 또는 VPC 서비스 제어를 사용하여 외부 액세스 차단
    • 외부 DDoS 공격 방어
  • 메시 관리 및 자동화 보안
    • 메시 작업에 사용되는 역할 분류
    • 정책 구성 자동 검증
      • 구성 동기화를 사용하는 GitOps 방식으로 구성 드리프트 방지
    • Cloud 감사 로그 및 모니터링 적용
  • 워크로드 보안
    • 포드 권한 제한
    • 컨테이너 이미지 보호
    • 메시 취약점 완화
    • GKE용 워크로드 아이덴티티 제휴를 사용하여 Google 서비스에 안전하게 액세스
    • 보안 대시보드 및 원격 분석을 통해 보안 상태 모니터링
  • 민감한 사용자 데이터 및 사용자 인증 정보 보안

소개

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

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

이 문서는 상호 TLS(mTLS), 권한 부여 정책, 게이트웨이, 기타 보안 구성에 대한 자세한 구성 권장사항이 포함된 Istio의 보안 권장사항 문서를 보완합니다. 이러한 권장사항을 기초로 해서 이 문서에 요약된 권장사항과 함께 사용하세요. 이 문서에서는 Cloud Service Mesh의 추가 권장사항과 Google Cloud 기술을 통해 모든 레이어, 구성요소 및 메시의 정보 흐름을 보호하는 방법을 설명합니다.

공격 벡터 및 보안 위험

공격 벡터

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

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

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

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

보안 위험

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

• 불완전한 보안 보호. 서비스 메시에 보안을 위한 인증 및 승인 정책이 구성되지 않았을 수 있습니다. 예를 들어 메시의 서비스에 인증 또는 승인 정책이 정의되어 있지 않습니다.
• 보안 정책 예외. 특정 사용 사례를 수용하기 위해 사용자는 특정 트래픽(내부 또는 외부)에 대한 보안 정책 예외를 만들어 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 인증서를 보호하고 순환합니다.
  • VPC 및 VPC 서비스 제어는 비공개 네트워크 액세스 제어를 통해 메시 에지를 보호합니다.
• 클러스터 보안
  • Cloud Service Mesh 상호 TLS(mTLS)는 워크로드 간 트래픽 암호화 및 인증을 적용합니다.
  • Cloud Service Mesh 인증 기관은 워크로드에 사용되는 인증서를 안전하게 프로비저닝하고 관리합니다.
  • 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은 메시의 워크로드 이미지가 관리자 승인을 받은 이미지인지 확인합니다.
  • Cloud 감사 로그는 메시 작업을 감사합니다.

다음 다이어그램은 Cloud Service Mesh에서 통합된 보안 솔루션이 포함된 커뮤니케이션 및 구성 흐름을 보여줍니다.

클러스터 보안

이 섹션에서는 클러스터 보안과 관련된 권장사항을 설명합니다.

엄격한 상호 TLS 사용 설정

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

Cloud Service Mesh를 사용하면 보안 및 규정 준수 요구사항을 충족하기 위해 워크로드 간의 TLS 연결에 대한 최소 TLS 버전을 구성할 수 있습니다.

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

액세스 제어 사용 설정

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

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

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

Cloud Service Mesh 인증 정책 적용

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 주소 및 포트의 네트워크 액세스를 제어합니다.

참고: Cloud Service Mesh는 비TCP 트래픽(예: UDP 트래픽)을 처리하지 않으므로 승인 정책으로 제어될 수 없습니다. 메시 관리자는 Kubernetes 네트워크 정책을 사용하여 UDP 트래픽에 대한 정책을 정의할 수 있습니다. 예를 들어 메시 서비스가 UDP를 사용하지 않는 경우 메시 관리자는 UDP 트래픽을 차단하는 Kubernetes 네트워크 정책을 정의할 수 있습니다.

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

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

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

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

참고: IAP 토큰 교환은 IAP가 단기 내부 토큰으로 외부 토큰을 교환하여 토큰 재생 공격을 방어한다는 점에서 Cloud Service Mesh 사용자 인증과 다릅니다. 반면 Cloud Service Mesh 사용자 인증은 웹 애플리케이션 서비스에 대한 웹브라우저 기반 외부 호출을 사용합니다.

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 보안 정책이 적용된 포트만 트래픽이 통과하도록 허용합니다.

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

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

Cloud 감사 로그 및 모니터링 적용

메시 관리자는 다음을 모니터링하는 것이 좋습니다.

• Cloud 감사 로그
• Cloud Service Mesh 감사 로깅
• 정책 제약조건 감사 로깅
• Anthos 구성 동기화
• 액세스 로그
• 서비스 수준 측정항목
• Cloud Trace 사용

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

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

워크로드 보안

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

포드 권한 제한

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

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

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

컨테이너 이미지 보호

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

메시 취약점 완화

• Artifact Analysis는 GKE 워크로드의 취약점을 스캔하고 표시할 수 있습니다.
• 일반 취약점 및 노출(CVE) 처리. 컨테이너 이미지에서 취약점이 발견되면 메시 관리자는 최대한 빨리 취약점을 수정할 수 있습니다. Google은 메시 이미지에 영향을 주는 CVE 패치를 자동으로 처리합니다.

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

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

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

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

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

GKE Enterprise 보안 대시보드에는 액세스 제어 정책,(Kubernetes 네트워크 정책, Binary Authorization 정책, 서비스 액세스 제어 정책) 및 인증 정책(mTLS)를 포함하여 서비스 메시의 워크로드에 적용되는 보안 정책이 표시됩니다.

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

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

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