Skip to main content
이 페이지에서는 클러스터의 샌드박스에 적용할 정책을 작성하는 방법을 설명합니다. 컴퓨트, 이미지, 네트워크 액세스, 보안 태세의 허용 범위를 제한하고 모든 샌드박스가 상속하는 기본값을 설정합니다. 러너를 관리하는 Admin을 위한 문서입니다. 정책에서는 Sandbox API 요청에 대한 소스 IP 액세스 제어도 설정할 수 있습니다. 정책은 러너에 포함되므로 러너를 업데이트하여 작성합니다. 별도의 정책 리소스나 정책 엔드포인트는 없습니다. 정책에 따라 샌드박스 설정이 결정되는 방식은 정책 개요를 참조하세요.

시작하기 전에

조직에서 Sandbox Admin 역할을 가지고 있어야 합니다. 이 역할 없이 정책을 조회하거나 작성하면 PermissionDenied가 반환됩니다.
The Sandbox Admin role controls runner settings across the organization. On runners using legacy v1beta2 profiles, this role can enable privileged profile settings. These settings include privileged containers, host namespaces, and mounts of the Node’s filesystem. These settings can give sandboxes Node access comparable to that of a cluster administrator and put co-located workloads at risk. The v1 policy’s allow_privileged setting governs in-guest privilege within the sandbox’s isolation boundary.
CLI 예시를 사용하려면 CoreWeave Intelligent CLI를 설치하고 인증하세요. REST 예시를 사용하려면 CoreWeave API 토큰이 필요합니다. 예시에서는 해당 토큰에 $TOKEN을, 러너에 prod-us-east-1을 사용합니다. 모든 러너는 정확히 하나의 정책을 가지고 있으며, 정책은 필수입니다. 빈 정책도 유효하지만, 이 경우 base 기본값이나 명시적 제약 조건이 적용되지 않습니다. 이때도 플랫폼 안전 게이트는 그대로 적용되며, 런타임 클래스 허용 목록이 없으면 특정 runtime_class로 고정할 수 없습니다. 보안 태세 제한을 참조하세요.

현재 정책 조회

러너가 현재 가지고 있는 것부터 시작하세요. 빈 문서에서 시작하는 대신입니다.
상세 뷰를 확인하려면 describe를 추가하세요. 이 옵션은 러너에 정책이 없을 때 설정되지 않은 상태를 명시적으로 표시합니다.
-o json을 사용하면 한 번도 설정되지 않은 러너는 {} 대신 null을 반환하므로, 자동화에서 “never configured”와 “configured and permissive”를 구분할 수 있습니다.

정책 업데이트

정책은 러너의 필드이므로, policy 업데이트 마스크를 사용하여 러너를 업데이트함으로써 설정합니다. 정책 업데이트는 항상 전체 문서를 대체합니다. policy만 업데이트 마스크 경로로 구현되어 있으므로, 하나의 제약 조건 그룹을 패치하고 나머지는 그대로 둘 수 없습니다. 현재 정책을 조회하고, 필요한 부분을 변경한 후 전체 문서를 다시 전송하세요.
러너의 현재 문서로 시드된 $EDITOR에서 정책을 편집합니다:
파일에서 또는 -로 stdin에서 문서를 적용합니다:
-f를 사용하면 cwic는 제출 시점에 러너의 현재 리비전을 조회합니다. 따라서 이전에 조회한 내용을 기준으로 편집한 파일이 다른 관리자의 변경 사항을 덮어쓸 수 있습니다. 파일의 기준이 된 리비전을 고정하려면 러너를 한 번만 조회하여 정책과 해당 etag를 함께 캡처하세요:
policy.json을 편집한 후, 같은 조회에서 얻은 etag와 함께 제출합니다:
etag는 반드시 문서를 가져온 바로 그 조회에서 얻어야 하며, 그 이후의 조회에서 가져와서는 안 됩니다. policy get은 etag 없이 정책을 내보내며, 내보낸 후에 policy describe를 실행하면 더 새로운 토큰이 반환될 수 있습니다. 이 토큰은 검사를 통과하기 때문에, 그 사이에 이루어진 변경 사항을 파일이 덮어쓰게 됩니다. curl 탭과 정책 교체에서도 같은 방식으로 하나의 응답에서 두 값을 모두 캡처합니다.편집기 모드에서는 편집기를 시드할 때 조회한 etag를 그대로 전송하므로 플래그가 필요 없습니다.현재 문서가 아닌 스캐폴드에서 시작하려면 템플릿을 출력합니다:
전송하기 전에 문서를 확인합니다:
모든 정책 쓰기에는 세 가지 규칙이 적용됩니다:
  • 수명은 정책이 아닌 플랫폼에 의해 제한됩니다. 정책은 생성 요청에서 수명을 생략할 때 사용되는 constraints.lifecycle.defaultLifetimeSeconds만 제공합니다. 플랫폼은 생성 시점에 최대값(현재 30일)을 초과하는 수명을 거부합니다. 이전 정책 버전에는 maxLifetimeSeconds 한도가 포함되어 있었으나, 현재 cwic는 이를 포함한 문서를 거부합니다.
  • 설정된 정책은 지울 수 없습니다. 삭제 오퍼레이션이 없으며, API는 정책을 null로 설정하는 업데이트를 거부합니다. 보안 태세를 완화하려면 더 관대한 문서로 교체하세요.
  • 정책 문서는 인코딩 후 256 KiB로 제한됩니다.
