Ejemplos de políticas MXC

Estos ejemplos muestran cómo los requisitos de carga de trabajo se traducen en permisos de recursos MXC. Puede empezar con el inicio rápido de C#, TypeScript o Rust y, a continuación, adaptar la configuración a la carga de trabajo.

El JSON de abajo usa la forma de configuración de ejecución sin procesar para el esquema 1.0.0 de MXC. Las configuraciones completas incluyen una versión y un comando; Las secciones etiquetadas como fragmentos deben incorporarse a una configuración existente. Cuando programe en C#, TypeScript o Rust, use los tipos del SDK V1 correspondientes, que no requieren una versión específica del esquema.

Estos son ejemplos de Windows. Reemplace las rutas de acceso por los recursos existentes en el host, conceda las dependencias de herramientas adicionales deliberadamente y confirme que la versión del SDK y el back-end admiten los controles seleccionados.

Ejecutar una herramienta con ámbito de repositorio

Esta configuración completa usa el mismo patrón leer-entrada/escribir-salida que el inicio rápido. Cree C:\src\my-app\input.txt y el C:\src\mxc-output directorio antes de ejecutarlo. El comando puede leer el directorio de origen y escribir el directorio de salida, pero no puede escribir en el origen ni usar la red o la interfaz.

{
  "$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
  }
}

En este ejemplo se supone que Windows está instalado en C:\Windows; use el directorio del sistema real en el host. Una solicitud de Windows ProcessContainer con una lista explícita env debe incluir tanto SystemRoot como LOCALAPPDATA. Al reemplazar el comando por una herramienta de compilación o análisis, configure sus memorias caché y archivos temporales para usar el directorio grabable dedicado en lugar de conceder acceso de escritura a todo el repositorio.

Proteger credenciales dentro de una concesión más amplia

La configuración anterior concede acceso de lectura a C:\src\my-app. Si ese directorio contiene un archivo de entorno o un directorio de secretos, añada este fragmento dentro de su sección filesystem existente, conservando las listas de solo lectura y de lectura/escritura:

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

Estas rutas de acceso denegadas están dentro del directorio de origen permitido. Mantenga los repositorios no relacionados y los directorios de perfil de usuario fuera de las concesiones.

Mantenga los secretos fuera de los árboles concedidos cuando sea posible. Verifique las concesiones y denegaciones superpuestas en el back-end seleccionado; algunos back-ends con directorio montado rechazan las denegaciones anidadas en lugar de imponerlas.

Permitir el acceso directo a un intervalo IP

Este fragmento de configuración reemplaza la network sección . Permite el puerto TCP saliente 443 a un intervalo CIDR aprobado y deniega otras salidas, entradas y accesos de bucle de retorno del host. Suministre los intervalos aprobados desde la configuración de confianza en lugar de aceptarlos de la carga de trabajo.

