Fortanix integra atestação de hardware ao Confidential Containers do Kubernetes

O que a Fortanix anunciou em 31 de outubro

A Fortanix anunciou em 31 de outubro suporte a Confidential Containers (CoCo) dentro da sua plataforma Confidential AI↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI →. A integração conecta a atestação de workloads no Kubernetes↳Kubernetes18 conteúdosGerenciamento de infraestrutura multicloud com Kubernetes proporciona otimização e economiaDevSecOps · set 2021Azure Kubernetes Services – AKS: referências gratuitas e dicas para solução de problemas comunsDevSecOps · abr 2019Kubernetes em produção: o que ninguém te conta e você aprende tarde demaisDev (Back & Front) · abr 2026Ver tudo em DevSecOps → à liberação de chaves de criptografia: só pods que cumprem a política de segurança conseguem decifrar modelos e dados sensíveis dentro de ambientes de execução confiáveis baseados em hardware, os TEEs.

Segundo a Fortanix, o suporte já está disponível, e o guia de implantação da empresa documenta a instalação de um Helm chart próprio para o CoCo. A companhia também disse estar desenvolvendo plugins open-source para o projeto, sem detalhar repositórios ou versões.

Como o Confidential Containers isola a carga de trabalho

CoCo é um projeto da Cloud Native Computing Foundation que roda pods do Kubernetes dentro de máquinas virtuais confidenciais, apoiadas em TEEs de hardware. A diferença para um container comum é onde mora a isolação: em vez de depender do sistema operacional do host, a VM confidencial usa proteções de hardware para criptografar a memória e restringir o acesso à carga de trabalho enquanto ela está em execução.

Isso protege dado em uso, não só em repouso ou em trânsito, e permite rodar workloads sensíveis em infraestrutura compartilhada. Mas a proteção ainda depende de confiar no software que roda dentro do guest e de configurar corretamente a atestação e a liberação de chaves, o que não é trivial.

No desenho do CoCo, o processo de puxar e descompactar a imagem do container acontece dentro do guest confidencial. Um componente chamado Attestation Agent coleta evidências de hardware, e o Confidential Data Hub só obtém os segredos depois que essa evidência é verificada.

Onde entram o CCM e o DSM

O material técnico da Fortanix descreve plugins que ligam workloads CoCo a dois serviços da plataforma:

• Confidential Computing Manager (CCM): verifica se o ambiente de execução é legítimo.
• Data Security Manager (DSM): só libera chaves para ambientes que o CCM já verificou.

No fluxo descrito pela empresa, se a atestação falha, a chave simplesmente permanece no DSM e o workload não consegue decifrar o modelo ou os dados protegidos. As notas de release do CCM de 17 de setembro de 2026 já haviam adicionado registro de aplicações CoCo para AMD Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) e Intel Trust Domain Extensions (TDX), as duas tecnologias de TEE mais comuns em nuvem pública hoje.

Com atestação e gestão de chaves em uma única plataforma, as equipes podem adotar o CoCo padrão sem precisar construir a camada de confiança sozinhas.

Anuj Jaiswal, chief product officer na FortanixWith attestation and key management in one platform, teams can adopt standard CoCo without building the trust layer themselves.

A GPU também precisa provar que é confiável

Para cargas de IA, a Fortanix diz que o CCM consegue atestar processador e GPU juntos, uma checagem que depende de como o cluster é configurado. O guia de implantação para Intel TDX expõe duas opções:

1. Required: o CCM valida a evidência da GPU por meio do serviço de atestação da NVIDIA.
2. Ignored: o CCM só checa se a evidência existe, mas descarta o resultado da validação.

Essa escolha importa na prática: um cluster configurado com Ignored passa a sensação de atestação de GPU sem de fato barrar hardware não confiável. O mesmo guia também avisa que o Helm chart da Fortanix para CoCo não configura firmware do host nem parâmetros de kernel, etapas que precisam ser feitas antes, manualmente.

Já existia atestação aberta: o papel do Trustee

Atestação e liberação condicional de segredos não são exclusividade da Fortanix: já existem nos componentes Trustee, que são open source↳Open source71 conteúdosComo o Open Source Está Liberando o Poder da Automação para TodosDev (Back & Front) · out 2025Código aberto: programadores criam software da NASA sem saberDev (Back & Front) · abr 2021N8N: O que é a ferramenta open source que está revolucionando a automação em TI?Dev (Back & Front) · dez 2025Ver tudo em Dev (Back & Front) → dentro do próprio projeto CoCo. O Trustee separa a avaliação de evidências da autorização de recursos.

Seu serviço de atestação compara as alegações da plataforma com valores de referência, e o Key Broker Service aplica uma política definida pelo usuário antes de liberar segredos, seja de armazenamento local, de um plugin ou de um key store externo. Uma atestação bem-sucedida, por si só, não libera nada: a política ainda precisa autorizar o pedido. O Trustee também aceita evidência de GPU vinculada ao relatório de atestação do processador.

Como alternativa gerenciada fora do CoCo, a Microsoft oferece o Azure Secure Key Release no Key Vault Premium e no Managed HSM, integrado à Azure Attestation; ele libera chaves exportáveis, não segredos ou certificados genéricos.

Nem tudo é coberto: os limites da atestação

O kernel do guest e os processos auxiliares do pod ficam dentro do limite de confiança, então a equipe também precisa confiar neles. A documentação do modelo de confiança do CoCo é clara: as medições de hardware normalmente cobrem o ambiente do guest, e a verificação do container é uma etapa separada.

O mesmo documento avisa que uma aplicação dentro do enclave ainda pode expor uma interface externa perigosa, e que o modelo exclui explicitamente proteção contra negação de serviço e ataques de canal lateral de hardware. Em outras palavras: atestação comprova que o ambiente é o esperado, não que a aplicação de IA que roda dentro dele trata os dados com segurança.

O que muda pra quem containeriza modelos em produção

Para times que já rodam Kubernetes multi-tenant e precisam colocar modelos proprietários ou dados sensíveis em clusters compartilhados, a proposta da Fortanix reduz trabalho de integração: em vez de montar manualmente a ponte entre o Trustee (ou outro mecanismo de atestação) e um key management próprio, a empresa empacota isso como serviço com suporte 24x7, hospedado, on-premises ou air-gapped.

Mas a decisão de configuração continua sendo do time de plataforma. Rodar com Ignored na validação de GPU, por exemplo, destrava mais hardware mas enfraquece exatamente a garantia que o CoCo promete entregar. Antes de declarar um cluster "confidencial", vale a pena auditar:

• Qual flag de validação de GPU está ativa (Required ou Ignored);
• Se firmware do host e parâmetros de kernel foram endurecidos manualmente, já que o Helm chart não faz isso sozinho;
• Se a política de liberação de chaves (via DSM, Trustee ou Azure Secure Key Release) cobre negação de serviço e canais laterais como riscos à parte, não resolvidos pela atestação.

A mensagem de fundo, tanto no material da Fortanix quanto na documentação do próprio CoCo, é a mesma: atestação resolve "este é o ambiente certo", mas não resolve "este código trata os dados com segurança". Para equipes que avaliam colocar inferência de modelos em TEEs, essa distinção decide onde termina a responsabilidade da plataforma e onde começa a da aplicação.

Fonte: InfoQ