Google Kubernetes Engine (GKE) 클러스터에서 알 수 없거나 신뢰할 수 없는 코드를 실행하는 컨테이너는 노드의 호스트 커널에 잠재적인 보안 위험이 됩니다. 커널에서 코드를 격리하여 이러한 위협으로부터 호스트 커널을 보호할 수 있습니다. 이 문서에서는 GKE 샌드박스가 gVisor 및 마이크로 VM과 같은 기술을 사용하여 이러한 격리 계층을 만드는 방법을 설명합니다.
이 문서는 GKE 노드의 공격 표면을 줄이고 신뢰할 수 없는 코드로부터 노드를 보호하려는 보안 전문가를 대상으로 합니다. 다음 개념에 익숙해야 합니다.
GKE의 샌드박싱 정보
containerd와 같이 노드에 설치된 컨테이너 런타임은 컨테이너 프로세스와 노드에서 실행되는 커널 간에 어느 정도의 격리를 제공합니다. 그러나 컨테이너 런타임은 많은 경우 노드에서 권한이 높은 사용자로 실행되고 호스트 커널에 대한 대부분의 시스템 호출에 액세스할 수 있습니다.
Kubernetes 및 GKE에서 샌드박스는 실행 중인 컨테이너를 격리하여 다른 컨테이너 또는 컨테이너 런타임에 영향을 미치는 악용 또는 오류의 잠재적 영향을 제한합니다. 샌드박스에서 컨테이너를 실행하여 신뢰할 수 없거나 알 수 없는 코드로부터 기본 Compute Engine 인스턴스의 커널을 보호할 수 있습니다. 샌드박스는 다른 워크로드의 영향을 받지 않도록 고가치 컨테이너를 보호하는 좋은 심층 방어 측정 단위이기도 합니다. GKE Sandbox를 사용하여 샌드박스에서 워크로드를 실행할 수 있습니다.
잠재적 위협
컨테이너 런타임 또는 호스트 커널의 결함으로 인해 컨테이너 내에서 실행되는 프로세스가 컨테이너에서 '이스케이프'하여 노드의 커널에 영향을 미칠 수 있습니다. 멀티 테넌트 클러스터와 컨테이너가 신뢰할 수 없는 워크로드를 실행하는 클러스터는 다른 클러스터보다 보안 취약점에 더 많이 노출됩니다. 예를 들면 다음과 같습니다.
- 사용자가 코드를 업로드하고 실행하도록 허용하는 조직(예: SaaS 제공업체, 웹 호스팅 제공업체)
- 코드를 생성하고 실행하는 AI 에이전트(감독 없이 실행되는 경우가 많음)
GKE Sandbox에서 사용하는 샌드박싱 기술은 컨테이너 이스케이프의 다음과 같은 잠재적 영향을 완화하는 데 도움이 됩니다.
- 호스트 커널을 비정상 종료하고 노드를 다운시키는 악성 또는 결함이 있는 코드
- 메모리나 디스크에 있는 다른 테넌트의 데이터를 추출하는 악의적인 테넌트
- 다른 Google Cloud 서비스나 클러스터 메타데이터에 액세스하는 신뢰할 수 없는 워크로드
GKE의 샌드박스 기술
GKE Sandbox는 다음 샌드박스 기술을 지원하며, 각 기술은 워크로드를 격리하는 서로 다른 접근 방식을 사용하고 다양한 사용 사례에 적합합니다.
gVisor: 승격된 권한이 필요 없는 Linux 커널 API의 사용자 공간 재구현입니다. 사용자 공간 커널과 컨테이너 런타임은 대부분의 시스템 호출을 다시 구현하고 호스트 커널을 대신하여 서비스를 제공합니다. 호스트 커널에 대한 직접 액세스는 제한됩니다. 게스트 커널의 작동 방식에 대한 자세한 내용은 gVisor 아키텍처 가이드를 참고하세요.
MicroVMs: 전체 Linux 커널과 운영체제를 실행하는 경량 가상 머신입니다. 각 포드는 자체 마이크로VM에서 실행되므로 다른 포드 및 호스트 노드로부터 엄격하게 격리됩니다. GKE 샌드박스는 오픈소스 Kata Containers 소프트웨어와 Cloud Hypervisor 가상 머신 모니터(VMM)를 사용하여 microVM을 만들고 관리합니다.
다음 표에는 gVisor와 마이크로VM의 주요 차이점이 요약되어 있습니다. 이 정보를 사용하여 사용 사례에 적합한 샌드박스 기술을 선택하세요.
| gVisor | MicroVMs | |
|---|---|---|
| 커널 액세스 | Linux 커널 syscall의 하위 집합 | 전체 Linux 커널 |
| 격리 수준 | 사용자 공간 커널의 시스템 호출 가로채기 | 전용 게스트 커널을 사용한 전체 하드웨어 가상화 |
| CPU 및 메모리 오버헤드 | 사용자 공간 커널의 기본 메모리가 적은 동적 오버헤드 | 각 포드의 고정 오버헤드: 250mCPU, 130MiB 메모리 |
| 시작 시간 | 200ms 미만 | 약 1~2초 |
| GKE 노드 구성 | 모든 Standard 노드 풀과 Autopilot 노드에서 사용할 수 있습니다. Autopilot 클러스터에서 기본적으로 사용 설정됩니다. | 중첩된 가상화를 사용 설정하는 노드에서만 사용할 수 있습니다. |
| 노드 이미지 지원 | Container-Optimized OS만 해당 | Container-Optimized OS 또는 Ubuntu |
| 머신 유형 호환성 | 대부분의 CPU, Arm 아키텍처, 가속기 머신 유형에서 지원됩니다. | 중첩된 가상화를 지원하는 머신 유형에서만 지원됩니다. |
| 가속기 지원 | 특정 GPU 모델 및 TPU 버전을 지원합니다. | GPU 또는 TPU를 지원하지 않습니다. |
| 높은 권한을 가진 컨테이너 | 지원되지 않음. | 지원됨 권한이 있는 컨테이너는 마이크로VM의 게스트 OS에만 루트 액세스 권한을 부여받으며 호스트 노드에는 부여받지 않습니다. |
| 사용 사례 |
|
|
특정 유형의 샌드박스에서 실행할 애플리케이션을 결정하는 데 도움이 되는 자세한 내용은 제한사항을 참고하세요.
샌드박스 요청 방식
샌드박스에서 애플리케이션을 실행하려면 다음을 수행합니다.
- ComputeClass를 사용하여 노드를 자동 생성하거나 노드 풀을 수동으로 만들어 노드에서 샌드박스 기술을 사용 설정합니다.
gvisor또는microvm와 같은 샌드박스 유형에 해당하는 RuntimeClass를 사용하여 포드에 대한 샌드박스를 요청합니다. 자세한 내용은 GKE Sandbox로 워크로드 격리 강화를 참조하세요.
GKE는 요청된 샌드박스 기술을 사용하는 노드에 포드를 예약하고, 이 노드는 샌드박스에서 애플리케이션 실행을 처리합니다. 원하는 경우 노드 선택기와 허용을 사용하여 GKE Sandbox가 사용 설정된 노드에서 샌드박스를 요청하지 않는 포드를 실행할 수 있습니다. 이는 모든 노드에서 실행하려는 모니터링 도구와 같은 신뢰할 수 있는 워크로드에 유용합니다.
추가 보안 권장사항
GKE Sandbox를 사용하는 경우 다음 권장사항도 따르는 것이 좋습니다.
샌드박스에서 실행되는 모든 컨테이너에 리소스 제한을 지정합니다. 이렇게 하면 결함이 있거나 악성인 애플리케이션으로 인해 노드가 리소스를 받지 못하게 되어 해당 노드에서 실행 중인 다른 애플리케이션 또는 시스템 프로세스가 피해를 입을 위험이 방지됩니다.
GKE용 워크로드 아이덴티티 제휴를 사용하는 경우
169.254.169.254에 대한 액세스를 차단하기 위해 네트워크 정책을 사용하여 클러스터 메타데이터 액세스를 차단합니다. 이렇게 하면 악성 애플리케이션이 프로젝트 ID, 노드 이름, 영역과 같은 비공개 데이터에 대한 정보에 액세스하는 위험을 방지할 수 있습니다. GKE용 워크로드 아이덴티티 제휴는 항상 GKE Autopilot 클러스터에서 사용 설정됩니다.
제한사항
GKE Sandbox는 많은 애플리케이션에서 잘 작동하지만 그렇지 않은 경우도 있습니다. 이 섹션에서는 GKE Sandbox의 현재 제한사항에 대해 자세히 설명합니다.
GKE Sandbox의 GPU
gVisor를 사용하여 샌드박스에서 GPU 워크로드를 실행할 수 있습니다. gVisor는 모든 NVIDIA 드라이버 취약점을 완화하지는 않지만 Linux 커널 취약점에 대해서는 보호 기능을 유지합니다. 샌드박스 포드에서는 GPU 시간 공유를 사용하지 마세요. 포드 간에 GPU가 완전히 격리되지 않기 때문입니다. gVisor가 GPU 워크로드를 보호하는 방법에 대한 자세한 내용은 GPU 지원 가이드를 참조하세요.
GKE Sandbox의 GPU 워크로드에는 다음 제한사항이 적용됩니다.
- MicroVM은 GPU를 지원하지 않습니다.
- gVisor에는 다음과 같은 제한사항이 적용됩니다.
- CUDA 워크로드만 지원됩니다.
- 사용 가능한 GPU 모델 중 일부만 지원됩니다. 자세한 내용은 GPU 모델 지원을 참고하세요.
- 각 GKE 버전에는
latest및defaultNVIDIA 드라이버 버전만 지원됩니다. 다른 드라이버 버전은 작동하지 않을 수 있습니다. - RDMA 또는 IMEX와 같은 일부 GPU 기능은 지원되지 않습니다. 고객의 요구사항에 따라 gVisor는 사례별로 특정 기능을 지원할 수 있습니다. 특정 기능에 대한 지원을 요청하려면 지원 케이스를 열거나 gVisor 기능 요청을 여세요.
GPU 모델 지원
다음 표에서는 GKE Sandbox에서 다양한 GPU 모델에 대한 지원 여부를 설명합니다.
| 모델 | 미리보기 | GA 지원 | 참고 |
|---|---|---|---|
|
|
|
- | - |
|
|
|
- | - |
|
|
- |
|
초기 출시부터 지원됩니다. |
|
|
지원되지 않음 | 지원되지 않음 | V100 및 P100은 독점 드라이버를 사용하므로 지원되지 않습니다. |
|
|
- | - | GKE Sandbox는 가상 워크스테이션 노드에 필요한 Windows 또는 Ubuntu 노드 유형을 지원하지 않습니다. |
GKE Sandbox의 TPU
GKE 버전 1.31.3-gke.1111001 이상에서는 gVisor를 사용하여 샌드박스에서 TPU 워크로드를 실행할 수 있습니다. gVisor는 모든 TPU 드라이버 취약점을 완화하지는 않지만 Linux 커널 취약점에 대해서는 보호 기능을 유지합니다. gVisor 프로젝트가 TPU 워크로드를 어떻게 보호하는지에 대한 자세한 내용은 TPU 지원 가이드를 참고하세요.
GKE Sandbox의 TPU 워크로드에는 다음 제한사항이 적용됩니다.
- MicroVM은 TPU를 지원하지 않습니다.
gVisor는 다음 TPU 버전을 지원합니다.
- V4pod
- V4lite
- V5litepod
- V5pod
- V6e
노드 구성
GKE Sandbox를 사용하는 노드에는 다음과 같은 제한사항이 적용됩니다.
- gVisor 및 마이크로 VM은 Linux 노드만 지원합니다. Windows Server 노드는 지원되지 않습니다.
- gVisor는 Container-Optimized OS 노드 이미지만 지원합니다. MicroVM은 Container-Optimized OS 및 Ubuntu 노드 이미지를 지원합니다.
- 마이크로 VM을 사용하려면 노드에서 중첩된 가상화를 사용 설정해야 합니다. 중첩된 가상화의 모든 요구사항 및 제한사항이 적용됩니다.
- Standard 클러스터에서는 기본 노드 풀에서 GKE Sandbox를 사용 설정할 수 없습니다. 클러스터에는 항상 GKE Sandbox를 사용하지 않는 노드 풀이 하나 이상 있어야 합니다. 모든 워크로드가 샌드박스 처리된 경우에도 해당 노드 풀에 노드가 하나 이상 포함되어야 합니다. 이 제한은 신뢰할 수 없는 워크로드에서 시스템 서비스를 분리하기 위해 존재합니다.
클러스터 메타데이터 액세스
노드에서 gVisor 샌드박스 유형을 사용하는 경우 노드의 포드는 노드 OS 수준에서 클러스터 메타데이터에 액세스할 수 없습니다. GKE용 워크로드 아이덴티티 제휴를 사용하여 포드 ID에 역할을 부여하지 않으면 포드가 Google Cloud서비스에 액세스할 수 없습니다.
이 제한사항은 microVM 샌드박스 유형에는 적용되지 않습니다. 마이크로 VM의 포드에서 클러스터 메타데이터에 액세스하지 못하도록 하려면 포트 988의 169.254.169.252/32 또는 GKE Dataplane V2를 사용하는 클러스터의 경우 포트 80의 169.254.169.254/32로 나가는 트래픽을 거부하는 NetworkPolicy를 사용하세요.
SMT가 사용 중지될 수 있음
동시 멀티스레딩 (SMT) 설정 (Intel CPU의 하이퍼 스레딩이라고도 함)은 마이크로아키텍처 데이터 샘플링 (MDS) 취약점과 같이 핵심 상태를 공유하는 스레드를 활용하는 사이드 채널 취약점을 완화하는 데 사용됩니다.
사이드 채널 공격을 완화하기 위해 gVisor는 Linux 코어 예약을 사용합니다. SMT 설정은 기본값에서 변경되지 않습니다. Linux 코어 예약은 gVisor 샌드박스에서 실행되는 포드에만 적용됩니다.
머신 유형의 기본 SMT 또는 하이퍼스레딩 설정은 머신이 MDS에 얼마나 취약한지에 따라 달라집니다.
Scale-OutComputeClass를 사용하는 Autopilot 포드: SMT가 항상 사용 중지됩니다.- Intel 프로세서를 사용하는 머신 유형: 기본적으로 하이퍼 스레딩이 사용 중지되어 있습니다.
- AMD 프로세서를 사용하는 머신 유형: 기본적으로 SMT가 사용 설정되어 있습니다.
- 코어당 스레드를 하나만 사용하는 머신 유형(예: Arm 프로세서): SMT를 지원하지 않습니다. 요청한 모든 vCPU가 표시됩니다.
SMT 사용 설정
GKE Standard 노드 풀에서는 선택한 머신 유형에서 SMT가 기본적으로 비활성화되어 있는 경우 이를 사용 설정할 수 있습니다. SMT를 사용 설정하든 사용 중지된 상태로 유지하든, 모든 vCPU에 대해 요금이 청구됩니다. 자세한 내용은 코어당 스레드 수를 변경할 때의 가격 책정을 참조하세요. SMT 설정을 변경하려면 다음 중 하나를 수행합니다.
gVisor를 사용하는 GKE Sandbox 노드 풀을 만들 때
--threads-per-core플래그를 설정합니다.gcloud container node-pools create smt-enabled \ --cluster=CLUSTER_NAME \ --location=LOCATION \ --machine-type=MACHINE_TYPE \ --threads-per-core=2 \ --sandbox=type=gvisorCLUSTER_NAME: 새 노드 풀을 만들려는 기존 클러스터의 이름입니다.LOCATION: 클러스터의 Compute Engine 리전 또는 영역입니다.MACHINE_TYPE: 머신 유형
DaemonSet를 사용하여 기존 노드 풀에서 SMT를 사용 설정합니다.
gVisor를 사용하는 기존 노드 풀에
cloud.google.com/gke-smt-disabled=false노드 라벨을 추가합니다.gcloud container node-pools update NODE_POOL_NAME \ --cluster=CLUSTER_NAME \ --location=LOCATION \ --node-labels=cloud.google.com/gke-smt-disabled=false다음을 바꿉니다.
NODE_POOL_NAME: 기존 노드 풀의 이름입니다.CLUSTER_NAME: 새 노드 풀을 만들려는 기존 클러스터의 이름입니다.LOCATION: 클러스터의 Compute Engine 리전 또는 영역입니다.
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.yamlDaemonSet 포드가 실행 중인 상태인지 확인합니다.
kubectl get pods --selector=name=enable-smt -n kube-system출력은 다음과 비슷합니다.
NAME READY STATUS RESTARTS AGE enable-smt-2xnnc 1/1 Running 0 6m포드의 로그에
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 드라이버 사용을 지원합니다.
호환되지 않는 기능
GKE Sandbox에는 다음과 같은 기능 제한사항이 적용됩니다.
gVisor 및 마이크로 VM 샌드박스 모두에 다음 제한사항이 적용됩니다.
- Cloud Service Mesh는 Autopilot 클러스터의 샌드박스에서 지원되지 않습니다.
- seccomp, AppArmor, SELinux, 새 권한 없음 플래그, 양방향 마운트 전파,
procMount포드 보안 컨텍스트와 같은 Linux 커널 보안 모듈은 샌드박스 포드에서 지원되지 않습니다. - 컨테이너 수준의 메모리 사용량 측정항목은 지원되지 않습니다. 하지만 포드 메모리 사용량은 지원됩니다.
다음 제한사항은 gVisor 샌드박스에만 적용됩니다.
- 권한이 있는 모드를 사용하는 컨테이너는 지원되지 않습니다.
- 원시 블록 볼륨은 지원되지 않습니다.
kubectl port-forward를 사용하는 등의 포트 포워딩은 지원되지 않습니다.- Hostpath 스토리지는 지원되지 않습니다.
sysctl커널 매개변수 설정은 지원되지 않습니다.- CPU 및 메모리 한도는
Guaranteed또는BurstableQoS 클래스가 있는 포드에만 적용되며, 포드의 모든 컨테이너에 CPU 및 메모리 한도가 지정된 경우에만 적용됩니다.
다음 제한사항은 마이크로VM 샌드박스에만 적용됩니다.
hostNetwork: true설정을 사용하는 포드는 지원되지 않습니다. 마이크로VM 샌드박스에서 실행되고hostNetwork: true설정을 사용하는 포드는 포드 외부의 리소스에 액세스할 수 없습니다.- 소켓 수준 추적을 사용하는 진단 도구는 microVM에 연결된 네트워크 인터페이스에만 액세스할 수 있습니다.