정책 쓰기는 읽기-수정-쓰기 방식으로 이루어지며, 편집의 기준이 된 러너 조회에서 얻은 etag를 기준으로 검사됩니다. 해당 조회 이후 다른 관리자가 정책을 업데이트했다면, API는 FAILED_PRECONDITION 오류와 함께 쓰기를 거부하며 아무것도 변경하지 않습니다. 이 경우 러너를 다시 조회하고, 반환된 문서에 변경 사항을 다시 적용한 후 새 etag와 함께 다시 제출하세요. 새 etag만 가져와서 기존 문서를 그대로 다시 전송하면 검사는 통과하지만, 쓰기는 여전히 전체 문서를 대체하므로 다른 관리자가 편집한 내용이 사라집니다.
수명 예시와 Serverless 및 CKS 간의 차이는 장기 실행 샌드박스 실행을 참조하세요. 정책 기본값과 제약 조건은 샌드박스가 생성될 때 확인됩니다. 정책을 저장해도 실행 중인 샌드박스가 자동으로 재구성되지는 않습니다. 새로운 배치와 명시적인 실시간 네트워크 업데이트는 게이트웨이에 현재 캐시된 러너 정책을 기준으로 확인됩니다. 소스 IP 액세스 제어는 새로운 배치뿐 아니라 기존 샌드박스에 대한 새 오퍼레이션에도 적용됩니다. 업데이트 직후에는 캐시된 정책이 잠시 늦게 반영될 수 있습니다.
정책 명령어는 v1 API를 사용해 조회 및 쓰기를 수행하지만, 다른 cwic sandbox runner 및 cwic sandbox profile 명령어는 여전히 v1beta2를 사용합니다. 두 API 모두 동일한 --api-url을 통해 접근합니다.

소스 IP로 Sandbox API 액세스 제한

control_plane_access.source_ip_allowlist를 사용하면 소스 주소를 기준으로 Sandbox API 요청을 제한할 수 있습니다. 클라이언트에서 관찰된 소스 주소가 IPv4 또는 IPv6 CIDR(classless inter-domain routing) 범위와 일치해야 합니다. 허용 목록은 인증, ID 및 액세스 관리(IAM) 권한, 조직 소유권 검사를 보완하는 기능입니다. 공유 API endpoint를 비공개로 전환하거나, 샌드박스가 노출하는 서비스로 직접 전송되는 트래픽을 제한하지는 않습니다. API 요청을 보내는 클라이언트에 대해 CoreWeave가 관찰하는 공용 이그레스 주소를 사용하세요. 표준 공용 NAT(network address translation) 라우팅을 사용하는 CoreWeave Kubernetes Service(CKS) 파드의 클라이언트라면 해당 Availability Zone의 NAT Egress 범위를 사용하세요. 회사 네트워크 또는 VPN(virtual private network)에 있는 클라이언트라면 조직의 공용 이그레스 범위를 사용하세요. 파드나 워크스테이션의 사설 주소로는 관찰된 소스 주소를 대신할 수 없습니다. 러너의 다른 정책 설정을 유지하면서 허용 목록을 추가하려면 다음 단계를 따르세요.
  1. 편집기에서 현재 정책을 엽니다.
    편집기 모드는 문서를 열 때 조회한 etag를 유지합니다. 따라서 그 사이에 다른 Admin이 정책을 업데이트한 경우, 해당 변경 사항을 덮어쓰지 않고 충돌이 발생합니다.
  2. 현재 정책의 최상위 수준에 다음 코드 조각을 추가합니다. 플레이스홀더를 클라이언트의 실제 공용 이그레스 CIDR로 바꾸세요. 클라이언트가 사용하지 않는 주소 체계는 생략하고, 나머지 정책 필드는 그대로 두세요.
  3. 전체 문서를 저장하고 편집기를 종료합니다. API에서 etag가 오래되었다고 보고하면 현재 정책을 다시 열고 변경 사항을 다시 적용한 다음 저장하세요.
