Crear y validar una directiva MXC

Una directiva MXC describe a qué puede acceder una carga de trabajo. Comience con permisos con denegación predeterminada, agregue solo los recursos necesarios para una tarea específica y valide el resultado con entradas representativas en cada plataforma que admita la aplicación. Cada back-end también proporciona los recursos del sistema operativo necesarios para iniciar una carga de trabajo; deny-by-default no significa que el proceso se ejecute sin un entorno del sistema.

Mantenga las decisiones de política en el código de aplicación de confianza. Una herramienta, complemento, script o comando generado por IA puede notificar lo que necesita, pero no debe seleccionar su propio modelo de contención ni expandir su propio acceso.

Entender la directiva y la configuración

MXC separa los permisos de recursos de la configuración usada para ejecutar un comando:

  • La configuración de directiva describe la intención entre plataformas, como las rutas legibles, las rutas con permiso de escritura, los destinos de red, el acceso a la interfaz y un tiempo de espera.
  • La configuración de ejecución añade el comando, el directorio de trabajo, el entorno y la selección de contención.

En los SDK de la V1, un ContainerRequest lleva ambos. En .NET, cree un ContainerRequest a partir del comando, establezca sus propiedades de directiva y ejecución, y llame a MxcContainer.RunAsync o a una API de creación de procesos. En TypeScript, pase un objeto ContainerRequest a run o a una función spawn. En Rust, cree una ContainerRequest estructura y pásela a v1::run o a una función spawn. Prefiera la intención de contención abstracta Process a menos que la carga de trabajo necesite un back-end determinado.

La siguiente configuración de directiva independiente del idioma describe una tarea con ámbito de repositorio. Usan los nombres de propiedad typeScriptContainerRequest; .NET usa la misma estructura con nombres PascalCase como ReadonlyPaths, y Rust usa nombres de snake_case como readonly_paths. No son una solicitud completa: no contienen un comando ni seleccionan un back-end. Cree los directorios y reemplace las rutas de acceso antes de adaptarlas.

{
  "filesystem": {
    "readonlyPaths": ["C:\\src\\my-app"],
    "readwritePaths": ["C:\\src\\mxc-output"],
    "deniedPaths": ["C:\\src\\my-app\\.env"]
  },
  "network": {
    "egress": { "default": "deny" },
    "ingress": { "default": "deny", "hostLoopback": "deny" }
  },
  "ui": {
    "disable": true,
    "clipboard": "none",
    "allowInputInjection": false
  },
  "timeoutMs": 30000
}

Use los tipos del SDK en lugar de copiar las propiedades de la solicitud en una configuración de ejecución sin procesar. Las formas difieren: por ejemplo, timeoutMs de la solicitud se asigna a process.timeout de la configuración, ui.allowInputInjection se asigna a network.runtimeConfig, y ui.injection se asigna a la sección runtimeConfig de nivel superior. Consulte el inicio rápido del SDK para obtener ejemplos completos de C#, TypeScript y Rust.

Elija un esquema compatible

Mantenga estas tres preguntas separadas:

Eje de compatibilidad Elementos que se deben comprobar
Lanzamiento del SDK y del producto ¿Qué API y qué componentes en tiempo de ejecución proporciona el paquete?
Esquema de política Qué contrato de configuración exacto acepta la versión
Capacidades del host Qué restricciones puede aplicar el entorno seleccionado en tiempo de ejecución

Los SDK V1 de MXC 1.0 usan el esquema estable 1.0.0 internamente, por lo que no se especifica una versión de esquema en un ContainerRequest. Una versión de esquema solo se aplica cuando redacta una configuración de ejecución JSON sin procesar, como un archivo para la herramienta de línea de comandos wxc-exec.

Una configuración sin procesar debe declarar un version registrado exacto. MXC 1.0 acepta 1.0.0, el esquema estable actual y 0.9.0-alpha, el esquema mínimo admitido. MXC rechaza la ausencia de una versión, versiones retiradas anteriores a 0.9.0-alpha, como 0.8.0-alpha, y ortografías no registradas como 1.0 o 1.0.1. El 1.1.0-alpha contrato de desarrollo puede cambiar antes de la publicación, por lo que no lo use para las configuraciones de producción. Seleccionarlo no autoriza los backends experimentales.

Mantenga juntos el SDK y los componentes en tiempo de ejecución nativos de la misma versión. Consulte Control de versiones de esquema MXC para los contratos registrados.

Delimitar el acceso a archivos

Clasifique cada ruta de acceso por cómo la carga de trabajo la usa:

Acceso Úselo para
Solo lectura Origen, herramientas, bibliotecas y configuración que la carga de trabajo debe examinar pero no cambiar
Lectura-escritura Un directorio de salida, caché o temporal específico de la tarea
Denegado Credenciales, repositorios no relacionados, configuración sensible y rutas más restringidas dentro de una concesión más amplia

Conceda la ruta más restringida que sea práctica. Por ejemplo, conceda un directorio test-results en lugar de la raíz del repositorio cuando un comando solo escribe la salida de prueba. Trate las rutas detectadas a partir de variables de entorno, administradores de paquetes o búsquedas de herramientas como candidatas para revisar, no como concesiones automáticas.

Incluya los binarios de la herramienta, las bibliotecas, la configuración y las rutas de acceso temporales que realmente necesita la carga de trabajo. Los SDK proporcionan asistentes de detección de sistemas de archivos, pero sus resultados no son una política aprobada. Revisa cada ruta candidata antes de agregarla.

Establecer un directorio de trabajo no concede acceso a ese directorio. Agréguelo a la lista de sistemas de archivos adecuada explícitamente.

