Criptografia Cilium mTLS (versão prévia pública)

A criptografia Cilium mTLS fornece criptografia e autenticação TLS (mTLS) transparentes e mútuas para tráfego de pod a pod no Kubernetes sem exigir alterações de aplicativo ou introduzir qualquer pilha de rede extra.

Ele garante que as cargas de trabalho de origem e de destino sejam autenticadas criptograficamente antes que qualquer tráfego seja trocado. Essa abordagem permite um modelo de rede de confiança zero para cargas de trabalho do Kubernetes.

Toda a criptografia e autenticação ocorrem abaixo da camada do aplicativo, o que significa que as cargas de trabalho não precisam ser modificadas, recriadas ou reiniciadas para se beneficiar do mTLS.

A criptografia Cilium mTLS para AKS faz parte do conjunto de recursos de ACNS (Serviços Avançados de Rede de Contêiner) e sua implementação é baseada no Cilium.

Importante

As funcionalidades em versão preliminar do AKS estão disponíveis de forma optativa e por autoatendimento. As versões prévias são fornecidas “no estado em que se encontram” e “conforme disponíveis” e são excluídas dos contratos de nível de serviço e da garantia limitada. As versões prévias do AKS são parcialmente cobertas pelo suporte ao cliente em uma base de melhor esforço. Dessa forma, esses recursos não são destinados ao uso em produção. Para obter mais informações, consulte os seguintes artigos:

Arquitetura

Em um alto nível, o Cilium mTLS protege o tráfego combinando emissão de identidade, interceptação de tráfego transparente e imposição de criptografia no nível da carga de trabalho.

Cada carga de trabalho recebe uma identidade criptográfica derivada de atributos do Kubernetes, como namespace e ServiceAccount. Quando o tráfego TCP entre pods é iniciado, o tráfego é interceptado de forma transparente no nível do nó. Em seguida, o tráfego é autenticado e criptografado usando TLS mútuo antes de ser encaminhado para a carga de trabalho de destino.

O sistema é composto por três componentes que cooperam:

SPIRE – Fornece identidade de carga de trabalho e emissão de certificado.
ztunnel – impõe mTLS no plano de dados.
Cilium – Instala regras de iptables que redirecionam o tráfego de saída para o ztunnel na porta 15001.

Juntos, esses componentes garantem que a autenticação e a criptografia ocorram de forma transparente e consistente em todo o cluster.

Modelo de identidade e autenticação

O Cilium mTLS usa autenticação mútua com base na identidade da carga de trabalho SPIFFE.

Cada carga de trabalho recebe uma identidade SPIFFE (SVID) derivada de:

Namespace do Kubernetes
Kubernetes ServiceAccount

Quando uma carga de trabalho inicia uma conexão:

O ztunnel de origem recupera um SVID válido para a carga de trabalho.
O ztunnel de destino valida a identidade apresentada.
Ambos os lados concluem a verificação mútua antes que o tráfego seja permitido fluir.

As decisões de autenticação são baseadas na identidade da carga de trabalho em vez do local da rede. Esse design garante que:

Somente cargas de trabalho autenticadas podem se comunicar.
A identidade permanece consistente durante o reagendamento e o escalonamento.
A confiança não depende do endereçamento IP ou da topologia de rede.

Fluxo de criptografia

Após a autenticação bem-sucedida, o tráfego é protegido usando TLS mútuo.

Tráfego interceptado dentro do namespace de rede do pod e redirecionado para a instância local do ztunnel.
O ztunnel de origem inicia uma sessão mTLS com o ztunnel de destino.
Os certificados são trocados e validados.
Os dados do aplicativo são criptografados antes da transmissão.
O ztunnel de destino descriptografa o tráfego e o entrega para o pod de destino.

Cada pacote de um pod registrado é criptografado. Não há janela de texto simples e nenhum primeiro pacote descartado. A conexão é mantida em espera pelo ztunnel até que o túnel mTLS seja estabelecido e, em seguida, o tráfego flui bidirecionalmente por meio de um túnel HBONE (HTTP/2 CONNECT).

Componentes principais

SPIRE (identidade e confiança)

O SPIRE (Ambiente de Execução do SPIFFE) é responsável pelo gerenciamento de identidade e certificados de carga de trabalho. O SPIRE tem dois componentes principais: o servidor SPIRE e o agente SPIRE.

O servidor SPIRE atua como a AC (Autoridade de Certificação) do cluster. Ele emite certificados X.509 de curta duração (SVIDs) apenas para cargas de trabalho que têm permissão para receber identidades. Ele usa o atestado nativo do Kubernetes, vinculando a identidade a atributos como o namespace e o ServiceAccount, em vez de a propriedades de rede, como endereços IP.