허용 목록은 다음과 같이 동작합니다.
  • source_ip_allowlist가 없으면 소스 주소 제한이 적용되지 않습니다.
  • 허용 목록이 있으면 관찰된 소스 주소가 하나 이상의 CIDR과 일치해야 합니다.
  • 0.0.0.0/0은 모든 IPv4 주소를, ::/0은 모든 IPv6 주소를 허용합니다.
  • 입력은 정규화 전 기준으로 CIDR 256개, CIDR 텍스트 16KiB로 제한됩니다. API는 프리픽스를 정규화하고, 중복 항목을 제거하며, 더 넓은 범위의 항목에 포함되는 프리픽스를 제거합니다.
source_ip_allowlist: {}처럼 source_ip_allowlist가 있지만 비어 있으면 모든 공용 소스 주소가 거부됩니다. 제한을 해제하려면 허용 목록을 비우지 말고 필드 자체를 제거하세요.

정책 변경과 요청 동작

정책 캐시가 수렴되면 게이트웨이는 러너를 선택할 때, 그리고 기존 샌드박스에서 새 오퍼레이션을 수행하기 전에 업데이트된 허용 목록을 확인합니다. 여기에는 조회, 명령어, 파일 전송, 라이프사이클 오퍼레이션, 스냅샷, 스트리밍 요청이 포함됩니다. 새 스트림, 재개된 스트림, 다른 게이트웨이로 전달된 요청도 확인 대상입니다. 이미 수립된 스트림은 연결이 유지됩니다. 목록 및 검색 요청의 결과에서는 소스 주소 때문에 거부된 리소스가 제외됩니다. 게이트웨이가 필수 정책을 평가할 수 없으면 액세스 결정 없이 리소스를 반환하지 않고 요청이 실패합니다. 스트림 재개 요청을 제외한 나머지 요청에서는 API가 소스 거부와 정책 상태를 사용할 수 없는 경우를 구분합니다. 스트림을 재개할 때는 소스 주소 거부가 스트림 내 SESSION_NOT_FOUND 응답으로 나타날 수 있습니다. 액세스 정책을 사용할 수 없는 경우에는 이때도 Unavailable과 CWSANDBOX_ACCESS_POLICY_UNAVAILABLE이 반환됩니다. 생성 요청은 해당 소스 주소를 허용하는 다른 적합한 러너를 여전히 사용할 수 있습니다. 이 경우에도 인증, 리소스 적합성, 용량 확인은 그대로 적용됩니다.

제한 없는 소스 액세스 복원

정책 관리에는 Sandbox Admin 역할이 필요하며, 러너 자체의 소스 IP 허용 목록의 제한을 받지 않습니다. 액세스가 차단된 상태에서 복구하려면 앞에서 설명한 편집기 명령어로 현재 정책을 여세요. source_ip_allowlist 필드 또는 이 필드를 포함하는 control_plane_access 필드를 제거한 다음 전체 문서를 저장하세요. 이때 다른 정책 설정은 그대로 유지하세요. 정책 캐시가 수렴되고 나면 새 요청은 더 이상 소스 주소에 따라 제한되지 않습니다. 단, 인증 및 권한 부여는 계속 적용됩니다. 필드 유형과 검증 규칙은 정책 레퍼런스의 control_plane_access를 참조하세요.

새 러너에 대한 기본 정책 설정

