Policy examples

이 페이지에는 일반적인 클러스터 보안 태세에 맞춘 전체 정책 다섯 가지가 정리되어 있어, 정책을 처음부터 구축하지 않고 바로 작동하는 문서에서 시작할 수 있습니다. 클러스터에는 정책이 하나만 적용되므로, 이 예시들은 서로 조합해서 쓰는 세트가 아니라 각각의 대안입니다. 클러스터의 용도에 맞는 보안 태세를 선택한 다음 필요에 맞게 조정하세요. 각 예시는 전체 정책 문서입니다. cwic sandbox runner policy edit [RUNNER-ID] -f policy.json 명령으로 적용하거나, 러너 업데이트 요청의 policy 필드로 전송하세요. [RUNNER-ID]는 정책을 편집하려는 러너의 ID로 바꾸고, 이미지 레지스트리 예시의 [GITHUB-ORG]는 GitHub Container Registry 조직 이름 또는 사용자 이름으로 바꾸세요. 필드별 워크스루는 샌드박스 정책 설정하기를 참조하세요.

GPU 데이터 과학 클러스터

사용자별 장기 작업을 위한 클러스터로, 넉넉한 컴퓨팅 리소스, GPU 노드, 데이터셋과 패키지를 다운로드하기 위한 인터넷 액세스를 제공하며, 인스턴스 메타데이터 엔드포인트는 액세스 대상에서 제외됩니다.

policy.json

{
  "displayName": "Data science, GPU",
  "constraints": {
    "resources": {
      "defaultCpu": "4",
      "defaultMemory": "16Gi",
      "maxCpu": "16",
      "maxMemory": "128Gi",
      "maxGpuCount": "2",
      "requireLimits": true
    },
    "instance": { "allowedInstanceTypes": ["h100"] },
    "image": { "allowedRegistries": ["ghcr.io/[GITHUB-ORG]"] },
    "network": {
      "allowedEgress": [
        { "cidr": { "cidr": "0.0.0.0/0", "except": ["169.254.169.254/32"] } }
      ],
      "defaultEgress": [
        { "cidr": { "cidr": "0.0.0.0/0", "except": ["169.254.169.254/32"] } }
      ]
    },
    "security": {
      "allowPrivileged": false,
      "allowedRuntimeClasses": ["kata-qemu", "cw-kata-nvidia-gpu"],
      "defaultCpuRuntimeClass": "kata-qemu",
      "defaultGpuRuntimeClass": "cw-kata-nvidia-gpu",
      "allowedSeccompProfiles": ["RuntimeDefault"]
    },
    "lifecycle": { "defaultLifetimeSeconds": 86400 }
  }
}

allowedRuntimeClasses는 페일 클로즈드(fail-closed) 방식으로 동작하므로 두 runtime 클래스를 모두 나열합니다. 샌드박스는 명시된 클래스만 고정할 수 있으며, 아무 클래스도 고정하지 않으면 두 기본값에 따라 적용될 클래스가 결정됩니다.

허용 목록 기반 egress가 적용된 공유 에이전트 클러스터

에이전트 워크로드를 위한 멀티테넌트 클러스터입니다. 에이전트는 정해진 업스트림과 조직 내 다른 에이전트에만 연결할 수 있으며, 그 외에는 연결할 수 없습니다.

policy.json

{
  "displayName": "Agents, allowlisted egress",
  "constraints": {
    "resources": {
      "defaultCpu": "1",
      "defaultMemory": "2Gi",
      "maxCpu": "4",
      "maxMemory": "8Gi",
      "requireLimits": true
    },
    "network": {
      "allowedEgress": [
        { "cidr": { "cidr": "140.82.112.0/20" }, "ports": [{ "port": 443 }] },
        { "cidr": { "cidr": "151.101.0.0/16" }, "ports": [{ "port": 443 }] },
        { "tenant": "TENANT_SCOPE_SAME_ORG" }
      ],
      "defaultEgress": [
        { "cidr": { "cidr": "140.82.112.0/20" }, "ports": [{ "port": 443 }] }
      ]
    },
    "security": {
      "allowPrivileged": false,
      "allowedRuntimeClasses": ["kata-qemu"],
      "defaultCpuRuntimeClass": "kata-qemu",
      "allowedSeccompProfiles": ["RuntimeDefault"]
    },
    "lifecycle": { "defaultLifetimeSeconds": 3600 }
  }
}

