GKE Sandbox

이 페이지에서는 포드의 컨테이너가 알 수 없거나 신뢰할 수 없는 코드를 실행할 때 GKE Sandbox를 사용하여 노드의 호스트 커널을 보호하는 방법을 설명합니다 예를 들어 Software as a Service(SaaS) 제공업체와 같은 멀티 테넌트 클러스터는 사용자가 제출한 알 수 없는 코드를 실행하는 경우가 많습니다. 또한 GKE Sandbox는 고가치 컨테이너를 실행하기 위한 유용한 심층 방어 측정 단위입니다.

GKE Sandbox는 오픈소스 프로젝트인 gVisor를 사용합니다. 이 주제에서는 gVisor에 대해 폭넓게 논의하지만 공식 gVisor 문서에서 더 자세히 알아볼 수 있습니다.

GKE Sandbox를 사용 설정하고 사용하는 방법은 GKE Sandbox 구성을 참조하세요.

개요

GKE Sandbox는 신뢰할 수 없는 코드가 클러스터 노드의 호스트 커널에 영향을 미치지 않도록 차단하는 부가적인 보안 레이어를 제공합니다. GKE Sandbox의 작동 방식을 논의하기 전에 이 도구가 완화해주는 잠재적인 위험의 속성을 이해하면 도움이 됩니다.

containerd 같은 컨테이너 런타임은 컨테이너 프로세스와 노드에서 실행되는 커널 간에 어느 정도의 격리를 제공합니다. 그러나 컨테이너 런타임은 많은 경우 노드에서 권한이 높은 사용자로 실행되고 호스트 커널에 대한 대부분의 시스템 호출에 액세스할 수 있습니다.

잠재적 위협

컨테이너가 신뢰할 수 없는 워크로드를 실행하는 멀티 테넌트 클러스터와 클러스터는 다른 클러스터에 비해 보안 취약점에 더 많이 노출됩니다. 예를 들어 SaaS 제공업체, 웹 호스팅 제공업체, 기타 사용자가 코드를 업로드하고 실행하도록 허용하는 조직이 여기에 해당됩니다. 컨테이너 런타임이나 호스트 커널의 결함으로 인해 컨테이너 내에서 실행되는 프로세스가 컨테이너를 '벗어나' 노드의 커널에 영향을 미치고 잠재적으로 노드를 다운시킬 수 있습니다.

악의적인 테넌트가 이러한 결함을 악용하여 메모리나 디스크에 있는 다른 테넌트의 데이터에 액세스하고 추출할 수 있습니다.

마지막으로, 신뢰할 수 없는 워크로드가 다른 Google Cloud 서비스나 클러스터 메타데이터에 액세스할 가능성이 있습니다.

GKE Sandbox가 이러한 위협을 완화하는 방법

gVisor는 승격된 권한이 필요 없는, Linux 커널 API의 사용자 공간 재구현입니다. 사용자 공간 커널은 containerd와 같은 컨테이너 런타임과 함께 대부분의 시스템 호출을 다시 구현하고 호스트 커널을 대신하여 서비스합니다. 호스트 커널 직접 액세스는 제한됩니다. 자세한 방법은 gVisor 아키텍처 가이드를 참조하세요. 컨테이너 관점에서 gVisor는 거의 투명하며 컨테이너식 애플리케이션을 변경할 필요가 없습니다.

Autopilot 클러스터의 포드에서 GKE Sandbox를 요청하면 GKE는 샌드박스에서 해당 포드를 실행합니다. GKE Standard에서 노드에 GKE Sandbox를 사용 설정하면 해당 노드에서 실행되는 모든 포드가 샌드박스에서 실행됩니다.

각 샌드박스는 자체 사용자 공간 커널을 사용합니다. 이를 감안하여 필요한 격리 수준과 애플리케이션의 특성에 따라 컨테이너를 포드로 그룹화할 방법을 결정할 수 있습니다.

