Criar e validar uma política MXC

Uma política MXC descreve a que recursos uma workload pode aceder. Comece com permissões predefinidas para negar, adicione apenas os recursos necessários para uma tarefa específica e valide o resultado com inputs representativos em todas as plataformas que a sua aplicação suporta. Cada backend também fornece os recursos do sistema operativo necessários para iniciar uma carga de trabalho; a negação por defeito não significa que o processo corra sem um ambiente de sistema.

Mantenha as decisões de política em código da aplicação de confiança. Uma ferramenta, plugin, script ou comando gerado por IA pode reportar o que precisa, mas não deve selecionar o seu próprio modelo de contenção nem expandir o seu próprio acesso.

Compreender a política e a configuração

O MXC separa as permissões de recursos das definições utilizadas para executar um comando:

  • As definições de política descrevem a intenção multiplataforma, como caminhos legíveis, caminhos graváveis, destinos de rede, acesso à interface e um timeout.
  • As definições de execução adicionam o comando, diretório de trabalho, ambiente e seleção de isolamento.

Nos SDKs V1, um ContainerRequest inclui ambos. No .NET, cria um ContainerRequest a partir do comando, define a sua política e propriedades de execução, e chama MxcContainer.RunAsync ou uma API de spawn. No TypeScript, passe um ContainerRequest objeto para run ou uma função de spawn. No Rust, constrói uma ContainerRequest estrutura e passa-a para v1::run ou para uma função spawn. Prefira a intenção abstrata Process de contenção, a menos que a sua carga de trabalho precise de um backend específico.

As seguintes definições de política independentes do idioma descrevem uma tarefa ao nível do repositório. Usam os nomes das propriedades TypeScriptContainerRequest; .NET usa a mesma estrutura com nomes PascalCase como ReadonlyPaths, e Rust usa nomes snake_case como readonly_paths. Não são um pedido completo: não contêm um comando nem selecionam um backend. Crie os diretórios e substitua os caminhos antes de os adaptar.

