Práticas recomendadas de contenção de agentes: sandboxing (beta privado)

Para clientes do nosso Programa de Verificação de Segurança, estamos fornecendo um novo classificador de escape de sandbox na API para monitorar e reduzir abuso. Este artigo explica por que agentes autônomos precisam de isolamento forte, como o design de referência os isola e como definir o escopo e supervisionar engajamentos que precisam de acesso à rede.

Para uma visão geral de todos os recursos disponíveis, consulte Práticas recomendadas de contenção de agentes: primeiros passos (beta privado).

Se você construir seu próprio sandbox, estas são as propriedades que o design de referência fornece. O resto deste artigo descreve uma maneira de obtê-las.

Execute agentes autônomos em sandboxes fortes e pense sobre quais efeitos colaterais um processo nesse sandbox ainda poderia causar. Modelos de fronteira são cada vez melhores em encontrar caminhos criativos ao redor de restrições: a mesma propriedade que os torna caçadores de vulnerabilidades eficazes significa que podem tomar ações inesperadas contra seu próprio ambiente de execução. Isso não é hipotético. A Anthropic publicou exemplos de modelos contornando restrições fracas para completar uma tarefa (consulte Como contemos Claude em todos os produtos).

Concretamente, não execute agentes autônomos de busca de vulnerabilidades em Docker/runc simples, e especialmente não com --privileged ou rede de host. Contêineres padrão compartilham o kernel do host, então uma exploração de kernel dentro do contêiner é um comprometimento do host. Recomendamos colocar um kernel virtualizado por hardware entre o código-alvo e o host, o que significa executar o agente em uma máquina virtual. Quando isso não é possível, use um host bare-metal dedicado que não contenha nada mais. Se você construir seu próprio sandbox, recomendamos Firecracker no Linux, Hyper-V no Windows e uma VM baseada no framework Hypervisor no macOS. O design de referência usa Firecracker.

Bloqueie toda saída do sandbox. O agente alcança a API do modelo apenas através de um proxy que adiciona a credencial e é executado fora do sandbox, então o sandbox não precisa de uma rota direta para o host da API. Instale cada ferramenta, pacote e dependência antes do início da execução, para que nada precise ser buscado durante ela.

O uso interativo, com um humano no loop, geralmente apresenta menos risco, mas ainda recomendamos um sandbox para ele. Se você conduzir um agente interativamente do Claude Code em um laptop, revise cada uso de ferramenta (modo manual) ou confie no classificador de permissão do modo automático e tenha um humano aprovando cada ação que alcance fora do repositório. O modo automático remove prompts de permissão rotineiros: aprova leituras e edições de diretório de trabalho automaticamente e envia tudo mais para um classificador de fundo que visa bloquear ações destrutivas, irreversíveis ou fora da tarefa. É uma verificação de melhor esforço. Pode perder coisas e em trabalho de segurança também pode recusar alguns passos legítimos. Modo automático descreve como funciona, o que esperar dele e como configurá-lo para seu ambiente.

Nunca monte caminhos com credenciais como ~/.aws, ~/.ssh ou .env no ambiente do agente. O mesmo vale para a credencial que as próprias chamadas de modelo do agente usam. Mantenha-a fora do sandbox e tenha um proxy que o agente não possa ler adicionando-a a cada solicitação (consulte O proxy de credencial). Não conecte agentes a servidores MCP ou ferramentas com acesso de escrita a estado externo como email, armazenamento em nuvem ou infraestrutura de produção.

Este é um padrão que coloca as diretrizes acima em prática. A fase de configuração tem acesso à internet de saída e um humano no loop que aprova cada chamada de ferramenta. Nela o agente puxa dependências, constrói o alvo e monta seu sandbox a partir de um documento de especificação. A fase de ataque não tem acesso geral à internet. Toda saída passa por um proxy de lista de permissões que permite apenas os hosts nomeados no engajamento, então o proxy também aplica escopo. Chamadas de modelo passam pelo proxy de credencial separado. O agente pode então sondar o alvo sem supervisão. O proxy contém o tráfego do próprio agente. Não contém tráfego que um alvo em rede envia em nome do agente.

