MXC 정책 예시

다음 예제에서는 워크로드 요구 사항이 MXC 리소스 권한으로 변환되는 방법을 보여 줍니다. C#, TypeScript 또는 Rust 빠른 시작으로 시작한 다음, 워크로드에 맞게 구성을 조정할 수 있습니다.

아래 JSON은 MXC 스키마에 대한 원시 1.0.0 셰이프를 사용합니다. 전체 구성에는 버전 및 명령이 포함됩니다. 조각으로 레이블이 지정된 섹션은 기존 구성에 통합되어야 합니다. C#, TypeScript 또는 Rust로 작성할 때는 특정 스키마 버전이 필요하지 않은 해당하는 V1 SDK 형식을 사용하세요.

다음은 Windows 예입니다. 경로를 호스트의 기존 리소스로 바꾸고, 추가 도구 종속성을 의도적으로 부여하고, SDK 릴리스 및 백 엔드가 선택한 컨트롤을 지원하는지 확인합니다.

리포지토리 범위의 도구 실행

이 전체 구성은 퀵스타트와 동일한 입력 읽기/출력 쓰기 패턴을 사용합니다. C:\src\mxc-output와 C:\src\my-app\input.txt 디렉터리를 만들고 그 후 실행하세요. 이 명령은 원본 디렉터리를 읽고 출력 디렉터리에 쓸 수 있지만 원본 디렉터리에는 쓸 수 없고 네트워크 또는 UI를 사용할 수는 없습니다.

{
  "$schema": "https://raw.githubusercontent.com/microsoft/mxc/main/schemas/stable/mxc-config.schema.1.0.0.json",
  "version": "1.0.0",
  "containment": "process",
  "process": {
    "commandLine": "C:\\Windows\\System32\\cmd.exe /d /c type input.txt > C:\\src\\mxc-output\\result.txt",
    "cwd": "C:\\src\\my-app",
    "env": [
      "SystemRoot=C:\\Windows",
      "LOCALAPPDATA=C:\\src\\mxc-output",
      "TEMP=C:\\src\\mxc-output",
      "TMP=C:\\src\\mxc-output"
    ],
    "timeout": 30000
  },
  "filesystem": {
    "readonlyPaths": ["C:\\src\\my-app", "C:\\Windows\\System32\\cmd.exe"],
    "readwritePaths": ["C:\\src\\mxc-output"]
  },
  "network": {
    "egress": { "default": "deny" },
    "ingress": { "default": "deny", "hostLoopback": "deny" }
  },
  "ui": {
    "disable": true,
    "clipboard": "none",
    "injection": false
  }
}

이 예제에서는 Windows가 C:\Windows에 설치되어 있다고 가정합니다. 호스트의 실제 시스템 디렉터리를 사용하십시오. 명시적 env 목록이 있는 Windows ProcessContainer 요청에는 SystemRoot와 LOCALAPPDATA가 모두 포함되어야 합니다. 명령을 빌드 또는 분석 도구로 바꾸면 전체 리포지토리에 쓰기 권한을 부여하는 대신 해당 도구가 캐시 및 임시 파일에 대해 전용 쓰기 가능한 디렉터리를 사용하도록 구성합니다.

더 광범위한 권한 부여 범위 내에서 자격 증명 보호

위의 구성은 C:\src\my-app에 대한 읽기 권한을 부여합니다. 해당 디렉터리에 환경 파일 또는 secrets 디렉터리가 포함된 경우 읽기 전용 및 읽기-쓰기 목록을 유지하면서, 기존 filesystem 섹션 내에 이 조각을 추가합니다.

{
  "deniedPaths": [
    "C:\\src\\my-app\\.env",
    "C:\\src\\my-app\\secrets"
  ]
}

이러한 거부된 경로는 허용된 원본 디렉터리 내에 있습니다. 관련 없는 리포지토리 및 사용자 프로필 디렉터리를 권한 범위 외부에 유지합니다.