Em cada nó, o agente SPIRE é responsável por atestar o nó ao servidor SPIRE e por recuperar certificados em nome de cargas de trabalho locais. As cargas de trabalho só se comunicam com o agente SPIRE e nunca diretamente com o servidor SPIRE.

O SPIRE garante que cada identidade de carga de trabalho seja:

Verificável criptograficamente.
Emitido e rotacionado automaticamente.
Associado a primitivos do Kubernetes, não a endereços IP.
Estável entre reinicializações de pods e eventos de reprogramação.

Essa base de identidade permite decisões de confiança fortes e independentes de topologia.

Ztunnel (plano de dados mTLS)

O Ztunnel é um proxy de camada 4 leve em nível de nó responsável por impor mTLS entre cargas de trabalho. Ele é executado como um DaemonSet, com uma instância por nó, eliminando a necessidade de proxies auxiliares por pod.

Quando uma carga de trabalho inicia uma conexão TCP, o ztunnel estabelece uma sessão TLS mutuamente autenticada com a instância do ztunnel do nó par. Ele usa certificados obtidos do SPIRE para autenticar ambos os lados da conexão antes de permitir que o tráfego flua.

O Ztunnel impõe as seguintes garantias:

Ambos os lados de uma conexão devem apresentar certificados de carga de trabalho válidos.
Os certificados são verificados no domínio de confiança do cluster.
O tráfego é sempre criptografado na transmissão.
Nenhum fallback de texto sem formatação é permitido para cargas de trabalho registradas.

Centralizando a aplicação de mTLS no nível do nó, o ztunnel oferece fortes propriedades de segurança sem aumentar a carga operacional por pod.

Cilium (regras de redirecionamento e inscrição de pod)

O Cilium é responsável por tornar o mTLS transparente para aplicativos.

Quando um namespace é rotulado com "io.cilium/mtls-enabled=true", o agente do Cilium registra todos os pods nesse namespace. Ele insere o namespace de rede de cada pod e instala regras de iptables que redirecionam o tráfego de saída para o ztunnel na porta 15001.

O Cilium também passa metadados de carga de trabalho, como o Pod UID, para o ztunnel e integra-se ao Operador Cilium para registrar identidades de carga de trabalho com o SPIRE.

Do ponto de vista do aplicativo, a comunicação continua usando soquetes TCP padrão. A criptografia e a autenticação são impostas inteiramente abaixo da camada do aplicativo, não exigindo nenhuma alteração de código.

Limites de escopo e confiança

Registro de namespace

O Cilium mTLS é opt-in e tem escopo no nível do namespace. Um namespace deve ser rotulado explicitamente para habilitar a imposição do mTLS. Uma vez habilitados, todos os pods dentro desse namespace estão sujeitos à autenticação e criptografia obrigatórias.

Pods em namespaces não registrados não são afetados. Esse design permite a distribuição incremental e a adoção em etapas entre ambientes.

Modelo de imposição

A criptografia é aplicada somente quando ambos os pods estão registrados. O tráfego entre cargas de trabalho registradas e não registradas continua em texto não criptografado sem causar problemas de conectividade ou falhas difíceis.

Fonte	Destino	Resultado
Inscrito	Inscrito	Criptografado (mTLS via HBONE)
Inscrito	Não registrado	Passagem de texto sem formatação
Não registrado	Inscrito	Texto sem formatação (capturado por ztunnel, mas não criptografado)
Não registrado	Não registrado	Datapath normal do Cilium (sem envolvimento de ztunnel)

Considerações e limitações

O recurso está disponível apenas em clusters usando o CNI do Azure alimentado pelo Cilium com ACNS (Serviços Avançados de Rede de Contêiner) habilitado.
O mTLS está habilitado no nível do namespace. Todos os pods em um namespace registrado participam do mTLS. Não há suporte para aceitação ou recusa no nível do pod.
Atualmente, o Cilium mTLS protege o tráfego entre pods baseado em TCP. No momento, ele não criptografa ou autentica outros protocolos, incluindo UDP.
Na fase atual, não há suporte para a imposição da política de rede L4/L7 com mTLS.
Você não pode utilizar uma autoridade certificadora personalizada. A SPIRE atua como a Autoridade de Certificação do cluster e gerencia a emissão e rotação de certificados.
Não há suporte para habilitar o mTLS e o WireGuard no mesmo cluster.
Não há suporte para habilitar a criptografia Istio e Cilium mTLS.
Não há suporte para criptografia mTLS para tráfego entre clusters.
A integração requer suporte a iptables no kernel e não pode ser usada com ambientes que não dão suporte a iptables (como alguns runtimes mínimos de contêiner).
Pods sem um caminho para o namespace de rede (como pods em rede de host) não podem ser registrados no ztunnel e são excluídos durante o processo de registro.

Preços