아무것도 선언하지 않은 샌드박스에는 첫 번째 CIDR만 적용됩니다. 조직 내 다른 샌드박스에 연결해야 하는 샌드박스는 테넌트 규칙을 직접 선언하며, 해당 규칙이 정책 경계에 부합하므로 정책에서 이를 허용합니다.

임시 CI 클러스터

수명이 짧고, 규모가 작으며, 범위가 좁습니다. 샌드박스는 테스트 실행 동안만 존재합니다.

policy.json

{
  "displayName": "CI",
  "constraints": {
    "resources": {
      "defaultCpu": "250m",
      "defaultMemory": "512Mi",
      "maxCpu": "2",
      "maxMemory": "4Gi",
      "requireLimits": true
    },
    "image": { "allowedRegistries": ["ghcr.io/[GITHUB-ORG]"] },
    "network": {
      "allowedEgress": [
        { "cidr": { "cidr": "140.82.112.0/20" }, "ports": [{ "port": 443 }] }
      ],
      "defaultEgress": [
        { "cidr": { "cidr": "140.82.112.0/20" }, "ports": [{ "port": 443 }] }
      ]
    },
    "security": {
      "allowPrivileged": false,
      "allowedRuntimeClasses": ["gvisor"],
      "defaultCpuRuntimeClass": "gvisor",
      "allowedSeccompProfiles": ["RuntimeDefault"]
    },
    "lifecycle": { "defaultLifetimeSeconds": 900 },
    "volumes": { "allowedMedia": ["STORAGE_MEDIUM_DISK"], "maxSize": "10Gi" }
  }
}

15분이라는 기본값이 유용한 이유는 아무것도 선언하지 않은 CI 작업이 빠르게 자동 종료되기 때문입니다. 이 정책에는 실행 시간 한도가 없습니다. 플랫폼의 최대 실행 시간인 30일을 초과하는 요청은 생성 시 거부되며, 그 이하는 모두 허용됩니다. 따라서 작업별로 엄격한 실행 시간 제한이 필요한 경우 생성 요청에 max_lifetime_seconds를 설정하세요.

기본 이그레스가 없는 VM 격리 실행

이 정책은 VM 격리를 요구하며 기본 이그레스 규칙을 제공하지 않습니다. UDP/TCP 포트 53의 아웃바운드 DNS 트래픽은 차단하지만, allowedEgress가 비어 있으므로 샌드박스가 다른 이그레스를 선언하는 것은 허용됩니다.

policy.json

{
  "displayName": "VM-isolated execution",
  "constraints": {
    "resources": {
      "defaultCpu": "500m",
      "defaultMemory": "512Mi",
      "maxCpu": "2",
      "maxMemory": "2Gi",
      "requireLimits": true
    },
    "image": { "allowedImages": ["ghcr.io/[GITHUB-ORG]/sandbox-base:pinned"] },
    "network": {
      "allowedEgress": [],
      "defaultEgress": [],
      "dnsEgress": "DNS_EGRESS_MODE_DENY"
    },
    "security": {
      "allowPrivileged": false,
      "allowedCapabilities": [],
      "allowedRuntimeClasses": ["kata-qemu"],
      "defaultCpuRuntimeClass": "kata-qemu",
      "allowedSeccompProfiles": ["RuntimeDefault"]
    },
    "lifecycle": { "defaultLifetimeSeconds": 300 },
    "metadata": { "maxAnnotationCount": 0 },
    "volumes": { "allowedMedia": ["STORAGE_MEDIUM_DISK"], "maxSize": "5Gi" }
  }
}