Integre as dependências que o agente precisa repetidamente na imagem de configuração, para que execuções de fase de ataque não precisem de acesso à internet. Escopo de credenciais por alvo, para que um agente trabalhando em um alvo não possa usá-las contra outro. Mantenha o modo automático do Claude Code ligado dentro do sandbox durante a fase de ataque e descreva o sandbox para seu classificador. Consulte Modo automático.

Dê a cada agente um orçamento explícito, para que uma execução que exceda seu teste pretendido pare por conta própria e não quando alguém notar. Aplique um limite de turno rígido em cada agente. Quando um agente o esgota, termine a execução e não conceda mais turnos automaticamente. Relançar com um limite mais alto é o ponto em que uma pessoa decide continuar. Limite execuções também em tempo. Termine uma sessão que exceda seu limite de tempo da mesma forma: a execução é final e nunca retomada, e o processo do agente é interrompido, mesmo quando o limite é atingido no meio de um comando de longa duração. Se um limite for definido para um valor que não pode ser lido, recuse iniciar em vez de executar sem limite. Defina os limites deliberadamente para o engajamento e não aceite um padrão generoso. Emparelhe-os com a cadência de monitoramento em monitoramento offline de transcrições de agentes, para que um lote longo seja analisado a cada hora ou duas e não apenas no final. Saiba como parar um único agente sem parar o lote. Em uma configuração baseada em Docker, é docker rm -f <agent-container>. O orquestrador deve registrar essa execução como falha e continuar com o resto do lote.

Para mais orientação, leia dois recursos da Anthropic. Implantação segura de agentes de IA cobre opções de isolamento, proxy de credencial e endurecimento de sistema de arquivos. O retrospecto de engenharia Como contemos Claude em todos os produtos cobre o que funcionou e o que não funcionou quando esses mesmos mecanismos foram executados em produção.

O sandbox limita o que um agente pode alcançar. Para pentesting, red teaming e outros engajamentos que precisam de acesso à rede, as práticas abaixo limitam o que o agente é solicitado e autorizado a fazer. Elas dependem de seus alvos e sua equipe, então ferramentas não podem colocar a maioria delas em prática para você.

Antes de uma execução, diga ao agente quais alvos estão no escopo, quais ações são permitidas, onde está o limite da rede e o que está fora do escopo. Expresse cada restrição como intenção ("não acesse hosts fora de 10.0.3.0/24") e não como uma afirmação sobre o ambiente ("você não pode alcançar a internet"), para que a instrução ainda valha se o ambiente estiver mal configurado. Faça isso também para trabalho local em sandbox: diga ao agente para não usar acesso à internet, mesmo que o sandbox o bloqueie. A descrição que você dá ao classificador do modo automático é uma coisa diferente. Ela declara fatos sobre a máquina (consulte Modo automático).

Onde você puder, execute o agente dentro do mesmo isolamento descrito acima e coloque na lista de permissões a saída apenas para os alvos no escopo (consulte Lista de permissões de saída). O agente alcança a API do modelo através do proxy de credencial, não através da lista de permissões. Onde um estiver disponível, aponte o engajamento para um ambiente de preparação ou réplica que esteja desconectado da produção.

Dê ao agente acesso a sistemas-alvo através de algo que você possa observar, como um proxy de acesso ou um conjunto definido de ferramentas. Evite deixar o agente escrever suas próprias ferramentas com acesso geral ao alvo. Em um harness personalizado, separe ferramentas somente leitura de ferramentas que mudam estado e supervise o segundo grupo mais de perto. Considere analisar comandos arriscados conforme são propostos e negá-los ou escalá-los para uma pessoa.

