Примеры политик MXC

В этих примерах показано, как требования к рабочей нагрузке преобразуются в разрешения ресурсов MXC. Вы можете начать с краткого руководства по C#, TypeScript или Rust, а затем адаптировать конфигурацию к рабочей нагрузке.

В приведенном ниже формате JSON используется структура raw конфигурации выполнения для схемы MXC 1.0.0. Полные конфигурации включают версию и команду; разделы, помеченные как фрагменты, должны быть включены в существующую конфигурацию. При создании в C#, TypeScript или Rust используйте соответствующие типы SDK V1, для которых не требуется определенная версия схемы.

Это примеры для Windows. Замените пути существующими ресурсами на узле, предоставьте любые дополнительные зависимости инструментов только осознанно и убедитесь, что выпуск пакета SDK и серверная часть поддерживают выбранные элементы управления.

Запустите средство для репозитория

В этой полной конфигурации используется тот же шаблон чтения входных данных/записи выходных данных, что и в кратком руководстве. Создайте C:\src\my-app\input.txt и каталог C:\src\mxc-output перед его запуском. Команда может считывать исходный каталог и записывать в выходной каталог, но не может записывать в исходный каталог или использовать сеть или пользовательский интерфейс.

{
  "$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; используйте фактический системный каталог в вашей системе. Запрос Windows ProcessContainer с явным env списком должен включать оба SystemRoot иLOCALAPPDATA. Когда вы заменяете команду средством сборки или анализа, настройте кэши и временные файлы на использование выделенного записываемого каталога, а не предоставляйте доступ на запись ко всему репозиторию.

Защита учетных данных внутри более широкого гранта

Предыдущая конфигурация предоставляет доступ для чтения к C:\src\my-app. Если этот каталог содержит файл среды или каталог секретов, добавьте этот фрагмент внутрь существующего раздела filesystem, сохранив списки только для чтения и записи:

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

Эти запрещённые пути находятся внутри разрешённого исходного каталога. Сохраняйте не связанные репозитории и каталоги профилей пользователей за пределами разрешений.

По возможности храните секреты вне разрешённых каталогов. Проверьте перекрывающиеся разрешения и запреты в выбранном бэкенде; некоторые бэкенды со смонтированными каталогами отклоняют вложенные запреты вместо их применения.

Разрешить прямой доступ к диапазону IP-адресов

Этот фрагмент конфигурации заменяет network раздел. Он разрешает исходящий трафик через TCP-порт 443 в утвержденный диапазон CIDR и запрещает весь прочий исходящий и входящий трафик, а также loopback-доступ узла. Предоставляйте утвержденные диапазоны из доверенной конфигурации, а не принимайте их из рабочей нагрузки.

{
  "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 настраивается для использования существующего прокси-сервера; он не реализует, не запускает и не утверждает политику обработки запросов прокси-сервера.

Следующий фрагмент конфигурации предназначен для Windows ProcessContainer с поддерживаемым механизмом принудительного применения прокси-политики на уровне ОС. Объедините его в полную конфигурацию, сохраняя команду, разрешения файловой системы, ограничения времени ожидания и пользовательского интерфейса. Замените конечную точку и имя однорангового узла на соответствующие значения вашего запущенного прокси-сервера.

{
  "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-адреса.

Important

Для этого сопоставления Windows требуется ingress.default: "allow", которое также разрешает трафик к серверам частной сети. hostLoopback: "deny" сохраняет общий доступ к loopback-интерфейсу хоста закрытым, пока настроенный пир прокси доступен. Пример не является конфигурацией с запретом всего входящего трафика.

Прямой доступ к Интернету по-прежнему запрещен на пути принудительной обработки. Прокси-сервер определяет, какие HTTP(S)-запросы он пересылает. Простой неупакованный прокси-сервер узла без удостоверения AppContainer требует другой, более широкой конфигурации совместимости; не удаляйте allowedProxyPeer и не предполагайте, что те же ограничения сохраняются.

Используйте соответствующие типы SDK и проверьте поддержку перед использованием доступа только через прокси. См. варианты развертывания прокси-сервера ProcessContainer, чтобы узнать сведения о предварительных требованиях для Windows, и направленной сетевой связи для других серверных частей.

Разрешить видимый инструмент без широкого доступа к пользовательскому интерфейсу

Для рабочей нагрузки, требующей видимого окна и входных данных буфера обмена, этот фрагмент конфигурации заменяет ui. Он позволяет считывать содержимое окон и буфер обмена, но не записывать в буфер обмена и не эмулировать ввод с клавиатуры и указателя:

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

В пакете SDK ContainerRequestверсии 1 эквивалентные свойства пользовательского интерфейса: disableclipboardи allowInputInjection. Разрешайте чтение буфера обмена только в том случае, если рабочая нагрузка этого требует. Проверьте поддержку интерфейса среды выполнения и проверьте необходимые ограничения на каждом целевом узле.

Повторное использование песочницы с учетом состояния

Используйте выполнение с учетом состояния, когда команды должны совместно использовать среду. Подготовьте и запустите её, выполните команды, а затем остановите и выведите её из эксплуатации после завершения. Обеспечьте очистку после сбоя и отмены, а не только после успешного завершения.

Вызовы, зависящие от состояния, используют специфичный для фазы ProvisionRequest и отдельную ExecutionRequest для каждой команды, а не полную однократную конфигурацию выше. Подготовка возвращает непрозрачный ContainerId; передавайте его без изменений на последующие этапы. Используйте MxcLifecycle в .NET, функции жизненного цикла TypeScript, такие как v1::container, или функции provisionContainer Rust, такие как provision_container, с IsolationSession или WSLc — бэкендами, которые поддерживают API жизненного цикла V1. См. концепции жизненного цикла, жизненный цикл контейнера MXC и руководство по SDK .NET, TypeScript или Rust для получения точных требований.

Прежде чем выбрать серверную часть жизненного цикла, проверьте, что обеспечивает каждая серверная часть жизненного цикла. IsolationSession отделяет пользователя и сеанс рабочей нагрузки, но не применяет фильтрацию файловой системы MXC, пользовательского интерфейса или сети, а его запрос должен явно разрешать весь сетевой трафик. Сеть WSLc полностью изолирована или полностью мостовая, без правил для отдельных назначений. Дополнительные сведения см. в разделах Выбор типа контейнера и Выбор серверной части и параметров.

Проверьте примеры

Для каждой адаптированной политики проверьте как предполагаемое поведение, так и попытки ненадлежащего использования:

  • Убедитесь, что необходимые входные данные можно считывать и необходимые выходные данные можно записывать.
  • Убедитесь, что учетные данные и несвязанные файлы остаются недоступными.
  • Убедитесь, что прямые, подключения локальной сети, loopback-подключения и входящие подключения соответствуют политике.
  • Для доступа на основе прокси-сервера убедитесь, что разрешенный запрос успешно выполнен, и прямая попытка доступа в интернет завершается ошибкой.
  • Убедитесь, что буфер обмена, инъекция ввода и видимые окна соответствуют политике пользовательского интерфейса.
  • Убедитесь, что время ожидания и очистка работают после успешного выполнения, сбоя и отмены.

Используйте Learning Mode, чтобы выяснить причину отсутствия доступа. Не предоставляйте автоматически доступ каждому ресурсу, который обнаруживается при пробном запуске.