CoreWeave는 호스팅 서비스에서 새 러너에 대한 기본 정책을 설정합니다. 다른 배포에서는 자체 기본 정책을 정의할 수 있습니다. 게이트웨이는 러너가 연결될 때 또는 v1 배치가 정책이 없는 러너를 처음 선택할 때 해당 정책을 기록합니다. 이미 정책이 있는 러너는 기존 정책을 그대로 유지합니다. 기본 정책은 게이트웨이 인프라 설정의 gateway.infraConfig.default_runner_policy에 있으며, 이를 변경하려면 게이트웨이를 재시작해야 합니다. 내장된 기본값은 없습니다. 설정이 없거나 null이면 아무것도 기록되지 않으며, 샌드박스는 여전히 CWSANDBOX_POOL_POLICY_NOT_CONFIGURED 오류와 함께 거부됩니다. 이 기능을 사용하기 전에 알아두어야 할 두 가지 동작이 있습니다.
  • 기본값은 연결이 아닌 스냅샷입니다. 러너에 한 번 적용되면 해당 정책은 일반 러너 정책이 됩니다. 이후 default_runner_policy를 변경해도 이미 정책이 있는 러너에는 반영되지 않습니다. 이러한 러너는 UpdateManagedRunner로 업데이트하세요.
  • 기본값이 유효하지 않으면 샌드박스를 생성할 수 없습니다. 게이트웨이는 시작 시 설정된 정책을 검증합니다. 검증에 실패해도 게이트웨이는 시작되지만, 샌드박스 생성은 CWSANDBOX_SERVERLESS_MISCONFIGURED 오류와 함께 실패합니다.

컴퓨트 제한

resources는 컨테이너가 요청할 수 있는 범위를 제한하고, 샌드박스가 아무것도 요청하지 않을 때 적용할 기본값을 제공합니다.
requireLimits를 true로 설정하면 각 컨테이너의 최종 할당에 제한이 반드시 포함되어야 합니다. 컨테이너에 리소스 할당이 지정되지 않은 경우, defaultCpu와 defaultMemory가 모두 0보다 큰 값으로 설정되어 있으면 이 기본값이 요청량과 제한을 모두 제공합니다. 기본값이 하나라도 빠져 있으면 이 요구 사항을 충족하지 못합니다. 이 설정은 제한과 요청량이 같아야 한다는 의미는 아닙니다. cpuCeiling과 memoryCeiling을 사용하여 샌드박스의 resolved total을 한도로 제한하세요. 이는 기본 레이어가 자체 컨테이너를 제공할 때 중요합니다. maxGpuCount는 각 컨테이너가 요청할 수 있는 GPU 수를 한도로 제한합니다. 생략하면 한도를 적용하지 않습니다. 0으로 설정하면 모든 GPU 요청을 거부하며, 이는 GPU-free pool을 표현하는 방법입니다. 한도를 초과하는 요청은 CWSANDBOX_RESOURCE_CEILING_EXCEEDED 오류로 실패합니다. maxGpuCount를 조직의 샌드박스당 최대 GPU 수보다 크게 설정하더라도 이 최댓값은 늘어나지 않습니다. 자세한 내용은 GPU 요청 작동 방식을 참조하세요.

이미지 제한

image는 샌드박스 이미지의 출처를 제한합니다. 빈 그룹은 모든 이미지를 허용합니다. [GITHUB-ORG]를 GitHub Container Registry 조직 이름 또는 사용자 이름으로 바꾸세요.

네트워크 액세스 제한

네트워크 제약 조건은 엔벨로프처럼 작동합니다. 샌드박스가 이그레스를 선언하면 정책은 해당 선언의 범위를 넓히지 않고 허용하거나 거부합니다. 샌드박스가 이그레스를 선언하지 않으면 정책은 자체 이그레스 기본값을 적용합니다. 단, 샌드박스가 deny_egress를 설정한 경우는 예외입니다. 두 설정은 별도의 작업을 수행합니다:
  • allowedEgress는 이그레스 허용 목록이며, 샌드박스가 생성될 때 확인됩니다. 비어 있지 않은 경우, 샌드박스가 선언하는 모든 규칙은 그 안에 맞아야 하며, 범위를 벗어나는 규칙은 거부되며 좁혀지지 않습니다. 비어 있으면 무엇이든 선언할 수 있습니다.
  • defaultEgress는 요청이 없을 때의 의미입니다. 샌드박스가 자체 이그레스를 선언하지 않고 deny_egress도 설정하지 않은 경우에만 적용됩니다. 어떤 선언이든 이를 완전히 대체합니다.