Recomendamos que um engenheiro observe cada execução conforme ela é executada, acompanhando chamadas de ferramentas e atividade de rede, e seja capaz de interromper a execução imediatamente. Agentes agem na velocidade da máquina, então a observação ao vivo complementa os controles que agem antes de uma ação ser executada (listas de permissões de rede, ferramentas intermediadas e revisão de ações que mudam estado). Não os substitui. Para execuções longas ou autônomas onde atenção contínua é impraticável, monitore continuamente em software (consulte Monitoramento offline de transcrições de agentes).

Não execute agentes autônomos contra sistemas de produção ao vivo onde uma ação fora do escopo poderia colocar em risco a segurança ou a disponibilidade de serviços críticos, como OT/ICS, médicos ou sistemas de energia. Isso já é a norma para testes liderados por humanos de tais sistemas e se aplica igualmente aqui. Teste contra uma réplica, um testbed ou um gêmeo digital, ou durante uma interrupção planejada. Onde o acesso ao vivo é inevitável, limite o agente a atividade passiva ou somente leitura e tenha uma pessoa executando cada passo que muda estado.

Antes de executar engajamentos reais de um host, teste seu sandbox com as duas etapas abaixo. Faça isso antes do primeiro uso real e novamente sempre que você mudar o modelo ou o sandbox. Mudanças de sandbox incluem um novo host, uma nova versão do hipervisor ou runtime de contêiner, uma configuração de rede ou proxy diferente e uma configuração de contêiner ou composição editada.

Em uma sessão interativa do Claude Code no host, peça-lhe para ler a configuração da sandbox conforme está configurada nesta máquina e para relatar qualquer coisa que enfraquece o limite descrito neste artigo. Aponte para:

Esta etapa apenas lê configuração e estado. Ela não inicia um agente.

Inicie o agente de teste da mesma forma que você inicia agentes de produção, e não com um comando construído manualmente, para que o teste exercite o caminho real. A seção Verifique o isolamento você mesmo abaixo cobre as verificações manuais do limite. Dê ao agente uma única tarefa: tentar alcançar qualquer coisa fora de seu limite, e parar e relatar assim que algo conseguir. Nomeie o limite concretamente no prompt: o host, outros contêineres, o socket do container-runtime, o serviço de metadados da nuvem, e qualquer host que não esteja na lista de permissões do proxy. Execute isso apenas sob supervisão humana próxima, em um host sem acesso à internet além da API do modelo e que você esteja preparado para reconstruir, para que um escape bem-sucedido não cause danos. Em bare metal, execute o teste dentro de uma VM descartável. Em uma VM na nuvem, use uma instância nova e destrua-a depois. Observe a sessão enquanto ela é executada. Trate qualquer sucesso como um bloqueador: corrija o host, repita o teste, e não execute engajamentos desse host até que o teste passe.

Verifique o que o agente tentou e se conseguiu sair. Procure por conexões diretas que não passaram pelo proxy, leituras de arquivos de credenciais ou endereços de metadados, uso do socket do container-runtime ou sondagens de contêineres vizinhos, escritas fora do próprio sistema de arquivos do contêiner, e tentativas de alterar as configurações ou ferramentas do próprio agente. O teste passa quando a transcrição mostra que cada um desses foi tentado e falhou pela razão que você espera. Registre, para cada um, se a sandbox ou o classificador de permissões o parou. Uma tentativa que o classificador negou nunca alcançou a sandbox, então cubra-a com as verificações manuais (veja Verifique o isolamento você mesmo abaixo). Um teste bem-sucedido é uma barra mínima, não prova de isolamento.

Confirme antes do lançamento que a tarefa pode ser concluída conforme fornecida. Alguns exemplos de tarefas que não podem ser concluídas: uma área de foco sem nada para encontrar, um destino que não é alcançável, um bug que não existe, ou uma ferramenta que a tarefa precisa que não está instalada. Sempre que você alterar sua configuração ou iniciar um novo tipo de tarefa, confirme antes do lançamento que o destino é compilado e pode ser alcançado e que o agente tem as ferramentas necessárias. Pela mesma razão, quando você revisa um lote, leia as transcrições das execuções que falharam ou não encontraram nada antes das que tiveram sucesso.

