샌드박스가 정책에 따라 해결되는 방법
샌드박스는 두 단계로 해결됩니다.- 기본. 정책은 런타임 기본값과 첨부 파일을 제공하며, 런타임 기본값, 정책 기본, 샌드박스 사양 순으로 병합됩니다. 개별 값에 대해서는 사용자의 사양이 우선합니다.
- 제약 조건. 유형 지정 클램프는 완전히 해결된 사양에 대해 검증됩니다. 제약 조건을 위반하는 사양은 거부되며, 조용히 재작성되지 않습니다.
runtime_class를 고정할 수 없습니다. SecurityConstraints를 참조하세요.
정책이 제한할 수 있는 항목
제약 조건은 관리 대상에 따라 그룹화됩니다. 모든 그룹은 선택 사항입니다. 그룹을 생략하면 해당 종류의 명시적인 제약 조건이 추가되지 않지만, 플랫폼 안전 게이트와 런타임 클래스 제한은 그대로 적용됩니다.
네트워크 제약 조건은 샌드박스가 요청할 수 있는 액세스의 허용 목록을 정의합니다. 샌드박스는 필요한 액세스를 선언하고, 정책은 클러스터가 허용하는 것과 비교하여 해당 요청을 검증하며, 정책은 별도로 요청이 없을 때의 의미를 정의합니다. 액세스를 선언하는 것은 샌드박스가 스스로를 제한하는 방법이기도 하며, 신뢰할 수 없는 에이전트를 실행하고 정책이 허용하는 것보다 범위를 좁히고자 할 때 유용합니다.
소스 IP 액세스 제어
정책에서control_plane_access.source_ip_allowlist를 사용하면 호출자의 소스 주소를 기준으로 Sandbox API 요청을 제한할 수도 있습니다. 게이트웨이는 생성 시점의 기본값 및 제약 조건과는 별개로, 러너를 선택할 때와 기존 샌드박스에서 새 오퍼레이션을 수행하기 전에 이 제어를 평가합니다.
소스 IP 제한은 인증 및 권한 부여를 보완하는 수단입니다. 샌드박스에서 노출된 서비스로 직접 전송되는 연결에는 적용되지 않습니다. 설정 및 복구 방법은 소스 IP로 Sandbox API 액세스 제한을 참조하세요.
프로필에서 변경된 사항
정책이 프로필을 대체합니다. 단순히 이름만 바뀐 것이 아니므로, 마이그레이션하기 전에 다음 두 가지 변경 사항을 이해해 두는 것이 좋습니다. 사용자가 더 이상 아무것도 선택하지 않습니다. 프로필 방식에서는 사용자가 이름으로 프로필을 선택했기 때문에, 어떤 프로필이 있는지 알아야 했고 이를 조회할 권한도 필요했습니다. 적합한 프로필이 없으면 사용자는 Admin에게 프로필 작성을 요청해야 했습니다. 정책 방식에서는 사용자가 원하는 샌드박스를 선언하면, 플랫폼이 이를 허용하거나 무엇을 거부했는지 설명합니다. 적용 방향이 반대입니다. 프로필은 샌드박스 사양의 값을 덮어썼습니다. 정책은 그 반대로, 사용자의 사양이 우선하고 정책은 그 결과에 제한을 가합니다. 프로필이 알리지 않고 대체하던 설정은 이제 그대로 적용되거나, 이유와 함께 거부됩니다. 정책은 클러스터 단위로 설정됩니다. 팀별 또는 사용자별로 세분화할 수 없으므로, 클러스터의 모든 사용자에게 동일한 정책이 적용됩니다.재사용 가능한 설정이 저장되는 위치
프로필은 거버넌스 외에도 두 번째 역할을 했습니다. 팀당 또는 애플리케이션당 하나씩 옵션 세트를 저장하고 재사용할 수 있는 편리한 방법이었습니다. 이제 그 역할은 샌드박스 템플릿이 맡게 되었으며, 샌드박스 템플릿은 샌드박스를 생성할 때 재정의할 수 있는 재사용 가능한 부분 샌드박스 명세를 담고 있습니다. 템플릿에는 권한이 없습니다. 시작점일 뿐이며, 정책만이 무엇이든 강제 적용하는 유일한 요소로 남습니다. 워크플로와 전체 예제 템플릿은 샌드박스 템플릿을 참조하세요.참고
- Sandboxes architecture: 샌드박스를 구축하는 리소스와 모든 요청을 중개하는 게이트웨이입니다.
- Deploy and manage a runner: 러너의 라이프사이클과 러너가 전달하는 설정입니다.
- Control plane API overview: 인증, 필드 마스크, 하트비트 및 엔드포인트 계약입니다.