규칙은 하나의 대상을 지정합니다. cidr을 선택적 except carve-outs와 함께 사용하거나, 다른 샌드박스와의 관계를 위한 tenant, 레이블로 선택한 워크로드를 위한 selector, HTTPS 호스트 이름을 위한 httpsHostname, 또는 any를 사용합니다. 선택적 ports는 규칙을 더 좁힙니다. 호스트 이름 규칙은 TCP 443만 허용하며, 이를 지원하는 러너가 필요합니다. 이러한 규칙은 defaultEgress가 아닌 allowedEgress와 샌드박스 요청에 지정해야 합니다.
예시는 공개 인터넷을 허용하면서 비공개 공간과 인스턴스 메타데이터 주소를 제외하고, 샌드박스가 동일한 조직 내 다른 샌드박스에 액세스할 수 있도록 허용합니다. 아무것도 선언하지 않은 샌드박스는 동일 조직 액세스만 받습니다. 테넌트 범위는 TENANT_SCOPE_SAME_USER와 TENANT_SCOPE_SAME_ORG입니다. 세 번째 값인 TENANT_SCOPE_SANDBOX_NETWORK은 아직 지원되지 않으며, 이를 사용하는 이그레스 규칙은 거부됩니다. Ingress는 공개 범위가 CUSTOM인 포트에 대해 allowedIngress와 defaultIngress를 사용합니다. 허용 목록이 비어 있지 않으면 선언된 모든 ingress 규칙이 이 목록의 제한을 받습니다. 샌드박스가 ingress 규칙을 선언하지 않고 CUSTOM 포트를 노출하면 defaultIngress가 적용됩니다. 단, 샌드박스에 deny_ingress가 설정된 경우는 예외입니다. ingress 규칙을 명시적으로 선언하면 이 기본값을 대체합니다. Ingress 규칙은 cidr, tenant 또는 any를 허용하며, 이름 기반 소스는 허용하지 않습니다. 호스트 이름 기반 HTTPS 규칙을 거부하려면 denyHttpsHostnameRules를 설정하세요. 이 설정은 DNS 쿼리나 CIDR 규칙으로 허용된 HTTPS 트래픽은 차단하지 않습니다. 아웃바운드 UDP/TCP 포트 53을 차단하려면 dnsEgress를 DNS_EGRESS_MODE_DENY로 설정하세요. 이 값을 생략하면 플랫폼 리졸버에 대한 DNS 액세스가 허용됩니다. 플랫폼 DNS 및 저장소 액세스는 대상 규칙과 별도로 부여됩니다. 포함 규칙과 DNS 동작에 대한 자세한 내용은 네트워크 제약 조건을 참조하세요.

보안 태세 제한

security는 게스트 내부 권한과 샌드박스가 실행되는 격리 환경을 제어합니다.
allowedRuntimeClasses는 기본적으로 접근을 차단합니다. 목록이 비어 있거나 없으면 구체적인 런타임 클래스를 고정할 수 없으므로, 샌드박스는 목록에 명시적으로 지정된 클래스만 고정할 수 있습니다. 샌드박스가 클래스를 고정하지 않을 때 사용할 클래스를 선택하려면 defaultCpuRuntimeClass와 defaultGpuRuntimeClass를 설정하세요. 또는 runtimeClassMappings를 설정하여 이식 가능한 런타임 클래스를 실행 대상에 매핑할 수도 있습니다. 매핑 목록이 비어 있지 않으면 runtime_class_selection을 통해 선택할 수 있게 되며, 구체적인 runtime_class 고정은 거부됩니다. 매핑은 allowedRuntimeClasses, defaultCpuRuntimeClass, defaultGpuRuntimeClass와 함께 사용할 수 없습니다. 필드와 선택 규칙은 RuntimeClassMapping을 참조하세요.

인스턴스, 수명, 메타데이터, 볼륨 제한

나머지 그룹은 규모가 작습니다.

기본 레이어

제약 조건은 샌드박스가 요청할 수 있는 항목을 제한합니다. base 레이어는 요청 없이 모든 샌드박스가 받는 항목을 제공합니다: 기본값과 스케줄러, 노드 셀렉터, 톨러레이션, 이미지 풀 시크릿 같은 첨부 항목입니다. 그 형태는 러너 런타임에 따라 달라지며, Kubernetes 러너에서는 파드 사양 조각입니다. 기본값이 아닌 서비스 계정은 거부됩니다. 허용되는 필드와 제한 사항은 기본 레이어로 Admin 기본값 고정하기를 참조하세요.

다음 단계

마지막 수정일 2026년 11월 4일