Execute essas verificações manualmente em cada host. A segunda coluna descreve a verificação para o design de referência (Docker com o runtime Kata e Firecracker). Adapte-a ao seu próprio runtime.

Esta seção descreve como a implementação de referência atende à orientação acima. A implementação não está incluída. Leia-a como um design que você pode copiar.

Cada agente é executado como claude -p dentro de sua própria microVM, ao lado do binário de destino e da fonte. A microVM é um contêiner Kata Containers apoiado pelo monitor de máquina virtual Firecracker, registrado no Docker como um runtime. As ferramentas Read, Write e Bash do agente veem apenas o sistema de arquivos e o kernel desse guest.

A conexão entre um guest e o host é deliberadamente pequena. Consiste em KVM e nos poucos dispositivos virtuais que o Firecracker emula: dispositivos de bloco para o disco do contêiner, uma interface de rede, e um canal de controle vsock que o Kata usa para iniciar processos dentro do guest. O próprio processo Firecracker é confinado no host. Ele é executado em uma "jail", que é um diretório chroot contendo apenas os arquivos dessa VM, com seu próprio namespace de montagem, o namespace de rede do contêiner, e o filtro seccomp integrado do Firecracker. É contabilizado no cgroup do contêiner. O que você confia no lado do host é KVM, Firecracker e o processo de runtime do Kata (o "shim" por contêiner que o Docker fala, que é executado como root).

O orquestrador permanece no host confiável. Ele gerencia o ciclo de vida do contêiner, transmite transcrições e move arquivos para dentro e para fora com docker exec, que o Kata serve através de seu agente dentro do guest. O iniciador inicia agentes apenas dentro dessa sandbox. Antes de qualquer agente iniciar, ele verifica se o runtime da sandbox está registrado, se /dev/kvm está presente, e se o proxy de saída está ativo, e se recusa a executar caso contrário.

O que a sandbox muda para cada superfície:

Onde cada propriedade é aplicada: a virtualização de hardware fornece o limite do kernel e do sistema de arquivos. O Read/Write/Bash do agente são executados contra o kernel do guest, e o processo Firecracker por trás dele é encarcerado e confinado com seccomp no host. A política de saída é aplicada no lado do host da interface de rede da VM, por uma ponte Docker --internal (sem rota padrão para fora) e os dois proxies nessa rede. O proxy de credenciais encaminha chamadas de modelo e nada mais. O proxy de saída recusa todo outro destino, porque sua lista de permissões está vazia a menos que você adicione a ela. O tráfego sai pela própria pilha de rede do guest; a filtragem acontece nos dois proxies.

A credencial para a API do modelo (sua chave de API, token OAuth, credencial AWS ou Google) nunca é colocada em um contêiner de agente. O orquestrador no host a lê e valida, e cada inicialização inicia um pequeno contêiner extra, o proxy de credenciais, para mantê-la. O proxy é anexado à rede interna dos agentes, e os contêineres de agente enviam suas chamadas de modelo para ele: seu CLI claude obtém o endereço do proxy como sua URL base de API, e um valor de espaço reservado fixo onde a chave ou token normalmente seria. Isso segue a melhor prática de acessar a API do modelo apenas através de um proxy, com a chave de API injetada de fora da sandbox. No design de referência, o proxy é um contêiner separado na rede dos agentes, não um processo no próprio localhost do agente. Para cada solicitação, o proxy:

Para um contêiner de agente comprometido, isso significa que não há chave, token ou arquivo de credencial para ler, copiar ou enviar para qualquer lugar. Os serviços de metadados da nuvem também são inacessíveis do contêiner. O que o contêiner ainda pode fazer é fazer chamadas de modelo através do proxy, em sua conta, enquanto a execução estiver ativa. Por esse motivo, prefira uma credencial com escopo estreito para execuções de agente e a rotacione após qualquer execução cuja transcrição mostre comportamento inesperado. O proxy registra uma linha por solicitação, com o endereço do cliente, método, caminho, status e tamanho. Ele não registra cabeçalhos ou corpos. Salve esse log quando a execução terminar (veja a seção Retenção em Monitoramento offline de transcrições de agentes).