GKE Sandbox는 다음 유형의 애플리케이션에 특히 적합합니다. 샌드박스 대상 애플리케이션을 결정하는 데 도움이 되는 자세한 내용은 제한사항을 참조하세요.

  • Rust, 자바, Python, PHP, Node.js, Golang과 같은 런타임을 사용하는 신뢰할 수 없는 애플리케이션 또는 타사 애플리케이션
  • 웹 서버 프런트 엔드, 캐시, 프록시
  • CPU를 사용하여 외부 미디어 또는 데이터를 처리하는 애플리케이션
  • CPU를 사용하는 머신러닝 워크로드
  • CPU 집약적 또는 메모리 집약적 애플리케이션
  • GPU 집약적 워크로드

추가 보안 권장사항

GKE Sandbox를 사용하는 경우 다음 권장사항도 따르는 것이 좋습니다.

  • 샌드박스에서 실행되는 모든 컨테이너에 리소스 제한을 지정합니다. 이렇게 하면 결함이 있거나 악성인 애플리케이션으로 인해 노드가 리소스를 받지 못하게 되어 해당 노드에서 실행 중인 다른 애플리케이션 또는 시스템 프로세스가 피해를 입을 위험이 방지됩니다.

  • GKE용 워크로드 아이덴티티 제휴를 사용하는 경우 169.254.169.254에 대한 액세스를 차단하기 위해 네트워크 정책을 사용하여 클러스터 메타데이터 액세스를 차단합니다. 이렇게 하면 악성 애플리케이션이 프로젝트 ID, 노드 이름, 영역과 같은 비공개 데이터에 대한 정보에 액세스하는 위험을 방지할 수 있습니다. GKE용 워크로드 아이덴티티 제휴는 항상 GKE Autopilot 클러스터에서 사용 설정됩니다.

제한사항

GKE Sandbox는 많은 애플리케이션에서 잘 작동하지만 그렇지 않은 경우도 있습니다. 이 섹션에서는 GKE Sandbox의 현재 제한사항에 대해 자세히 설명합니다.

GKE Sandbox의 GPU

GKE 버전 1.29.2-gke.1108000 이상에서 GKE Sandbox는 NVIDIA GPU 사용을 지원합니다.

GKE Sandbox는 모든 NVIDIA 드라이버 취약점을 완화하지는 않지만 Linux 커널 취약점에 대한 보호 기능을 유지합니다. gVisor 프로젝트가 GPU 워크로드를 보호하는 방법에 대한 자세한 내용은 GPU 지원 가이드를 참조하세요.

GKE Sandbox 내의 GPU 워크로드에는 다음 제한사항이 적용됩니다.

  • 지정된 GKE 버전에서 latest NVIDIA 드라이버 버전만 지원됩니다. Autopilot 클러스터는 GKE Sandbox를 지원하는 NVIDIA 드라이버 버전을 자동으로 설치합니다.
  • CUDA 워크로드만 지원됩니다.
  • 지원되는 GPU 모델은 nvidia-tesla-t4, nvidia-tesla-a100, nvidia-a100-80gb, nvidia-l4, and nvidia-h100-80gb입니다.

추가 비용 없이 GPU 워크로드에 GKE Sandbox를 사용할 수 있습니다.

노드 풀 구성

Standard 클러스터에 적용

  • Windows Server 노드 풀에서는 GKE Sandbox를 사용할 수 없습니다.
  • GKE Sandbox를 사용하여 기본 노드 풀에서 실행되는 시스템 서비스를 신뢰할 수 없는 워크로드와 분리하도록 기본 노드 풀에서 GKE Sandbox를 사용 설정할 수 없습니다.
  • GKE Sandbox를 사용하는 경우 클러스터에 두 개 이상의 노드 풀이 있어야 합니다. GKE Sandbox가 사용 중지된 노드 풀이 항상 하나 이상 있어야 합니다. 모든 워크로드가 샌드박스 처리된 경우에도 이 노드 풀에 노드가 하나 이상 포함되어야 합니다.
  • 1.24.2-gke.300 이전의 GKE 버전은 e2-micro, e2-small, e2-medium 머신 유형을 지원하지 않습니다. GKE 버전 1.24.2-gke.300 이상은 이러한 머신 유형을 지원합니다.
  • 노드는 containerd(cos_containerd)가 포함된 Container-Optimized OS 노드 이미지를 사용해야 합니다.