{
  "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 es un rango solo para documentación. Reemplácelo por las direcciones aprobadas del servicio previsto. La regla permite TCP en ese puerto, no exclusivamente HTTPS, un nombre de host o un servicio de aplicación. La resolución directa del nombre de host puede requerir una regla DNS independiente.

En este ejemplo se requiere un back-end y un host que admitan reglas de salida directas. No lo combine con runtimeConfig.networkProxy. En el caso de las decisiones HTTP(S) basadas en el nombre de host, use en su lugar una configuración basada en proxy admitida.

Usar un proxy proporcionado por la aplicación

La aplicación host debe iniciar su proxy antes de iniciar la carga de trabajo. Este ejemplo configura MXC para usar un proxy existente; no implementa, inicia ni aprueba la directiva de gestión de solicitudes del proxy.

El siguiente fragmento de configuración se dirige a Windows ProcessContainer con una ruta admitida de imposición del proxy en el ámbito del sistema operativo. Combinarla en la configuración completa, conservando el comando, los permisos del sistema de archivos, el tiempo de espera y las restricciones de la interfaz de usuario. Reemplace el punto de conexión y el nombre del par por los del proxy en ejecución.

{
  "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 identifica el paquete instalado del proxy o el perfil AppContainer sin empaquetar. El proxy debe escuchar en la dirección y el puerto de bucle invertido configurados y cumplir los requisitos previos Windows documentados. MXC no deduce esa identidad de la dirección URL.

Importante

Esta asignación de Windows requiere ingress.default: "allow", que también permite el tráfico de servidor de red privada. hostLoopback: "deny" mantiene cerrado el acceso general al bucle de retorno del host mientras el par del proxy configurado sea accesible. El ejemplo no es una configuración con todo el tráfico entrante denegado.

El acceso directo a internet sigue denegado en la ruta impuesta. El proxy controla qué solicitudes HTTP(S) reenvía. Un proxy de host plano, sin empaquetar y sin una identidad AppContainer necesita una configuración de compatibilidad distinta y más amplia; no quite allowedProxyPeer dando por hecho que se mantienen las mismas restricciones.

Utilice los tipos de SDK correspondientes y compruebe la compatibilidad antes de confiar en el acceso de solo proxy. Vea Opciones de implementación del proxy ProcessContainer para los requisitos previos de Windows y Redes direccionales para otros back-ends.

Permitir una herramienta visible sin acceso amplio a la interfaz de usuario

Para una carga de trabajo que necesita una ventana visible y una entrada del Portapapeles, este fragmento de configuración reemplaza ui. Permite las lecturas de ventanas y portapapeles, pero no las escrituras en el portapapeles ni la entrada sintética de teclado y puntero:

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

En un SDK ContainerRequestV1, las propiedades de interfaz de usuario equivalentes son disable, clipboardy allowInputInjection. Conceda acceso de lectura al portapapeles solo cuando la carga de trabajo lo requiera. Compruebe la compatibilidad con la interfaz de usuario en tiempo de ejecución y pruebe las restricciones necesarias en cada host de destino.

Reutilizar un sandbox con estado

Use la ejecución con estado cuando los comandos deban compartir un entorno. Aprovisiónelo e inícielo, ejecute los comandos y, a continuación, deténgalo y desaprovísionelo cuando termine. Programe la limpieza tras un error y una cancelación, no solo tras el éxito.

Las llamadas con estado usan un ProvisionRequest específico de la fase y un ExecutionRequest separado para cada comando, no la configuración completa de una sola vez de arriba. El aprovisionamiento devuelve un valor opaco ContainerId; páselo sin cambios a las fases posteriores. Use MxcLifecycle en .NET, las funciones del ciclo de vida de TypeScript como provisionContainer o las funciones de Rust v1::container como provision_container, con IsolationSession o WSLc, los back-ends que admiten las API de ciclo de vida de la V1. Consulte los conceptos del ciclo de vida, el ciclo de vida del contenedor MXC y la guía del SDK de .NET, TypeScript o Rust para conocer los requisitos exactos.

Compruebe qué impone cada back-end del ciclo de vida antes de elegirlo. IsolationSession separa al usuario y la sesión de la carga de trabajo pero no aplica el filtrado de sistema de archivos, interfaz ni red de MXC, y su solicitud debe permitir explícitamente todo el tráfico de red. La red de WSLc está totalmente aislada o totalmente puenteada, sin reglas por destino. Para obtener más información, consulte Elección de un tipo de contención y selección y configuración de back-end.

Compruebe los ejemplos

Para cada directiva adaptada, pruebe tanto el comportamiento previsto como los intentos de uso indebido:

  • Confirme que se pueden leer las entradas necesarias y que se pueden escribir salidas necesarias.
  • Confirme que las credenciales y los archivos no relacionados permanecen inaccesibles.
  • Confirme que las conexiones directas, de la red local, de bucle de retorno y entrantes coinciden con la directiva.
  • Para el acceso basado en proxy, confirme que una solicitud aprobada se realiza correctamente y se produce un error en un intento directo de Internet.
  • Confirme que el Portapapeles, la inserción de entrada y las ventanas visibles coinciden con la directiva de interfaz de usuario.
  • Confirme que los tiempos de espera y la limpieza funcionan tras el éxito, el error y la cancelación.

Use Learning Mode para investigar los accesos ausentes. No conceda automáticamente todos los recursos que observe una ejecución representativa.