Qualquer coisa que o agente envie para a API do modelo sai de sua rede, em corpos de solicitação que o proxy não inspeciona ou registra.

O que cada lado mantém, por rota de autenticação:

O contêiner proxy de credenciais faz parte do lado confiável da configuração. Ele é executado sob runc simples em vez do tempo de execução da sandbox, como root com todas as capacidades removidas, exceto a que precisa para ler os arquivos montados, e com um sistema de arquivos somente leitura. Ele escuta apenas em seu endereço na rede interna dos agentes e se conecta ao provedor diretamente em vez de através do proxy de saída. O orquestrador passa a credencial para o proxy em execução via docker exec. Para as rotas de arquivo de token WIF e perfil, o diretório que contém o token ou perfil é montado somente leitura no proxy, que lê o arquivo de lá. A credencial não está no ambiente do contêiner proxy ou em sua linha de comando, para que docker inspect nele mostre as montagens e não um segredo.

Inicie um proxy por lançamento e remova-o quando a execução terminar ou for interrompida. Verifique se há proxies deixados para trás por uma execução que foi interrompida e remova-os antes do próximo lançamento.

O proxy de credenciais tem dois efeitos colaterais. Primeiro, o CLI dos agentes recebe um endereço de API não padrão, portanto alguns recursos de CLI que se aplicam apenas ao endereço padrão estão desativados dentro dos contêineres de agente. Sua telemetria e verificações de atualização também são desativadas, porque não teriam rota para fora de qualquer forma. Segundo, no Vertex, o filtro de caminho do proxy é o controle principal que impede um contêiner de agente de usar o resto da API Vertex AI (veja Lista de permissões de saída). Uma verificação do escopo de IAM da chave no lançamento é uma segunda camada.

A lista de permissões do proxy de saída está vazia por padrão. Os contêineres de agente acessam a API do modelo apenas através do proxy de credenciais (veja O proxy de credenciais). Cada lançamento inicia esse proxy para o provedor que suas credenciais selecionam, portanto nada específico do provedor é armazenado na configuração da sandbox. Todo outro destino que um agente solicita através do proxy de saída, incluindo o próprio host da API do modelo, recebe um 403 e uma linha de negação em seu log. Os valores de região que selecionam os endpoints Bedrock e Vertex (AWS_REGION, CLOUD_ML_REGION) são verificados em relação a um padrão rigoroso antes de serem usados, para que um valor malformado não possa enviar a credencial para um host diferente.

Vertex tem um limite a ser observado. …aiplatform.googleapis.com serve toda a API Vertex AI, portanto uma credencial que é permitida criar trabalhos personalizados pode executar um contêiner arbitrário com saída de internet completa em seu projeto. Use dois controles contra isso. Faça o proxy de credenciais encaminhar apenas chamadas de modelo de editor em seu projeto configurado (…/publishers/anthropic/models/…:rawPredict, :streamRawPredict e :countTokens) e recuse todo outro caminho. E verifique o escopo de IAM da chave no lançamento e falhe fechado: recuse ADC de usuário gcloud, verifique uma chave de conta de serviço com testIamPermissions e recuse-a se ela contiver qualquer permissão de criação de carga de trabalho. Conceda à conta uma função personalizada que contém apenas aiplatform.endpoints.predict. O servidor de metadados, STS do Google e os endpoints de credenciais de IAM não devem ser acessíveis dos contêineres de agente.

Se os agentes precisarem acessar hosts extras, como um espelho de pacote ou um alvo no escopo, adicione-os à lista de permissões do proxy de saída como entradas host:port. Adicione apenas o que o engajamento precisa (veja Escopo e supervisão).

Não adicione o host da model-API a esta lista. Os agentes não precisam dele, porque suas chamadas de modelo passam pelo proxy de credenciais. Adicioná-lo oferece aos contêineres de agentes uma rota direta para a API, e o resto do design, incluindo o que o classificador de permissões é informado, assume que eles não têm nenhuma.

