> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 정책 개요

> 샌드박스에 클러스터를 관리하는 정책이 적용되는 방식과 정책으로 제한할 수 있는 항목을 설명합니다.

**정책**은 Admin이 클러스터의 샌드박스에 설정하는 거버넌스입니다. 모든 샌드박스가 상속하는 허용적인 기본값의 기본 계층과 샌드박스가 요청할 수 있는 범위를 제한하는 유형 지정 제한을 결합합니다. 하나의 정책이 클러스터를 관리하며, 정책은 필수이므로 보안 태세는 항상 플랫폼이 선택한 것이 아니라 Admin이 선언한 것입니다.

사용자는 정책을 선택하지 않으며, 정책이 존재한다는 사실을 알 필요도 없습니다. 사용자는 원하는 샌드박스를 정의합니다. 정책이 해당 샌드박스를 허용하면 샌드박스가 시작됩니다. 정책이 그 일부를 금지하면 요청이 거부되고, 오류에 거부된 항목이 명시됩니다.

<h2 id="how-a-sandbox-resolves-against-a-policy">
  샌드박스가 정책에 따라 해결되는 방법
</h2>

샌드박스는 두 단계로 해결됩니다.

1. **기본.** 정책은 런타임 기본값과 첨부 파일을 제공하며, 런타임 기본값, 정책 기본, 샌드박스 사양 순으로 병합됩니다. 개별 값에 대해서는 사용자의 사양이 우선합니다.
2. **제한.** 유형 지정 클램프는 완전히 해결된 사양에 대해 검증됩니다. 제한을 위반하는 사양은 거부되며, 조용히 재작성되지 않습니다.

순서가 생각보다 중요합니다. 제한은 제출된 사양이 아닌 해결된 사양을 검증하기 때문에, 기본에서 제공한 값도 사용자가 제공한 값과 동일한 조건으로 검사됩니다.

빈 정책은 유효하며 의미가 있습니다. 기본의 기본값과 제한 없이 완전히 허용적인 태세를 선언하지만, 플랫폼 수준의 안전 게이트는 여전히 적용됩니다.

<h2 id="what-a-policy-can-constrain">
  정책이 제한할 수 있는 항목
</h2>

제한은 관리 대상에 따라 그룹화됩니다. 모든 그룹은 선택 사항이며, 설정되지 않은 그룹은 해당 종류의 제한을 부과하지 않습니다.

| 그룹 | 관리 대상 |
| - | - |
| `resources` | CPU 및 메모리 최소값, 최대값, 기본값, 상한, 그리고 제한이 필요한지 여부. |
| `image` | 샌드박스가 실행할 수 있는 레지스트리와 이미지. |
| `network` | 샌드박스가 요청할 수 있는 egress와 ingress, 그리고 요청이 없을 때 받는 것. |
| `security` | 권한 있는 컨테이너, Linux 기능, seccomp 프로필, 호스트 namespace, 런타임 클래스. |
| `instance` | 샌드박스가 배치될 수 있는 노드 인스턴스 유형. |
| `lifecycle` | 샌드박스가 살아있을 수 있는 기간. |
| `metadata` | 거부되는 주석 접두사. |
| `volumes` | 허용되는 저장소 미디어와 최대 볼륨 크기. |

네트워크 제한은 샌드박스가 요청할 수 있는 액세스의 허용 목록을 정의합니다. 샌드박스는 필요한 액세스를 선언하고, 정책은 클러스터가 허용하는 것과 비교하여 해당 요청을 검증하며, 정책은 별도로 요청이 없을 때의 의미를 정의합니다. 액세스를 선언하는 것은 샌드박스가 스스로를 제한하는 방법이기도 하며, 신뢰할 수 없는 에이전트를 실행하고 정책이 허용하는 것보다 범위를 좁히고자 할 때 유용합니다.

<h2 id="what-changed-from-profiles">
  프로필에서 변경된 사항
</h2>

정책이 프로필을 대체합니다. 단순히 이름만 바뀐 것이 아니므로, 마이그레이션하기 전에 다음 두 가지 변경 사항을 이해해 두는 것이 좋습니다.

**사용자가 더 이상 아무것도 선택하지 않습니다.** 프로필 방식에서는 사용자가 이름으로 프로필을 선택했기 때문에, 어떤 프로필이 있는지 알아야 했고 이를 조회할 권한도 필요했습니다. 적합한 프로필이 없으면 사용자는 Admin에게 프로필 작성을 요청해야 했습니다. 정책 방식에서는 사용자가 원하는 샌드박스를 선언하면, 플랫폼이 이를 허용하거나 무엇을 거부했는지 설명합니다.

**적용 방향이 반대입니다.** 프로필은 샌드박스 사양의 값을 덮어썼습니다. 정책은 그 반대로, 사용자의 사양이 우선하고 정책은 그 결과에 제한을 가합니다. 프로필이 알리지 않고 대체하던 설정은 이제 그대로 적용되거나, 이유와 함께 거부됩니다.

<Warning>
  적용 방향이 뒤바뀐 것은 단순한 이름 변경이 아니라 동작 변경입니다. 프로필이 알리지 않고 변경했을 요청이 이제는 즉시 거부될 수 있습니다. 기존 프로필 설정을 마이그레이션하기 전에 제한 그룹과 비교하여 검토하세요.
</Warning>

정책은 클러스터 단위로 설정됩니다. 팀별 또는 사용자별로 세분화할 수 없으므로, 클러스터의 모든 사용자에게 동일한 정책이 적용됩니다.

<h2 id="where-reusable-configuration-lives">
  재사용 가능한 설정이 저장되는 위치
</h2>

프로필은 거버넌스 외에도 두 번째 역할을 했습니다. 팀당 또는 애플리케이션당 하나씩 옵션 세트를 저장하고 재사용할 수 있는 편리한 방법이었습니다.

이제 그 역할은 샌드박스 템플릿이 맡게 되었으며, 샌드박스 템플릿은 샌드박스를 생성할 때 재정의할 수 있는 재사용 가능한 부분 샌드박스 명세를 담고 있습니다. 템플릿에는 권한이 없습니다. 시작점일 뿐이며, 정책만이 무엇이든 강제 적용하는 유일한 요소로 남습니다. 워크플로와 전체 예제 템플릿은 [샌드박스 템플릿](/ko/products/sandboxes/profiles/templates)을 참조하세요.

<h2 id="see-also">
  참고
</h2>

* [Sandboxes architecture](/ko/products/sandboxes/architecture): 샌드박스를 구축하는 리소스와 모든 요청을 중개하는 게이트웨이입니다.
* [Deploy and manage a runner](/ko/products/sandboxes/operations/managed-runners): 러너의 라이프사이클과 러너가 전달하는 설정입니다.
* [Control plane API overview](/ko/products/sandboxes/reference/control-plane-api): 인증, 필드 마스크, 하트비트 및 엔드포인트 계약입니다.