가능한 경우 권한이 부여된 트리 밖에 시크릿을 두십시오. 선택한 백 엔드에서 겹치는 권한 부여 및 거부를 확인합니다. 일부 탑재된 디렉터리 백 엔드는 중첩된 거부 규칙을 적용하는 대신 이를 거부합니다.

IP 범위에 대한 직접 액세스 허용

이 구성 조각은 network 섹션을 대체합니다. 승인된 CIDR 범위로의 아웃바운드 TCP 포트 443 트래픽을 허용하고 다른 송신, 수신 및 호스트 루프백 액세스를 거부합니다. 워크로드에서 이를 수락하지 말고 신뢰할 수 있는 구성에서 승인된 범위를 제공합니다.

{
  "network": {
    "egress": {
      "default": "deny",
      "allow": [
        {
          "to": [{ "cidr": "192.0.2.0/24" }],
          "ports": [{ "protocol": "tcp", "port": 443 }]
        }
      ]
    },
    "ingress": { "default": "deny", "hostLoopback": "deny" }
  }
}

192.0.2.0/24 은 설명서 전용 범위입니다. 의도한 서비스의 허용된 주소로 바꿉니다. 규칙은 해당 포트에서 TCP를 허용하며, HTTPS만, 하나의 호스트 이름만 또는 하나의 애플리케이션 서비스만 허용하는 것은 아닙니다. 직접 호스트 이름 확인에는 별도의 DNS 규칙이 필요할 수 있습니다.

이 예제에는 직접 아웃바운드 규칙을 지원하는 백 엔드 및 호스트가 필요합니다. 그것을 runtimeConfig.networkProxy와 결합하지 마세요. 호스트 이름 기반 HTTP(S) 결정의 경우 지원되는 프록시 기반 구성을 대신 사용하세요.

애플리케이션에서 제공하는 프록시 사용

호스트 앱은 워크로드를 시작하기 전에 프록시를 시작해야 합니다. 이 예제에서는 기존 프록시를 사용하도록 MXC를 구성합니다. 프록시의 요청 처리 정책을 구현하거나 시작하거나 승인하지는 않습니다.

다음 구성 조각은 지원되는 OS 범위 프록시 적용 경로를 사용하여 Windows ProcessContainer를 대상으로 합니다. 명령, 파일 시스템 권한, 시간 제한 및 UI 제한을 유지하면서 전체 구성에 병합합니다. 엔드포인트 및 피어 이름을 실행 중인 프록시의 엔드포인트와 피어 이름으로 바꾸십시오.

{
  "containment": "processcontainer",
  "network": {
    "egress": { "default": "deny" },
    "ingress": { "default": "allow", "hostLoopback": "deny" }
  },
  "runtimeConfig": {
    "networkProxy": "http://127.0.0.1:8080"
  },
  "processContainer": {
    "network": {
      "allowedProxyPeer": "<package-family-name-or-appcontainer-profile-name>"
    }
  }
}

allowedProxyPeer 는 프록시의 설치된 패키지 또는 패키지되지 않은 AppContainer 프로필을 식별합니다. 프록시는 구성된 루프백 주소 및 포트에서 수신 대기하고 문서화된 Windows 필수 조건을 충족해야 합니다. MXC는 URL에서 해당 식별 정보를 유추하지 않습니다.

중요합니다

이 Windows 매핑에는 ingress.default: "allow"이 필요하며, 이는 프라이빗 네트워크 서버 트래픽도 허용합니다. hostLoopback: "deny"는 구성된 프록시 피어가 도달 가능한 경우 일반 호스트 루프백 액세스를 차단된 상태로 유지합니다. 이 예제는 모든 인바운드 트래픽이 거부되는 구성이 아닙니다.

직접 인터넷 액세스는 강제 적용 경로에서 거부된 상태로 유지됩니다. 프록시는 어떤 HTTP(S) 요청을 전달할지 제어합니다. AppContainer ID가 없는 일반 패키지되지 않은 호스트 프록시에는 더 광범위한 별도의 호환성 구성이 필요합니다. allowedProxyPeer를 제거하지 말고 동일한 제한 사항이 유지된다고 가정하지 마세요.