Alterar a lista de permissões significa reiniciar o proxy de saída, o que interrompe qualquer conexão de agente ativa. Faça isso entre lotes em vez de durante um, e confirme depois qual lista o proxy carregou.

Derive o endpoint do provedor da sua configuração de credenciais e ignore uma variável de URL base como ANTHROPIC_BASE_URL que está definida no host: o proxy de credenciais deve sempre encaminhar para o endpoint que as credenciais selecionam.

Esta seção coleta o que foi aprendido ao executar agentes sob Kata com Firecracker na implementação de referência. Não é um conjunto de etapas de instalação.

O design de referência precisa de uma máquina Linux física ou de uma VM que possa executar VMs:

Sua sandbox precisa de KVM em um host Linux. Docker em um Mac é executado dentro de uma VM Linux compartilhada que monta o diretório inicial do usuário e mantém o daemon do Docker, portanto não pode fornecer isolamento de hardware por agente. Se você trabalha em um Mac, execute os agentes em um host Linux com KVM (bare metal ou uma VM de nuvem com virtualização aninhada) e conduza-os via SSH. Se você construir sua própria sandbox no macOS ou Windows, consulte os hipervisores nomeados na seção Diretrizes gerais acima.

Imagens e contêineres criados no armazenamento anterior do Docker ficam invisíveis para o Docker após a mudança para o snapshotter devmapper. Eles permanecem no disco. Para vê-los novamente, coloque ambas as configurações de armazenamento em daemon.json (storage-driver e features.containerd-snapshotter) de volta ao que eram e reinicie o Docker.

Fixe a versão do Kata e verifique seu resumo antes de instalá-lo. O design de referência começa com o perfil Firecracker do Kata e fixa essas configurações em /etc/kata-containers/configuration.toml:

Os valores de kernel, image e kernel_params que vêm com a versão Kata são mantidos como estão.

Cada VM inicializa a partir dos mesmos dois arquivos, Kata os vincula em cada jail, e o jailer é iniciado como root, portanto as permissões de arquivo ordinárias não impediriam um processo Firecracker comprometido de reescrever a imagem da qual cada VM posterior inicializa. Defina o sinalizador imutável em ambos (chattr +i). Limpar esse sinalizador requer uma chamada de sistema que o filtro seccomp do Firecracker não permite, projetado para impedir até mesmo root dentro da jail de fazê-lo. Limpe o sinalizador você mesmo antes de instalar uma nova versão Kata. Em um sistema de arquivos sem suporte a chattr, use um bind mount somente leitura.

Cada VM do agente é dimensionada uma vez, na inicialização: default_memory mais o --memory do contêiner. Com uma linha de base de 4096 MiB e um limite de contêiner 4g, um agente é uma VM de 8 GiB. O host aloca essa memória à VM conforme o convidado a usa, não tudo na inicialização, mas planeje para o valor total por agente simultâneo: dez agentes em paralelo podem crescer para 80 GiB. Se o limite --memory do contêiner também limita a VM como um todo depende de como os cgroups do host estão dispostos. Verifique qual destes se aplica ao seu host:

Não confirmamos esse comportamento em todos os tipos de host. De qualquer forma, dimensione o host pelo tamanho da VM.

Cada VM obtém default_vcpus. Firecracker não pode adicionar CPUs a uma VM em execução, portanto, para destinos com uso intensivo de compilação, aumente o valor antes do lançamento; o máximo é 32 por VM.

Cada imagem e cada contêiner obtém um disco virtual de um pool fino de device-mapper, que faz backup do armazenamento de imagens. Se o pool se encher, as gravações dentro dos contêineres falham com erros de E/S ou falta de espaço. Se o sistema de arquivos que contém o pool se encher primeiro, o pool fica somente leitura e cada contêiner nele falha. Libere espaço com docker rmi e docker system prune (blocos liberados retornam ao pool). sudo dmsetup status <pool> mostra o uso. Para um host de longa duração, um pool fino LVM em um disco dedicado é o melhor layout.

