Automatizando a Infraestrutura de Confidential Containers (CoCo) com Kyverno

Automatizando a Infraestrutura de Confidential Containers (CoCo) com Kyverno

Implementar Confidential Containers (CoCo) eleva a segurança de workloads, mas impõe um alto ônus operacional aos times de desenvolvimento. Este artigo analisa como o uso do Kyverno, como motor de Policy as Code, resolve esse desafio. A conclusão é que o Kyverno automatiza a configuração de infraestrutura (injecções de initdata e runtimeClass) sem comprometer o modelo zero-trust, pois a verificação final de segurança permanece ancorada no processo de remote attestation do runtime, garantindo escalabilidade e robustez.

Confidential Containers (CoCo) adiciona uma camada de segurança crítica para workloads conteinerizados, especialmente em ambientes onde partes da infraestrutura não são inerentemente confiáveis. No entanto, o deployment desses workloads exige que os times gerenciem detalhes de infraestrutura complexos, propensos a erros. Ao usar o Kyverno como Policy as Code engine, times de plataforma podem automatizar boa parte dessa orquestração específica do CoCo, melhorando a experiência do desenvolvedor (DevEx) enquanto preservam um modelo zero-trust robusto.

Entendendo os Confidential Containers (CoCo)

O Confidential Containers (CoCo) é uma iniciativa open-source focada em proteger workloads em ambientes não confiáveis.

O princípio fundamental do modelo de confiança do CoCo é que o control plane do Kubernetes é explicitamente não confiável. Consequentemente, qualquer especificação de pod fornecida pelo control plane é considerada suspeita e deve ser verificada pelo ambiente de runtime antes de ser executada. Esse processo de verificação é tipicamente realizado através de remote attestation.

O que um workload habilitado para CoCo exige?

Um pod destinado a rodar em um ambiente CoCo precisa das seguintes definições em sua especificação:

• runtimeClass (normalmente obrigatório): Especifica o ambiente de runtime confidencial necessário.
• initdata (normalmente obrigatório): Fornece a configuração de bootstrap para o ambiente confidencial, incluindo detalhes do servidor de remote attestation, políticas de imagem de container e políticas do kata-agent. É crucial para estabelecer a confiança e é verificado via remote attestation. Ref: https://confidentialcontainers.org/docs/features/initdata/
• sealed secrets (Opcional): Referências a segredos que serão disponibilizados apenas após o sucesso da remote attestation. Ref: https://confidentialcontainers.org/docs/features/sealed-secrets/
• attestation initcar (Opcional): Container inicial usado para auxiliar no processo de attestation.
• mTLS sidecar (Opcional): Sidecar para garantir comunicação segura.

Desafios práticos de deployment

Os requisitos técnicos do CoCo introduzem fricção para os times:

1. Sobrecarga de infraestrutura para desenvolvedores: Times de aplicação acabam gerenciando detalhes complexos, o que gera gargalos no ciclo de entregas.
2. Falhas no admission e startup dos pods: initdata malformado ou campos incorretos nos manifests podem interromper a criação dos workloads prematuramente.

A Solução: Automatizando com Kyverno

Para resolver isso, uma plataforma moderna precisa de: injeção automática das configurações necessárias e validação proativa (shift-left) das entradas de configuração do CoCo.

O Kyverno, como engine de políticas nativo do Kubernetes, pode realizar mutações e validações no momento do admission, garantindo que os elementos de infraestrutura do CoCo sejam aplicados de forma consistente e rejeitando configurações inválidas precocemente.

O paradoxo da confiança: Kyverno em um control plane não confiável

O Kyverno roda dentro do control plane do Kubernetes, que, pelo modelo do CoCo, é não confiável. Como podemos confiar nele?

A chave é que o Kyverno é usado para automação operacional, não para estabelecer a confiança (root of trust). Ele serve apenas para facilitar o deployment. A responsabilidade final pela verificação permanece com o dono da aplicação, via remote attestation, incluindo:

• Verificação de container images (uso de imagens assinadas) - https://confidentialcontainers.org/docs/features/signed-images/
• Verificação da especificação do pod via kata agent policy - https://github.com/kata-containers/kata-containers/blob/main/docs/how-to/how-to-use-the-kata-agent-policy.md

O Kyverno melhora a ergonomia do deployment, enquanto o attestation do CoCo e as runtime policies continuam como os pontos de decisão de segurança.

Fig: Visão geral da integração entre Kyverno e Confidential Containers.

Como implementar um fluxo de deployment automatizado?

Implementar essa solução exige segregação clara de duties entre os times:

• Time de Plataforma e Infraestrutura: Responsável pelo gerenciamento do Kubernetes e pela aplicação das políticas via Kyverno nos namespaces.
• Time de App Security: Gerencia as credenciais e o servidor de remote attestation. Provê o initdata exigido.
• Time de Desenvolvimento: Responsável pelo deployment dos manifests, que serão "decorados" automaticamente pelas políticas do Kyverno.

Para um guia prático, consulte a documentação da comunidade CoCo e a biblioteca de políticas do Kyverno, filtrando pela tag "Confidential Computing".

Processo de Deployment e Attestation

1. Configuração: O time de Security provê o initdata necessário.
2. Enforcement de Política: O desenvolvedor aplica o manifest. O Kyverno detecta e automaticamente injeta o initdata e a runtimeClass necessários no pod.
3. Runtime Attestation: Antes do pod rodar, o runtime dispara a remote attestation para verificar o initdata. Qualquer modificação indevida feita pelo control plane será detectada aqui.
4. Entrega Condicional de Segredos: Credenciais só são liberadas após o sucesso do attestation.

Conclusão

O Confidential Containers fortalece a segurança, mas o modelo zero-trust pode complicar a operação. O Kyverno reduz o gap operacional automatizando a injeção de configurações e validando inputs antes mesmo da aceitação no cluster. Para times brasileiros, isso significa escala sem abrir mão da segurança, permitindo que times de engenharia foquem no que traz valor ao negócio, enquanto a fundação da infraestrutura permanece segura e conforme.

Perguntas Frequentes

• O Kyverno não compromete o modelo de 'zero-trust' do CoCo?
  Não. O Kyverno atua na automação operacional (mutação e validação de manifestos), não na decisão de confiança. A segurança real e a validação final ocorrem via remote attestation realizada pelo runtime do CoCo, que verifica a integridade de qualquer configuração injetada.

• Quais são os maiores desafios operacionais ao adotar CoCo?
  O principal desafio é a sobrecarga cognitiva sobre os times de aplicação, que precisam gerenciar detalhes complexos de infraestrutura como initdata e runtimeClass. Erros nessas configurações levam a falhas comuns de admission e problemas na inicialização de pods.

• Como posso começar a usar essa abordagem?
  Aproveite a separação de responsabilidades entre times de Plataforma, Security e Desenvolvimento. Utilize políticas do Kyverno (disponíveis na biblioteca oficial com a tag 'Confidential Computing') para injetar automaticamente as configurações necessárias nos namespaces das aplicações.

---

Artigo originalmente publicado por Shuting Zhao, Project Maintainer (Nirmata) em Cloud Native Computing Foundation.