이 정책은 완전한 네트워크 격리를 강제 적용하지 않습니다. allowedEgress 목록이 비어 있어도 명시적인 대상 규칙은 허용되며, 플랫폼 저장소 액세스는 별도로 부여됩니다. dnsEgress는 아웃바운드 53번 포트를 차단하지만, HTTPS 등 허용된 다른 전송 방식을 통한 DNS는 차단하지 않습니다.

allowedImages는 레지스트리가 아닌 하나의 이미지를 고정하므로, 샌드박스는 신뢰할 수 있는 레지스트리에서 임의의 이미지를 선택할 수 없습니다.

내부 워커 클러스터

조직 내 다른 샌드박스가 서비스를 통해 연결하는 장기 실행 백그라운드 워커로, 타사 API 호출을 위한 아웃바운드 액세스를 제공합니다.

policy.json

{
  "displayName": "Internal workers",
  "constraints": {
    "resources": {
      "defaultCpu": "1",
      "defaultMemory": "2Gi",
      "maxCpu": "8",
      "maxMemory": "16Gi",
      "requireLimits": true
    },
    "image": { "allowedRegistries": ["ghcr.io/[GITHUB-ORG]"] },
    "network": {
      "allowedEgress": [
        { "cidr": { "cidr": "0.0.0.0/0", "except": ["10.0.0.0/8", "169.254.169.254/32"] } },
        { "tenant": "TENANT_SCOPE_SAME_ORG" }
      ],
      "defaultEgress": [{ "tenant": "TENANT_SCOPE_SAME_ORG" }]
    },
    "security": {
      "allowPrivileged": false,
      "allowedRuntimeClasses": ["kata-qemu"],
      "defaultCpuRuntimeClass": "kata-qemu",
      "allowedSeccompProfiles": ["RuntimeDefault"]
    },
    "lifecycle": { "defaultLifetimeSeconds": 604800 }
  }
}

이그레스는 워커가 퍼블릭 인터넷과 조직 내 형제 샌드박스에 도달할 수 있도록 범위가 지정되며, 비공개 주소 공간과 메타데이터 주소는 제외됩니다.

이 예제에서는 이그레스만 설정합니다. 공개 범위가 CUSTOM인 포트에 대한 인바운드 액세스를 제한하려면 allowedIngress를 추가하고, 필요한 경우 defaultIngress도 추가하세요. 자세한 내용은 네트워크 액세스 제한을 참조하세요.

기본 계층으로 관리자 기본값 고정하기

위의 모든 정책에는 base 조각도 포함할 수 있습니다. 이는 샌드박스의 요청 내용과 관계없이 러너의 모든 샌드박스에 적용되는 관리자 연결 설정입니다. 이 내부 워커 정책 변형은 모든 샌드박스에 노드 선택, 비공개 레지스트리의 이미지 가져오기 시크릿, 비용 귀속 레이블을 고정합니다.

policy.json

{
  "displayName": "Internal workers, pinned scheduling",
  "base": {
    "spec": {
      "nodeSelector": { "workload": "sandbox" },
      "tolerations": [
        { "key": "sandbox-only", "operator": "Exists", "effect": "NoSchedule" }
      ],
      "imagePullSecrets": [{ "name": "regcred" }]
    },
    "metadata": {
      "labels": { "cost-center": "sandboxes" }
    }
  },
  "constraints": {
    "resources": {
      "defaultCpu": "1",
      "defaultMemory": "2Gi",
      "maxCpu": "8",
      "maxMemory": "16Gi",
      "requireLimits": true
    },
    "image": { "allowedRegistries": ["ghcr.io/[GITHUB-ORG]"] },
    "security": {
      "allowPrivileged": false,
      "allowedRuntimeClasses": ["kata-qemu"],
      "defaultCpuRuntimeClass": "kata-qemu",
      "allowedSeccompProfiles": ["RuntimeDefault"]
    },
    "lifecycle": { "defaultLifetimeSeconds": 604800 }
  }
}