Evite confiar en una regla de ruta de acceso superpuesta a menos que la haya probado con el back-end seleccionado. Los back-end usan diferentes mecanismos de acceso a archivos y algunos no pueden representar una regla de denegación dentro de un directorio asignado o montado.

Control del acceso a la red

Mantenga denegado el acceso a la red a menos que la tarea lo requiera. Elija un modelo de red que el back-end seleccionado pueda aplicar:

Model Úselo para
Sin acceso externo Análisis o transformación que necesita solo los recursos locales concedidos
Acceso directo con reglas de puerto, protocolo y IP/CIDR Tarea que necesita conexiones directas específicas, como TCP a un punto de conexión de servicio conocido
HTTP(S) a través de un proxy proporcionado por la aplicación Solicitudes cuyos destinos o permisos de nivel de aplicación controla el proxy

La directiva de red direccional separa:

  • Salida desde la carga de trabajo hasta los destinos de red.
  • Entrada desde las redes privadas o locales hacia los agentes de escucha de la carga de trabajo.
  • Bucle de retorno del host entre la carga de trabajo y los servicios del host, en ambos sentidos.

Las reglas de ip/CIDR y puerto no identifican un protocolo de aplicación ni un nombre de host. Permitir el puerto TCP 443 no establece que la conexión use HTTPS o que solo llegue a un servicio específico identificado por nombre. Las solicitudes DNS también pueden requerir acceso cuando la carga de trabajo resuelve los destinos directamente.

Los esquemas admitidos rechazan los campos de red retirados, como defaultPolicy, allowedHosts, blockedHostsy network.proxy. Use los campos direccionales egress y ingress en su lugar. Consulte ejemplos de directivas de red.

Uso de un proxy de red personalizado

La aplicación host proporciona e inicia el proxy antes de iniciar la carga de trabajo. MXC no proporciona ni administra un proxy de producción. El proxy decide qué solicitudes y destinos permitir; MXC configura los clientes compatibles para usarlo y aplica las restricciones de red del back-end.

La solicitud direccional usa la configuración runtimeConfig.networkProxy de la sección de red para identificar un punto de conexión HTTP(S) de bucle de retorno con un puerto explícito. En una configuración de ejecución sin procesar, esta configuración es el runtimeConfig.networkProxy del nivel superior. Este punto de conexión es configuración del tiempo de ejecución, no una lista de permitidos del nivel de aplicación. El modo proxy requiere salida con denegación predeterminada y no se puede combinar con reglas directas para permitir o denegar la salida.

El enrutamiento del cliente y la imposición son cosas distintas. Las variables de entorno de proxy o la configuración de la plataforma indican a los clientes HTTP que colaboran dónde enviar solicitudes. Una ruta de imposición solo con proxy también debe impedir las conexiones directas a internet; una configuración de proxy cooperativa por sí sola no establece esa restricción.

MXC no redirige de forma transparente SSH, TCP/UDP arbitrario u otros protocolos que no son HTTP a través del proxy HTTP(S). El comportamiento de bucle de retorno del host y de red privada también varía según el back-end. Revise el ejemplo de configuración de proxy personalizado y sus requisitos previos en lugar de asumir que el mismo fragmento funciona en todas partes.

Restringir el acceso a la interfaz de usuario

De forma predeterminada, no permita que una carga de trabajo en segundo plano cree ventanas, lea o escriba el Portapapeles ni inserte la entrada de teclado y puntero. Agregue acceso a la interfaz de usuario solo cuando forme parte de la experiencia de usuario prevista de la carga de trabajo.

La inyección de entrada se refiere a la entrada sintética de teclado o puntero, no a la inyección arbitraria de código en otro proceso.

Los controles de interfaz de usuario dependen del host y del back-end. Use la información de soporte técnico en tiempo de ejecución para comprobar cada restricción que requiera el diseño de seguridad.

Ejecución vinculada

Establezca un tiempo de espera para cada acción del agente, llamada a la herramienta o script que debe finalizar en un período conocido. Proporcione solo las variables de entorno que necesita el proceso y mantenga los secretos fuera del entorno de proceso y de las rutas de acceso de archivo legibles. No suponga que la omisión del entorno crea uno vacío: los valores predeterminados de back-end y las opciones de herencia del SDK difieren.

Elija un ciclo de vida que coincida con la tarea. Se prefiere la ejecución única para comandos independientes. Use un sandbox con estado solo cuando los comandos deban compartir las herramientas instaladas, la identidad, los archivos o el estado del sistema operativo.

Validar la directiva efectiva

Antes de distribuir una directiva:

  1. Use la detección en tiempo de ejecución del SDK y compruebe los requisitos previos del back-end seleccionado.
  2. Cree la configuración y gestione los errores de validación de directiva o de back-end no disponible sin debilitar la directiva.
  3. Ejecute los casos de éxito representativos con los recursos que debe usar la carga de trabajo.
  4. Ejecute casos negativos que intenten leer secretos, escribir fuera del directorio de salida, usar una ruta de acceso de red no aprobada o acceder a una interfaz de usuario no permitida.
  5. Use Learning Mode para investigar los accesos ausentes, y revise cada resultado antes de cambiar la directiva.
  6. Quite todas las configuraciones de aprendizaje o auditoría y ejecute una prueba de imposición final.

Falla cuando el host no puede aplicar un control necesario. No seleccione de forma silenciosa un back-end con acceso más amplio ni quite un campo de directiva para ejecutar una carga de trabajo. Un análisis o un lanzamiento correctos no son evidencia de que se mantenga cada restricción prevista.

Contenido relacionado

  • Se actualizó por última vez el