Encriptação mTLS Cilium (pré-visualização pública)

A encriptação mTLS Cilium fornece encriptação e autenticação TLS (mTLS) transparentes e mútuas para o tráfego pod-to-pod no Kubernetes, sem necessidade de alterações na aplicação ou introdução de qualquer pilha de rede adicional.

Assegura que tanto as cargas de trabalho de origem como de destino são autenticadas criptograficamente antes de qualquer tráfego ser trocado. Esta abordagem permite um modelo de rede zero-trust para cargas de trabalho Kubernetes.

Toda a encriptação e autenticação acontecem abaixo da camada de aplicação, o que significa que as cargas de trabalho não precisam de ser modificadas, reconstruídas ou reiniciadas para beneficiar do mTLS.

A encriptação Cilium mTLS para AKS faz parte do conjunto de funcionalidades Advanced Container Networking Services (ACNS ), e a sua implementação baseia-se no Cilium.

Importante

Os recursos de pré-visualização do AKS estão disponíveis numa base de autosserviço e adesão voluntária. As visualizações prévias são fornecidas "como estão" e "conforme disponíveis" e são excluídas dos contratos de nível de serviço e da garantia limitada. As versões de teste do AKS são parcialmente cobertas pelo suporte ao cliente numa base de melhor esforço. Assim sendo, estas funcionalidades não se destinam ao uso em produção. Para obter mais informações, consulte os seguintes artigos de suporte:

Arquitetura

A um nível geral, o Cilium mTLS protege o tráfego combinando emissão de identidade, interceção transparente de tráfego e aplicação da encriptação ao nível da carga de trabalho.

Cada carga de trabalho recebe uma identidade criptográfica derivada dos atributos Kubernetes, como namespace e ServiceAccount. Quando o tráfego TCP pod-to-pod é iniciado, o tráfego é interceptado de forma transparente ao nível do nó. O tráfego é então autenticado e encriptado usando TLS mútuo antes de ser encaminhado para a carga de trabalho de destino.

O sistema é composto por três componentes cooperantes:

SPIRE - Fornece identificação da carga de trabalho e emissão de certificados.
ztunnel - Aplica o mTLS no plano de dados.
Cilium - Instala regras iptables que redirecionam o tráfego de saída para o ztunnel na porta 15001.

Juntos, estes componentes garantem que a autenticação e a encriptação ocorrem de forma transparente e consistente em todo o cluster.

Identidade e modelo de autenticação

O Cilium mTLS utiliza autenticação mútua com base na identidade de 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 ligação:

O ztunnel de origem recupera um SVID válido para a tarefa.
O ztunnel de destino valida a identidade apresentada.
Ambos os lados completam a verificação mútua antes de o tráfego ser autorizado a circular.

As decisões de autenticação baseiam-se na identidade da carga de trabalho e não na localização da rede. Este design assegura que:

Só cargas de trabalho autenticadas podem comunicar.
A identidade mantém-se consistente em reagendamento e escalabilidade.
A confiança não depende do endereçamento IP ou da topologia da rede.

Fluxo de encriptação

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

Tráfego intercetado dentro do namespace da rede 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 da aplicação são encriptados antes da transmissão.
O ztunnel de destino desencripta o tráfego e entrega-o ao pod alvo.

Cada pacote de um pod inscrito é encriptado. Não existe janela de texto simples, nem pacotes iniciais descartados. A ligação é mantida em linha pelo ztunnel até que o túnel mTLS seja estabelecido, depois o tráfego flui bidirecionalmente através de um túnel HBONE (HTTP/2 CONNECT).

Componentes centrais

SPIRE (identidade e confiança)

O SPIRE (SPIFFE Runtime Environment) é responsável pela gestão de identidade de carga de trabalho e de certificados. O SPIRE tem dois componentes principais: o servidor SPIRE e o agente SPIRE.

O servidor SPIRE atua como a Autoridade Certificadora (CA) do cluster. Emite certificados X.509 (SVIDs) de curta duração apenas para cargas de trabalho autorizadas a receber identidades. Utiliza atestação nativa do Kubernetes, associando identidade a atributos como namespace e ServiceAccount em vez de propriedades de rede como endereços IP.

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