클러스터 메타데이터 액세스

Autopilot 및 Standard 클러스터에 적용

  • 샌드박스 처리된 포드를 실행하는 노드는 노드의 운영체제 수준에서 클러스터 메타데이터에 액세스할 수 없습니다.
  • GKE Standard에서는 GKE Sandbox가 사용 설정된 노드에서 일반 포드를 실행할 수 있습니다. 그러나 이러한 일반 포드는 기본적으로 Google Cloud 서비스 또는 클러스터 메타데이터에 액세스할 수 없습니다.
  • 포드에 Google Cloud 서비스 액세스 권한을 부여하려면 GKE용 워크로드 아이덴티티 제휴를 사용합니다.

SMT가 사용 중지될 수 있음

Autopilot 및 Standard 클러스터에 적용

동시 멀티 스레드(SMT) 설정은 마이크로아키텍처 데이터 샘플링(MDS) 취약점과 같이 핵심 상태를 공유하는 스레드를 활용하는 사이드 채널 취약점을 완화하는 데 사용됩니다.

GKE 버전 1.25.5-gke.2500 이상 및 1.26.0-gke.2500 이상에서 gVisor는 Linux 코어 예약을 사용하여 사이드 채널 공격을 완화하도록 구성됩니다. SMT 설정은 기본적으로 변경되지 않습니다. 코어 예약은 gVisor로 실행되는 워크로드에만 사용됩니다.

GKE 버전 1.24.2-gke.300부터 머신이 MDS에 얼마나 취약한지를 기반으로 한 머신 유형에 따라 SMT가 구성됩니다.

  • Scale-Out 컴퓨팅 클래스에서 실행 중인 Autopilot 포드: SMT가 사용 중지됩니다.

  • Intel 프로세서를 갖춘 머신 유형: 기본적으로 SMT는 사용 중지됩니다.

  • Intel 프로세서가 없는 머신 유형: 기본적으로 SMT가 사용 설정됩니다.

  • 코어당 스레드가 하나만 있는 머신 유형: SMT는 지원되지 않습니다. 요청된 모든 vCPU가 표시됩니다.

버전 1.24.2-gke.300 이전에는 모든 머신 유형에서 SMT가 중지됩니다.

SMT 사용 설정

Standard 클러스터에 적용

GKE Standard 클러스터에서는 선택한 머신 유형에서 SMT가 비활성화되어 있는 경우 이를 사용 설정할 수 있습니다. SMT를 사용 설정하든 사용 중지된 상태로 유지하든 모든 vCPU에 요금이 부과됩니다. 가격 정보는 Compute Engine 가격 책정을 참조하세요.

GKE 버전 1.24.2-gke.300 이상

GKE Sandbox 노드 풀을 만들 때 --threads-per-core 플래그를 설정하세요.

gcloud container node-pools create smt-enabled \
  --cluster=CLUSTER_NAME \
  --machine-type=MACHINE_TYPE \
  --threads-per-core=2 \
  --sandbox type=gvisor
  • CLUSTER_NAME: 기존 클러스터의 이름
  • MACHINE_TYPE: 머신 유형

--threads-per-core에 대한 상세 설명은 코어당 스레드 수 설정을 참조하세요.

1.24.2-gke.300 이전의 GKE 버전

  1. cloud.google.com/gke-smt-disabled=false 노드 라벨을 사용하여 클러스터에 새 노드 풀을 만드세요.

    gcloud container node-pools create smt-enabled \
    --cluster=CLUSTER_NAME \
    --machine-type=MACHINE_TYPE \
    --node-labels=cloud.google.com/gke-smt-disabled=false \
    --image-type=cos_containerd \
    --sandbox type=gvisor

  2. 노드 풀에 DaemonSet를 배포합니다. DaemonSet는 cloud.google.com/gke-smt-disabled=false 라벨이 있는 노드에서만 실행됩니다.

    kubectl create -f \
    https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-node-tools/master/disable-smt/gke/enable-smt.yaml

  3. DaemonSet 포드가 실행 중인 상태인지 확인하세요.

    kubectl get pods --selector=name=enable-smt -n kube-system

    출력은 다음과 비슷합니다.

    NAME               READY     STATUS    RESTARTS   AGE