base 조각은 주변의 제약 조건 필드와 달리 camelCase 키를 사용하는 Kubernetes 파드 사양의 하위 집합이며, 알 수 없는 키는 거부됩니다. 스케줄링 및 런타임 구성만 허용됩니다. 허용되는 항목은 nodeSelector, tolerations, imagePullSecrets, volumes, topologySpreadConstraints, hostAliases, DNS 설정, name, env, envFrom, volumeMounts, volumeDevices로 제한된 단일 containers 항목, 파드 레이블 및 주석입니다. 보안에 민감한 필드는 거부됩니다. 여기에는 securityContext, runtimeClassName, initContainers, affinity, 호스트 namespace, hostPath 볼륨, 기본값이 아닌 서비스 계정, 러너가 소유권을 유지하는 namespace가 포함됩니다. 실행 시간, 이미지, egress처럼 유형이 지정된 설정은 base가 아닌 constraints에 속합니다. CKS 클러스터에서는 템플릿 연결 항목이 템플릿별로 이 조각을 구체화합니다. imagePullSecrets와 tolerations는 합쳐진 후 중복이 제거되고, 다른 목록은 기존 목록에 추가되며, 맵 키는 키별로 재정의되고, 동일한 이름이 충돌하면 생성이 거부됩니다. base의 현재 강제 적용 상태는 기본 계층을 참조하세요.

클러스터별로 보안 태세 다르게 구성하기

정책은 클러스터에 속하므로, 보안 태세를 다르게 하려면 한 클러스터에 여러 문서를 두는 대신 클러스터를 따로 구성해야 합니다. 개방형 데이터 과학 환경과 엄격하게 제한된 실행 환경이 모두 필요한 팀이라면 클러스터 두 개를 운영하고 각 클러스터에 알맞은 정책을 적용합니다. 리전별로 한 가지 항목만 다르게 구성하려면 리전별 값만 바꾼 동일한 정책을 각 클러스터에 적용하세요. 공유하거나 상속할 수 있는 정책 문서는 없으므로, 기준이 되는 원본은 버전 관리 시스템에 보관하고 클러스터마다 적용하세요.

참고 자료

샌드박스 정책 설정: 모든 제약 조건 그룹과 이 예시에서 사용하는 필드.
정책 개요: 샌드박스에 정책이 적용되는 방식.
에이전트형 RL 트레이닝: 보상 함수와 멀티턴 에이전트 롤아웃 및 실행 가능한 Python 코드.
러너 배포 및 관리: 나머지 러너 설정.

샌드박스

샌드박스 사용하기

샌드박스 관리

레퍼런스

GPU 데이터 과학 클러스터

허용 목록 기반 egress가 적용된 공유 에이전트 클러스터

임시 CI 클러스터

기본 이그레스가 없는 VM 격리 실행

내부 워커 클러스터

기본 계층으로 관리자 기본값 고정하기

클러스터별로 보안 태세 다르게 구성하기

참고 자료

​GPU 데이터 과학 클러스터

​허용 목록 기반 egress가 적용된 공유 에이전트 클러스터

​임시 CI 클러스터

​기본 이그레스가 없는 VM 격리 실행

​내부 워커 클러스터

​기본 계층으로 관리자 기본값 고정하기

​클러스터별로 보안 태세 다르게 구성하기

​참고 자료

GPU 데이터 과학 클러스터

허용 목록 기반 egress가 적용된 공유 에이전트 클러스터

임시 CI 클러스터

기본 이그레스가 없는 VM 격리 실행

내부 워커 클러스터

기본 계층으로 관리자 기본값 고정하기

클러스터별로 보안 태세 다르게 구성하기

참고 자료