Cada início de agente inicializa um kernel de convidado. Isso leva bem menos de um segundo em metal nu e alguns segundos sob virtualização aninhada, o que é pequeno em comparação com os tempos de execução do agente.

Depois de configurar uma máquina nova, esta sequência mostra que a sandbox funciona de ponta a ponta. As etapas 3 e 4 fazem chamadas de modelo reais.

Executar agentes sob Kata com Firecracker difere de executar contêineres simples nestas formas.

Firecracker não tem compartilhamento de sistema de arquivos de host, portanto Kata copia um arquivo ou diretório vinculado ao convidado quando o contêiner inicia, e mudanças posteriores no host não são vistas dentro. Isso é bom para entradas que não mudam durante uma execução, como fonte de destino, e essas podem permanecer como montagens somente leitura. Nenhum arquivo de credencial é montado ou transmitido, porque contêineres de agente não possuem nenhum (veja O proxy de credencial). Um arquivo que muda durante uma execução tem que ser escrito no contêiner pelo orquestrador, através de docker exec, e mantido atualizado. As cópias no contêiner são arquivos ordinários que um agente poderia editar, portanto, peça ao orquestrador para ler os originais no host e julgar descobertas de uma cópia que o agente em teste não pode alcançar.

As interfaces de rede de uma microVM devem existir quando a VM inicializa; Firecracker não pode adicionar uma depois. Docker, no entanto, conecta a rede de um contêiner apenas depois que o tempo de execução criou o contêiner. O design de referência contorna isso. Ele primeiro inicia um pequeno contêiner ocioso que está anexado à rede correta e executa apenas sleep, e depois inicia o agente dentro do namespace de rede desse contêiner (--network container:<name>). Kata encontra as interfaces lá na inicialização e as anexa à VM. Um complemento serve exatamente uma VM, porque Kata deixa os dispositivos de rede do lado do host da VM atrás nele, portanto crie e remova o par junto e não reutilize um complemento. Um custa um processo ocioso de aproximadamente 12 MB.

docker rm -f <agent-container> é suficiente. O orquestrador deve detectar o contêiner morto, marcar a execução como falha e remover o contêiner complementar quando desmontar a execução.

O DNS incorporado do Docker é executado no namespace de rede do lado do host e é inacessível de dentro de um guest, portanto, passe os proxies para os agentes como endereços IP e atribua um IP estático aos destinos em rede.

docker exec em um contêiner de agente se comporta normalmente; o agente do Kata dentro do guest executa o comando. docker cp para dentro ou para fora de um contêiner de agente não funciona, porque os arquivos do contêiner estão em um disco virtual dentro do guest. Use docker exec <container> cat <path> e similares.

Kata inicia o jailer com uid 0, portanto o processo Firecracker é confinado por seu chroot, namespaces, filtro seccomp e cgroup, não por um uid de usuário sem privilégios. Os dois arquivos que cada VM compartilha, o kernel do guest e a imagem, são protegidos pela flag imutável (veja Configurações do Kata).

Kata executa Firecracker através de seu runtime Go mais antigo. Kata 4.0 tornou um runtime Rust mais novo o padrão para seus outros hipervisores e descontinuou o runtime Go. O upstream diz que o runtime Go ainda recebe correções críticas de bugs e correções de CVE, e que pode ser removido não antes de Kata 5.0. O runtime Rust não lista Firecracker entre seus hipervisores, e o upstream testa sua integração com Docker principalmente com QEMU. Planeje uma migração. Quando você alterar a versão do Kata, repita Validando um novo host. Kata também pode usar Cloud Hypervisor em vez de Firecracker; a implementação de referência não testou ou endureceu essa configuração.

As mensagens do runtime do Kata, Firecracker e guest-agent vão para o journal: journalctl -t kata. Os problemas do containerd e Docker estão em journalctl -u containerd e journalctl -u docker.