enable-smt-2xnnc   1/1       Running   0          6m

  4. 포드의 로그에 SMT has been enabled가 표시되는지 확인합니다.

    kubectl logs enable-smt-2xnnc enable-smt -n kube-system

기능

Standard 클러스터에 적용

악의적인 공격 가능성을 낮추기 위해 기본적으로 컨테이너는 원시 소켓을 열 수 없습니다. ping 및 tcpdump와 같은 특정 네트워크 관련 도구는 핵심 기능의 일부로 원시 소켓을 만듭니다. 원시 소켓을 사용 설정하려면 NET_RAW 기능을 컨테이너의 보안 컨텍스트에 명시적으로 추가해야 합니다.

spec:
  containers:
  - name: my-container
    securityContext:
      capabilities:
        add: ["NET_RAW"]

GKE Autopilot을 사용하면 Google Cloud는 이 기능이 보안에 미치는 영향으로 인해 NET_RAW 권한을 컨테이너에 추가할 수 없게 합니다.

외부 종속 항목

Autopilot 및 Standard 클러스터에 적용

샌드박스 내부에서 실행되는 신뢰할 수 없는 코드가 데이터베이스 서버, API, 기타 컨테이너, CSI 드라이버 등의 외부 서비스에 연결될 수 있습니다. 이러한 서비스는 샌드박스 경계 외부에서 실행되며 개별적으로 보호되어야 합니다. 공격자는 이러한 서비스의 취약점을 악용하여 샌드박스 침입을 시도할 수 있습니다. 샌드박스 내부에서 실행되는 코드를 통해 이러한 서비스에 연결될 수 있는 위험과 영향을 고려하고 필요한 조치를 취하여 이를 보호해야 합니다.

여기에는 ext4 및 CSI 드라이버와 같은 컨테이너 볼륨의 파일 시스템 구현이 포함됩니다. CSI 드라이버는 샌드박스 격리 외부에서 실행되며 호스트 및 서비스에 대한 액세스 권한을 가질 수 있습니다. 이러한 드라이버의 악용은 호스트 커널에 영향을 미치고 전체 노드를 손상시킬 수 있습니다. 악용의 경우 노출을 줄이려면 최소한의 권한이 필요한 컨테이너 내에서 CSI 드라이버를 실행하는 것이 좋습니다. GKE Sandbox는 Compute Engine Persistent Disk CSI 드라이버 사용을 지원합니다.

호환되지 않는 기능

다음 Kubernetes 기능으로는 GKE Sandbox를 사용할 수 없습니다.

워크로드 특성

Autopilot 및 Standard 클러스터에 적용

노드의 커널에 액세스하기 위한 부가적인 레이어를 두면 그만큼 성능이 저하됩니다. GKE Sandbox는 격리가 중요한 대규모 멀티 테넌트 클러스터에서 가장 확실한 이점을 제공합니다. GKE Sandbox로 워크로드를 테스트할 때는 다음 가이드라인에 유의하세요.

시스템 호출

Autopilot 및 Standard 클러스터에 적용

다수의 작은 I/O 작업과 같이 오버헤드가 낮은 시스템 호출을 대량으로 생성하는 워크로드를 사용하려면 샌드박스에서 실행될 때 더 많은 시스템 리소스가 필요할 수 있습니다. 따라서 더 강력한 노드를 사용하거나 클러스터에 노드를 추가해야 할 수 있습니다.

하드웨어 또는 가상화에 직접 액세스

Autopilot 및 Standard 클러스터에 적용

워크로드에 다음 중 어느 하나라도 필요한 경우 노드의 호스트 커널에 대한 직접 액세스를 차단하는 GKE Sandbox는 적합하지 않을 수 있습니다.

  • 노드의 하드웨어에 직접 액세스
  • 커널 수준 가상화 기능
  • 높은 권한을 가진 컨테이너

다음 단계