{
  "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 os tipos do SDK em vez de copiar as propriedades do pedido para uma configuração de execução em bruto. As formas diferem: por exemplo, o pedido timeoutMs mapeia para a configuração process.timeout, ui.allowInputInjection mapeia para ui.injection, e network.runtimeConfig para a secção de nível superior runtimeConfig . Consulte o quickstart do SDK para exemplos completos de C#, TypeScript e Rust.

Escolha um esquema compatível

Mantenha estas três perguntas separadas:

Eixo de compatibilidade O que deve verificar
SDK e lançamento do produto Quais as APIs e componentes de runtime que o pacote fornece
Schema de política Que contrato de configuração exato é aceite pela versão
Capacidades do host Quais restrições o ambiente selecionado pode impor em tempo de execução

Os SDKs MXC 1.0 V1 usam o esquema estável 1.0.0 internamente, por isso não especificas uma versão do esquema num ContainerRequestarquivo . Uma versão de esquema aplica-se apenas quando se cria uma configuração de execução JSON bruta, como um ficheiro para a wxc-exec ferramenta de linha de comandos.

Uma configuração bruta deve especificar um registado versionexato. O MXC 1.0 aceita 1.0.0, o esquema estável atual, e 0.9.0-alpha, o esquema mínimo suportado. O MXC rejeita a ausência de uma versão, versões descontinuadas anteriores a 0.9.0-alpha, como 0.8.0-alpha, e grafias não registadas como 1.0 ou 1.0.1. O 1.1.0-alpha contrato de desenvolvimento pode mudar antes da publicação, por isso não o uses para configurações de produção. Selecioná-la não autoriza backends experimentais.

Mantém o SDK e os componentes nativos de runtime da mesma release juntos. Consulte o versionamento do esquema MXC para os contratos registados.

Definir o âmbito do acesso a ficheiros

Classifica cada caminho de acordo com a forma como a carga de trabalho o utiliza:

Acesso Usa-o para
Read-only Origens, ferramentas, bibliotecas e configuração que a carga de trabalho deve inspecionar mas não alterar
Leitura/escrita Uma saída, cache ou diretório temporário específicos da tarefa
Negado Credenciais, repositórios não relacionados, configuração sensível e caminhos mais restritos dentro de uma permissão mais ampla

Conceda o acesso mais restrito possível. Por exemplo, conceda um diretório de resultados de teste em vez da raiz do repositório quando um comando apenas escreve a saída do teste. Trate os caminhos descobertos a partir de variáveis de ambiente, gestores de pacotes ou pesquisas de ferramentas como candidatos para revisão, e não como aprovações automáticas.

Inclua os binários das ferramentas, bibliotecas, configuração e caminhos temporários de que a carga de trabalho realmente precisa. Os SDKs fornecem utilitários de deteção do sistema de ficheiros, mas os seus resultados não constituem uma política aprovada. Revise cada caminho candidato antes de o adicionar.

Definir um diretório de trabalho não concede acesso a esse diretório. Adicione-o explicitamente à lista de sistemas de ficheiros apropriada.

Evite depender de uma regra de caminho sobreposto a menos que a tenha testado com o backend selecionado. Os backends usam mecanismos de acesso a ficheiros diferentes, e alguns não conseguem representar uma regra de negação dentro de um diretório mapeado ou montado.

Controlo do acesso à rede

Mantenha o acesso à rede negado, a menos que a tarefa o exija assim. Escolha um modelo de rede que o backend selecionado possa impor:

Modelo Usa-o para
Sem acesso externo Análise ou transformação que só necessita de recursos locais autorizados
Acesso direto com IP/CIDR, protocolo e regras de porta Uma tarefa que necessita de ligações diretas específicas, como TCP para um endpoint de serviço conhecido
HTTP(S) através de um proxy fornecido pela aplicação Pedidos cujos destinos ou permissões ao nível da aplicação são controlados pelo seu proxy

A política de rede direcional separa:

  • Saída da carga de trabalho para os destinos da rede.
  • Ingress de redes privadas ou locais para listeners no workload.
  • Loopback do host entre a carga de trabalho e os serviços no host, em ambas as direções.

As regras de IP/CIDR e portas não identificam um protocolo de aplicação ou nome de host. Permitir a porta TCP 443 não estabelece que a ligação usa HTTPS ou alcança apenas um serviço nomeado. Os pedidos DNS também podem necessitar de acesso quando a carga de trabalho resolve diretamente os destinos.

Os esquemas suportados rejeitam os campos de rede descontinuados, como defaultPolicy, allowedHosts, blockedHosts e network.proxy. Usa em vez disso os campos direcionais egress e ingress. Veja exemplos de políticas de rede.

Utilize um proxy de rede personalizado

A tua aplicação anfitriã fornece e inicia o proxy antes de iniciar a carga de trabalho. A MXC não fornece nem gere um proxy de produção. O proxy decide quais os pedidos e destinos a permitir; o MXC configura os clientes suportados para o utilizarem e aplica as restrições de rede do backend.

O pedido direcional utiliza a definição da runtimeConfig.networkProxy secção de rede para identificar um endpoint de loopback HTTP(S) com uma porta explícita. Numa configuração de execução bruta, esta definição é a de nível runtimeConfig.networkProxysuperior . Este endpoint é de configuração em tempo de execução, não uma lista de permissões na camada de aplicação. O modo proxy requer saída com negação por omissão e não pode ser combinado com regras de permitir ou negar saída direta.

O encaminhamento e a imposição do cliente são diferentes. As variáveis do ambiente proxy ou as definições da plataforma indicam aos clientes HTTP cooperantes onde enviar pedidos. Um caminho de aplicação apenas por proxy também deve impedir ligações diretas à internet; uma configuração cooperativa de proxy por si só não estabelece essa restrição.

O MXC não redireciona de forma transparente SSH, TCP/UDP arbitrário ou outros protocolos não HTTP através do proxy HTTP(S). O comportamento de host-loopback e de rede privada também varia consoante o backend. Revise o exemplo de configuração do proxy personalizado e os seus pré-requisitos em vez de assumir que o mesmo fragmento funciona em todo o lado.

Restringir o acesso à interface de utilizador

Por defeito, não permita que uma carga de trabalho em segundo plano crie janelas, leia ou escreva a área de transferências, ou injete entrada do teclado e do ponteiro. Adicione acesso à interface apenas quando fizer parte da experiência de utilizador pretendida da carga de trabalho.

Injeção de entrada significa entrada sintética de teclado ou apontador, não injeção arbitrária de código noutro processo.

Os controlos da interface dependem do host e do backend. Utilize informações de suporte em tempo de execução para verificar cada restrição que o seu design de segurança exige.

Execução vinculada

Defina um timeout para cada ação do agente, chamada de ferramenta ou script que deva terminar dentro de um período conhecido. Fornece apenas as variáveis de ambiente de que o processo precisa e mantém segredos fora tanto do ambiente do processo como dos caminhos legíveis dos ficheiros. Não assumas que omitir o ambiente cria um ambiente vazio: os predeterminados do backend e as opções de herança do SDK diferem.

Escolha um ciclo de vida que corresponda à tarefa. Prefira a execução one-shot para comandos independentes. Utilize um sandbox com estado apenas quando os comandos tiverem de partilhar ferramentas instaladas, identidade, ficheiros ou estado do sistema operativo.

Validar a política em vigor

Antes de enviar uma apólice:

  1. Usa a descoberta em tempo de execução do teu SDK e verifica os pré-requisitos do backend selecionado.
  2. Crie a configuração e trate de erros de validação de políticas ou de indisponibilidade do backend sem enfraquecer a política.
  3. Executar casos de sucesso representativo com os recursos que a carga de trabalho deve utilizar.
  4. Executar casos negativos que tentem ler segredos, escrever fora do diretório de saída, usar um caminho de rede não aprovado ou aceder a interfaces não autorizadas.
  5. Utilize o Modo Aprendizagem para investigar acesso em falta e reveja cada resultado antes de alterar a política.
  6. Remova todas as definições de aprendizagem ou auditoria e execute um último teste em modo de imposição.

Falhe quando o host não consegue impor um controlo obrigatório. Não selecione silenciosamente um backend com acesso mais amplo nem remova um campo de política para pôr uma carga de trabalho em execução. Uma análise ou lançamento bem-sucedidos não são prova de que todas as restrições pretendidas se cumpram.

Conteúdo relacionado

  • Última atualização a