O SPIRE garante que a identidade de cada carga de trabalho é:

Criptograficamente verificável.
Emitido e rodado automaticamente.
Vinculado a primitivas Kubernetes, não a endereços IP.
Estável entre reinicializações de pods e eventos de reagendamento.

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

Ztunnel (plano de dados mTLS)

O Ztunnel é um proxy leve em recursos de Camada 4 no nível de nó, responsável por impor o mTLS entre cargas de trabalho. Funciona como um DaemonSet, com uma instância por nó, eliminando a necessidade de proxys sidecar por cada pod.

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

A Ztunnel faz cumprir as seguintes garantias:

Ambos os lados de uma ligação devem apresentar certificados de carga de trabalho válidos.
Os certificados são verificados contra o domínio de confiança do cluster.
O tráfego é sempre encriptado na linha.
Não é permitido usar texto em formato simples para cargas de trabalho registadas.

Ao centralizar a aplicação do mTLS ao nível do nó, o ztunnel oferece fortes propriedades de segurança sem aumentar a sobrecarga operacional em cada pod.

Cilium (regras de redirecionamento e inscrição em pods)

A Cilium é responsável por tornar o mTLS transparente às aplicações.

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

O Cilium também passa metadados da carga de trabalho, como o UID do Pod, para o ztunnel e integra-se com o Operador Cilium para registar as identidades das cargas de trabalho com o SPIRE.

Do ponto de vista da aplicação, a comunicação continua usando sockets TCP padrão. A encriptação e autenticação são aplicadas inteiramente abaixo da camada de aplicação, não exigindo alterações de código.

Âmbito e limites de confiança

Inscrição em espaços de nomes

O mTLS do Cilium é opcional e tem âmbito ao nível do namespace. Um namespace deve ser explicitamente identificado para permitir a aplicação do mTLS. Uma vez ativados, todos os pods dentro desse espaço de nomes estão sujeitos a autenticação e encriptação obrigatórias.

Os pods em namespaces não registados não são afetados. Este design permite a implementação incremental e a adoção progressiva em vários ambientes.

Modelo de fiscalização

A encriptação é aplicada apenas quando ambos os pods estão inscritos. O tráfego entre cargas de trabalho inscritas e não inscritas continua em texto simples sem causar problemas de conectividade ou falhas graves.

Fonte	Destino	Result
Inscrito	Inscrito	Encriptado (mTLS sobre HBONE)
Inscrito	Não inscritos	Passagem de texto simples
Não inscritos	Inscrito	Texto simples (capturado pelo ztunnel, mas não encriptado)
Não inscritos	Não inscritos	Caminho de dados normal do Cilium (sem envolvimento do ztunnel)

Considerações e limitações

A funcionalidade está disponível apenas em clusters que utilizam Azure CNI, alimentado pela Cilium, com Advanced Container Networking Services (ACNS) ativado.
O mTLS está ativado ao nível do namespace. Todos os pods num namespace inscrito participam no protocolo mTLS. O opt-in ou opt-out ao nível do pod não é suportado.
O Cilium mTLS protege atualmente o tráfego pod-a-pod baseado em TCP. Atualmente, não encripta nem autentica outros protocolos, incluindo o UDP.
Na fase atual, a aplicação da política de rede L4/L7 não é suportada com mTLS.
Não podes levar uma CA personalizada. A SPIRE atua como a Autoridade Certificadora do cluster e gere a emissão e rotação dos certificados.
Ativar tanto o mTLS como o WireGuard no mesmo cluster não é suportado.
Ativar simultaneamente a encriptação mTLS tanto do Istio como do Cilium não é suportado.
A encriptação mTLS para tráfego cross-cluster não é suportada.
A integração requer suporte ao iptables no kernel e não pode ser usada em ambientes que não suportem iptables (como alguns tempos de execução mínimos de containers).
Pods sem um caminho de namespace de rede (como pods conectados à rede do host) não podem ser inscritos no ztunnel e são excluídos durante o processo de inscrição.

Preços