Exemplos de política MXC

Estes exemplos mostram como os requisitos de carga de trabalho se traduzem em permissões de recursos MXC. Podes começar com o C#, TypeScript ou Rust quickstart, e depois adaptar a configuração à tua carga de trabalho.

O JSON abaixo utiliza a forma bruta de configuração de execução para o esquema MXC 1.0.0 . As configurações completas incluem uma versão e um comando; as secções rotuladas como fragmentos devem ser incorporadas numa configuração existente. Quando escreves em C#, TypeScript ou Rust, usa os tipos de SDK V1 correspondentes, que não requerem uma versão específica do esquema.

Estes são exemplos do Windows. Substitua os caminhos por recursos existentes no seu host, conceda deliberadamente quaisquer dependências adicionais de ferramentas e confirme que o seu SDK release e backend suportam os controlos selecionados.

Executar uma ferramenta com âmbito de repositório

Esta configuração completa utiliza o mesmo padrão read-input/write-output do quickstart. Crie C:\src\my-app\input.txt e o diretório C:\src\mxc-output antes de o executar. O comando pode ler o diretório de origem e escrever o diretório de saída, mas não pode escrever na origem nem usar a rede ou a interface.

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

Este exemplo assume que o Windows está instalado em C:\Windows; use o diretório do sistema real no seu host. Um pedido ProcessContainer do Windows com uma lista explícita env deve incluir tanto SystemRoot como LOCALAPPDATA. Quando substituir o comando por uma ferramenta de compilação ou análise, configure as suas caches e ficheiros temporários para usarem o diretório dedicado gravável em vez de conceder acesso de escrita a todo o repositório.

Proteger as credenciais dentro de uma concessão mais ampla

A configuração anterior concede acesso de leitura a C:\src\my-app. Se esse diretório contiver um ficheiro de ambiente ou um diretório de segredos, adicione este fragmento dentro da sua secção existentefilesystem, preservando as listas de apenas leitura e leitura-escrita:

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

Estes caminhos negados estão dentro do diretório de origem autorizado. Mantenha repositórios e diretórios de perfis de utilizador não relacionados fora das permissões.

Mantém segredos fora das árvores autorizadas sempre que possível. Verifique concessões e recusas sobrepostas no backend selecionado; alguns backends mounted-directory rejeitam recusas aninhadas em vez de as impor.

Permitir acesso direto a um intervalo de IP

Este fragmento de configuração substitui a network secção. Permite a saída pela porta TCP 443 para um intervalo CIDR aprovado e nega todos os outros acessos de saída, entrada e loopback do anfitrião. Forneça intervalos aprovados a partir de uma configuração fidedigna, em vez de os aceitar da workload.

