Fixe o OpenZiti na v2.0.6 ou mais recente na linha 2.0, e não trate uma tag de pré-lançamento como o pin do cliente

Fixe o OpenZiti na v2.0.6 ou mais recente na linha 2.0, e não trate uma tag de pré-lançamento como o pin do cliente

A frase que um MSP ouve é: «temos um overlay zero trust, por isso a rede plana desapareceu». A resposta é que o overlay é um plano de controlo que continua a ter de ser inventariado, fixado numa versão e protegido. Não é um slogan que acaba com as janelas de alteração. O projeto em causa é o OpenZiti, repositório openziti/ziti, com licença Apache-2.0, 4417 estrelas e 276 forks no GitHub a 4 de outubro de 2026 e página principal em openziti.io. São contagens, não uma afirmação de popularidade para lá do número.

A fixação da versão vem logo a seguir. A versão completa mais recente da linha 2.0 é a v2.0.6, publicada a 18 de setembro de 2026. Existem também a v2.0.7 (25 de setembro) e a v2.0.8 (8 de outubro), e ambas continuam marcadas como pré-lançamentos.

Segue-se o que «overlay zero trust programável» pode significar: serviços encaminhados por identidade, um controlador, routers de periferia e identidades registadas. E o que o OpenZiti não é, face a seis outros produtos que resolvem trabalhos diferentes. O conselho de manutenção fica por «aplicar uma versão fixada», e os seis controlos defensivos não acrescentam detalhes de ataque.

A frase sobre funcionalidades que este artigo usa vem da descrição do repositório e de nada mais: o projeto principal do OpenZiti disponibiliza os executáveis de uma rede programável e totalmente zero trust. Os tópicos do repositório incluem overlay, zero-trust e ZTNA, o ramo predefinido é o main e a linguagem principal é Go. Aqui não se vende como facto nenhuma topologia de alta disponibilidade, nenhum valor de débito nem nenhum número de clientes. O diagrama de como um cliente ligou os seus controladores é o registo de conceção desse cliente, não uma afirmação que esta página possa tirar de um número de estrelas.

Os objetos que um MSP continua a ter de nomear são controladores, routers de periferia e identidades registadas, incluindo uma malha de controladores HA, se o cliente tiver uma. São nomes para uma exportação de inventário. Não são um guia de instalação, nem uma topologia para copiar, nem a promessa de que todos os ambientes têm a malha. Se o cliente não tiver um segundo controlador, o inventário di-lo. Uma linha HA vazia é um facto. Um segundo controlador presumido não é.

«Encaminhado por identidade» é a frase para o comprador, e é estreita. Um serviço é alcançado através de uma identidade registada e de uma política, não porque o anfitrião está na LAN do cliente. Essa é a diferença que um overlay pode reivindicar aqui. Não é uma afirmação de que os erros de configuração sejam impossíveis. Uma política demasiado ampla, uma identidade nunca revogada ou um router administrado onde não deveria continuam a ser falhas operacionais comuns. O overlay muda a pergunta de «que sub-rede» para «que identidade e que política». Não elimina a pergunta.

As estrelas são uma contagem, e fica-se por aí. As 4417 estrelas de 4 de outubro de 2026 não são uma avaliação de segurança, nem um contrato de suporte, nem uma versão fixada. O repositório recebe push com frequência; o último antes deste artigo foi a 8 de outubro de 2026. Isso diz que o projeto se mexe. Não diz que tag um cliente deve executar.

A licença é Apache-2.0, tal como o GitHub a indica. Uma licença informa o comprador sobre os termos de direitos de autor. Não lhe diz que versão é segura para uma janela de alteração, e não substitui a versão fixada.

A página de versões lê-se melhor como uma lista curta do que como uma folha de cálculo de digests. A v2.0.6 (18 de setembro de 2026) é uma versão completa. A v2.0.7 (25 de setembro) e a v2.0.8 (8 de outubro) são pré-lançamentos. A v1.6.21 (18 de setembro) e a v1.5.18 (22 de setembro) são versões completas nas linhas mais antigas, e a v2.0.5 (15 de setembro) é a versão completa anterior da 2.0. Cada tag fica dentro da sua linha. Uma tag 1.6 não passa a ser «mais recente do que a 2.0» por ter sido publicada mais tarde nesse dia, e uma tag 2.0 não encerra uma linha de manutenção 1.5 só por existir.

A regra de fixação é uma frase que um MSP pode repetir. Na linha 2.0, não descer abaixo da v2.0.6, não executar um latest flutuante e não promover a v2.0.7 nem a v2.0.8 enquanto estiverem marcadas como pré-lançamentos. Um cliente que ainda está na 1.6 fica numa tag 1.6 revista (a mais recente é a v1.6.21) até uma migração planeada, não porque exista uma tag 2.0. «Basta usar a mais recente» entre 1.5, 1.6 e 2.0 é a instrução que este artigo recusa. As linhas de manutenção existem para que uma migração planeada seja uma migração, com um ticket, e não um acidente da ordem de ordenação.

As notas de versão da v2.0.6, da v2.0.7 e da v2.0.8 descrevem correções de erros e atualizações ou backports de componentes. A mensagem de segurança é curta: o projeto publica correções e o MSP aplica uma versão fixada depois de uma janela de alteração. Quem quiser a lista de problemas pode abrir a página de versões.