해당 SDK 형식을 사용하고 프록시 전용 액세스에 의존하기 전에 지원을 확인합니다. Windows 필수 구성 요소는 ProcessContainer proxy deployment choices를, 다른 백엔드의 경우 directional networking을 참조하세요.

광범위한 UI 액세스 없이 표시 가능한 도구 허용

표시되는 창 및 클립보드 입력이 필요한 워크로드의 경우 이 구성 조각이 ui를 대체합니다. 창 및 클립보드 읽기를 허용하지만 클립보드 쓰기 또는 가상 키보드 및 포인터 입력은 허용되지 않습니다.

{
  "ui": {
    "disable": false,
    "clipboard": "read",
    "injection": false
  }
}

V1 SDK ContainerRequest에서 해당 UI 속성은 disable, clipboard및 allowInputInjection. 워크로드에 필요한 경우에만 클립보드 읽기를 부여합니다. 런타임 UI 지원을 확인하고 각 대상 호스트에 필요한 제한을 테스트합니다.

상태 인식 샌드박스 재사용

명령이 환경을 공유해야 하는 경우 상태 인식 실행을 사용합니다. 인스턴스를 프로비전하고 시작한 다음, 명령을 실행한 후, 완료되면 중지하고 프로비전을 해제합니다. 성공뿐만 아니라 실패 및 취소 후에도 정리가 수행되도록 하세요.

상태 인식 호출은 위와 같은 전체 원샷 구성이 아니라 각 명령에 대해 단계별 ProvisionRequest 및 각 명령에 대한 별도의 ExecutionRequest를 사용합니다. 프로비저닝은 불투명한 값 ContainerId을 반환하고 변경되지 않은 상태로 이후 단계에 전달합니다. provisionContainer를 .NET에서, provision_container와 같은 TypeScript 수명 주기 함수를, 또는 IsolationSession이나 WSLc처럼 V1 수명 주기 API에서 지원하는 백엔드와 함께 MxcLifecycle와 같은 Rust v1::container 함수를 사용합니다. 정확한 요구 사항은 수명 주기 개념, MXC 컨테이너 수명 주기 및 .NET, TypeScript 또는 Rust SDK 가이드를 참조하세요.

선택하기 전에 각 수명 주기 백엔드가 무엇을 강제하는지 확인하세요. IsolationSession은 워크로드의 사용자와 세션을 구분하지만 MXC 파일 시스템, UI 또는 네트워크 필터링을 적용하지 않으며 해당 요청은 모든 네트워크 트래픽을 명시적으로 허용해야 합니다. WSLc 네트워킹은 대상별 규칙 없이 완전히 격리되거나 완전히 브리지 모드로 연결됩니다. 자세한 내용은 포함 유형 선택 및 백 엔드 선택 및 설정을 참조하세요.

예제를 검증하세요

각 조정된 정책에 대해 의도한 동작과 오용 시도를 모두 테스트합니다.

필요한 입력을 읽고 필요한 출력을 쓸 수 있는지 확인합니다.
자격 증명 및 관련 없는 파일에 액세스할 수 없는지 확인합니다.
직접, 로컬 네트워크, 루프백 및 인바운드 연결이 정책과 일치하는지 확인합니다.
프록시 기반 액세스의 경우 승인된 요청이 성공하고 직접 인터넷 시도가 실패했는지 확인합니다.
클립보드, 입력 삽입 및 표시되는 창이 UI 정책과 일치하는지 확인합니다.
성공, 실패 및 취소 후 시간 제한 및 정리가 작동하는지 확인합니다.

학습 모드를 사용하여 누락된 액세스 권한을 조사합니다. 샘플 실행에서 관찰되는 모든 리소스를 자동으로 부여하지 마세요.

피드백

이 페이지가 도움이 되었나요?

2026-10-27 에 마지막으로 업데이트됨