{
  "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 é um intervalo apenas para documentação. Substitua-o pelos endereços aprovados do serviço em questão. A regra permite TCP nessa porta, não apenas HTTPS, um único nome de anfitrião ou um único serviço de aplicação. A resolução direta de nomes de host pode exigir uma regra DNS separada.

Este exemplo requer um backend e um host que suportem regras de saída direta. Não o combine com runtimeConfig.networkProxy. Para decisões HTTP(S) baseadas em nomes de host, use antes uma configuração suportada baseada em proxy.

Utilize um proxy fornecido pela aplicação

A sua aplicação anfitriã tem de iniciar o seu proxy antes de iniciar a carga de trabalho. Este exemplo configura o MXC para usar um proxy existente; não implementa, inicia nem aprova a política de tratamento de pedidos HTTP do proxy.

O seguinte fragmento de configuração tem como alvo o Windows ProcessContainer com um caminho de aplicação de proxy ao nível do sistema operativo suportado. Junte-o à configuração completa, mantendo o comando, as permissões do sistema de ficheiros, o timeout e as restrições da interface. Substitua o endpoint e o nome do peer pelos do seu proxy em execução.

{
  "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 o pacote instalado do proxy ou o perfil AppContainer não empacotado. O proxy deve ouvir o endereço de loopback e a porta configurados e cumprir os pré-requisitos documentados do Windows. O MXC não infere essa identidade a partir do URL.

Importante

Este mapeamento do Windows requer ingress.default: "allow", que também permite tráfego de servidores numa rede privada. hostLoopback: "deny" mantém o acesso geral ao host-loopback fechado enquanto o par proxy configurado está acessível. O exemplo não é uma configuração com todo o tráfego de entrada negado.

O acesso direto à internet continua negado no caminho de imposição. O proxy controla que pedidos HTTP(S) encaminha. Um proxy de host simples, não empacotado, sem identidade AppContainer, necessita de uma configuração de compatibilidade diferente e mais ampla; não remova allowedProxyPeer e assuma que as mesmas restrições permanecem.

Utilize os tipos de SDK correspondentes e verifique o suporte antes de depender apenas do acesso por proxy. Consulte as opções de implementação do proxy ProcessContainer para pré-requisitos do Windows e a ligação em rede direcional para outros backends.

Permitir uma ferramenta visível sem acesso amplo à interface de utilizador

Para uma carga de trabalho que necessita de uma janela visível e entrada na área de transferência, este fragmento de configuração substitui ui. Permite leituras de janelas e da área de transferência, mas não escritas na área de transferência nem entrada sintética de teclado e ponteiro:

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

Num SDK ContainerRequestV1 , as propriedades equivalentes da interface são disable, clipboard, e allowInputInjection. Permita leituras da área de transferência apenas quando a carga de trabalho as exigir. Verifique o suporte da IU em tempo de execução e teste as restrições necessárias em cada host alvo.

Reutilizar um sandbox sensível ao estado

Utilize a execução com conhecimento do estado quando os comandos têm de partilhar um ambiente. Provisionar e iniciá-lo, executar os comandos, depois parar e desprovisioná-lo quando terminar. Efetue a limpeza após falhas e cancelamentos, não apenas após o sucesso.

As chamadas sensíveis ao estado usam um ProvisionRequest específico da fase e um ExecutionRequest separado para cada comando, não a configuração completa de one-shot acima. O provisionamento devolve um opaco ContainerId; passe-o inalterado para fases posteriores. Utilize MxcLifecycle no .NET, as funções do ciclo de vida TypeScript como provisionContainer, ou as funções Rust v1::container como provision_container, com IsolationSession ou WSLc, os backends que as APIs do ciclo de vida V1 suportam. Consulte conceitos de ciclo de vida, ciclo de vida dos contentores MXC e o guia do SDK de .NET, TypeScript ou Rust para requisitos exatos.

Verifica o que cada backend do ciclo de vida impõe antes de o escolheres. O IsolationSession separa o utilizador e a sessão da carga de trabalho, mas não aplica o sistema de ficheiros MXC, a UI ou a filtragem de rede, e o seu pedido deve permitir explicitamente todo o tráfego de rede. A rede WSLc é totalmente isolada ou totalmente bridged, sem regras por destino. Para detalhes, consulte Escolher um tipo de contenção e seleção e definições do Backend.

Verifique os exemplos

Para cada política adaptada, testar tanto o comportamento pretendido como a tentativa de uso indevido:

  • Confirme que as entradas necessárias podem ser lidas e as saídas necessárias podem ser escritas.
  • Confirme que as credenciais e ficheiros não relacionados continuam inacessíveis.
  • Confirme que as ligações diretas, de rede local, de loopback e de entrada correspondem à política.
  • Para acesso baseado em proxy, confirme que um pedido aprovado seja bem-sucedido e que uma tentativa direta de internet falhe.
  • Confirma se a área de transferência, a injeção de entrada e as janelas visíveis correspondem à política da interface.
  • Confirma que os tempos de espera e a limpeza funcionam após sucesso, falha e cancelamento.

Utilize o Modo de Aprendizagem para investigar acesso em falta. Não conceda automaticamente todos os recursos que uma execução representativa observa.

Conteúdo relacionado

  • Última atualização a