Versões anteriores de 2026, em agosto, também incluíam correções de segurança do lado do controlador e dos routers, com os avisos de segurança listados nas respetivas notas de versão. O conselho prático não muda: fixar uma versão atual e revista, e tratar um aviso de segurança como motivo para atualizar dentro do planeamento.

O Headscale é um servidor de coordenação para outra família de overlays. Este artigo não compara listas de funcionalidades com ele. Juntar os dois numa única história de reforço de segurança esconderia a que plano de controlo o ticket se refere de facto.

O Linkerd2 é um service mesh com um plano de dados baseado em proxies. O OpenZiti, tal como é tratado aqui, é um overlay de identidade. Este não é um artigo sobre sidecars de malha, e uma política de sidecar não é a versão fixada de um controlador de overlay. Um MSP pode usar ambos. Usar ambos não é o mesmo que dizer «um substitui o outro».

O Tetragon é aplicação de políticas em tempo de execução e observabilidade, noutro projeto. Não é esta fixação. Um sensor que vigia um nó não escolhe a tag do OpenZiti, e uma tag do OpenZiti não se torna uma política de execução só porque as duas palavras podem aparecer no mesmo diapositivo de arquitetura.

O Gatekeeper e o Kyverno são admissão de políticas de cluster. Um overlay zero trust não substitui uma política de admissão do Kubernetes, e uma política de admissão não fixa a versão de um overlay. Os objetos são diferentes: um admite ou recusa pedidos de API num cluster, o outro encaminha identidades registadas para serviços. Tratá-los como substitutos é a forma de uma janela de alteração perder ao mesmo tempo a tag do overlay e as restrições de admissão.

O Trivy, o Prowler, o Grype e o Syft são scanners e ferramentas SBOM. Um resultado de análise não é uma decisão de versão para um overlay, e este artigo não pede emprestadas as suas versões para enfeitar a fixação do OpenZiti.

Um MSP pode usar vários. O erro do comprador é tratá-los como substitutos. O trabalho deste artigo é a fixação do OpenZiti e a higiene desse plano de controlo, nada mais. Se o título do ticket pudesse ser trocado por Headscale, Linkerd2, Tetragon, Gatekeeper, Kyverno ou Trivy sem mudar os passos, o ticket não é sobre esta fixação.

Cada um dos seis controlos abaixo tem provas que contam e provas que não contam. Um número de estrelas, um slogan de marketing que diz «zero trust» e um digest latest flutuante não são prova de nenhum deles.

Primeiro, inventariar controladores, routers de periferia e identidades registadas, incluindo os membros de um cluster de controladores HA, se existirem. A prova é uma exportação de inventário que nomeia esses objetos e indica se existe um segundo controlador. Um diapositivo a dizer «overlay implementado» não é essa exportação.

Segundo, fixar uma linha conhecida depois da janela de alteração. Na linha 2.0, o mínimo é a v2.0.6. Os pré-lançamentos como a v2.0.7 e a v2.0.8 ficam fora desse ticket, a não ser que o cliente aceite expressamente um pré-lançamento, por escrito, nesse ticket. A prova é a cadeia da tag no registo de alteração, não um digest que alguém descarregou na manhã da janela por aparecer em primeiro lugar.

Terceiro, exigir MFA de administrador nas identidades do controlador e da consola de administração, revogar registos obsoletos e manter o privilégio mínimo nas políticas de identidade e de serviço. A prova é uma definição de MFA nessas identidades de administração e um registo de revogação dos registos que já não têm responsável.

Quarto, aceder ao plano de gestão apenas a partir de redes de administração de confiança ou de anfitriões de salto. A exposição pública da administração ou do registo não é uma predefinição. A prova é uma lista de permissões, ou uma regra equivalente para anfitriões de salto, anexada ao ticket. Um diagrama de firewall sem identificadores de regras é um desenho.

Quinto, fazer exercícios de cópia de segurança e restauro do modelo de dados do controlador e do material de registo. Reconstruir a partir de suportes de confiança e rodar as identidades após uma suspeita de comprometimento. A prova é o relatório do exercício de restauro: a data, quem o fez e se o restauro produziu um controlador que o inventário ainda reconhece.

Sexto, enviar os registos de auditoria para um SIEM. Tratar registos inesperados, remoções de MFA de administrador e instabilidade nas ligações dos routers como sinais operacionais a vigiar. A prova é o nome da consulta no SIEM e um responsável que a analisa. Um bucket de registos que ninguém abre é armazenamento, não vigilância.

A frase que a equipa de alterações pode repetir: não confundir «implementámos um overlay» com «o plano de controlo está fixado e protegido». A implementação é o início do inventário. A fixação e a proteção são tickets posteriores, e têm de nomear uma linha.

Em resumo: o OpenZiti (openziti/ziti) tem licença Apache-2.0 e tinha 4417 estrelas no GitHub a 4 de outubro de 2026. A versão mínima na linha 2.0 é a v2.0.6, lançada a 18 de setembro de 2026, enquanto a v2.0.7 e a v2.0.8 continuam a ser pré-lançamentos. A página principal é openziti.io.

O OpenZiti não é o Headscale, nem o Linkerd2, nem o Tetragon, nem o Gatekeeper, nem o Kyverno, nem o Trivy. Fixe a linha, proteja o plano de controlo e guarde as provas no ticket.