Se você nunca usou Karmada, o resumo é: ele resolve orquestração multi-cluster e multi-cloud sem pedir que você reescreva manifests. Você aplica o YAML normal contra a karmada-apiserver e associa uma PropagationPolicy (ou ClusterPropagationPolicy, pra recursos cluster-scoped) dizendo em quais clusters membro aquilo deve rodar — com regras de failover e override por cluster. A comunicação com os clusters membro pode ser em modo push (o control plane do Karmada acessa a API dos membros diretamente, bom pra clusters na mesma rede) ou pull (um karmada-agent roda dentro do cluster membro e busca instruções no control plane, necessário quando o cluster está atrás de firewall ou é edge).
Desde que entrou no Sandbox em 2021 e passou pra Incubating em dezembro de 2023, o projeto cresceu pra mais de 1.200 contribuidores de 292 organizações, com adotantes documentados como Bloomberg e Wellhub, além de players de cloud, telecom e IA na Ásia.
A graduação coincidiu com o release do v1.19.0, publicado em 31 de agosto de 2026. E é o release — não o selo — que muda comportamento de quem já roda Karmada ou está avaliando adotar. Quatro pontos merecem atenção antes de atualizar.
Em modo push, o Karmada mantém um watch aberto contra a API de cada cluster membro pra reagir a mudanças de status. Antes do v1.19, se o bearer token usado nesse watch fosse rotacionado — o que acontece por padrão em vários setups de service account com token de vida curta —, a conexão não era renovada automaticamente. O watch continuava “vivo” na aparência, mas parava de receber eventos novos. Sem crash, sem log óbvio de erro recorrente: só um cluster que para de refletir status atualizado até alguém reiniciar o componente manualmente.
O v1.19 implementa uma camada de transporte que renova o token no informer automaticamente quando ele rotaciona, sem exigir restart. Se você roda push mode com tokens de curta duração — comum em integrações com OIDC ou em clusters gerenciados que forçam rotação —, esse fix sozinho já justifica a atualização, porque o sintoma anterior é exatamente do tipo que passa despercebido até virar incidente.
O feature gate PriorityBasedScheduling foi promovido a Beta e vem habilitado por padrão no v1.19. Na prática, isso faz o scheduler do Karmada respeitar spec.schedulePriority nas suas PropagationPolicy e agendar workloads de prioridade mais alta primeiro quando há disputa por capacidade entre clusters.
Se você nunca configurou schedulePriority, o efeito prático deve ser neutro — sem prioridade declarada, não há reordenação pra aplicar. Mas se algum manifesto seu já tem esse campo preenchido (por exemplo, copiado de um exemplo da documentação sem intenção de usar o recurso), o comportamento de scheduling muda no upgrade sem você ter pedido. Vale grepar suas policies por schedulePriority antes de atualizar. Pra manter o comportamento anterior de qualquer forma, dá pra desligar com --feature-gates=PriorityBasedScheduling=false no karmada-scheduler.
PurgeMode é o campo que controla o que acontece com a instância antiga de uma aplicação quando ela migra de cluster por failover — Directly evicta na hora (útil quando duas instâncias rodando ao mesmo tempo não pode acontecer), Gracefully espera a aplicação ficar saudável no cluster novo antes de tirar a antiga do ar.
Os valores antigos Immediately e Graciously — que já estavam deprecados — foram removidos no v1.19, não só descontinuados. Se alguma PropagationPolicy sua com regra de failover ainda usa esses nomes, ela vai falhar validação depois do upgrade do control plane. É find-and-replace simples (Immediately → Directly, Graciously → Gracefully), mas precisa ser feito antes, não depois de descobrir em produção.
Karmada estripou managedFields dos caches dos informers dinâmicos e separou melhor a responsabilidade entre o execution controller (mudanças nos clusters membro) e o work-status controller (coleta de status), eliminando reconciliação duplicada. O resultado reportado pelo projeto: pico de memória do karmada-controller-manager caindo de 5 GB pra 3.4 GB num teste distribuindo 20.000 Deployments. Se você dimensionou o control plane pro consumo do v1.18, vale reavaliar o limite depois de migrar — não porque vai faltar memória, mas porque provavelmente sobra headroom que estava sendo desperdiçado.
Se você roda um cluster Kubernetes só, isso não muda nada pra você hoje. Karmada resolve um problema específico: aplicação distribuída em múltiplos clusters — por região, por cloud, por ambiente de produção replicado — com uma política declarativa central em vez de pipeline de CI/CD duplicando manifests por cluster. Se esse é o seu cenário e você está hoje resolvendo isso com script, Terraform aplicando N vezes, ou ArgoCD ApplicationSet puro sem lógica de failover, vale colocar Karmada na lista de avaliação — a chancela Graduated é, no mínimo, sinal de que o projeto não vai sumir nem mudar de API de forma descontrolada.
PropagationPolicy e ClusterPropagationPolicy por schedulePriority; se existir e não for intencional, decida se aceita o novo comportamento de scheduling ou desliga o feature gate.purgeMode: Immediately ou purgeMode: Graciously e substitua antes do upgrade do control plane, não depois.karmada-controller-manager via resources.limits, revalidar depois da migração — o número mudou pra baixo no benchmark do projeto, mas seu workload real pode variar.Server, MeshTLSAuthentication e AuthorizationPolicy.
O padrão abaixo é o que a própria documentação do projeto recomenda para restringir acesso — não é relato de “rodei isso em produção”, é a forma oficial de compor essas três CRDs (mais HTTPRoute, quando a granularidade precisa ser por caminho, não só por porta). Testei o schema direto no chart linkerd-crds do repositório do projeto pra garantir que os campos abaixo batem com a versão atual — sem inventar enum ou flag que eu não vi na fonte.
Server (policy.linkerd.io/v1beta3) declara uma porta de um Deployment como alvo de política. O campo que muda o jogo é accessPolicy, que hoje tem deny como valor default: se o tráfego não casar com nenhuma regra de AuthorizationPolicy, ele é recusado — não fica liberado por omissão.
apiVersion: policy.linkerd.io/v1beta3
kind: Server
metadata:
name: billing-api
namespace: billing
spec:
podSelector:
matchLabels:
app: billing-api
port: http
# sem regra correspondente, a requisição é negada
accessPolicy: deny
MeshTLSAuthentication (policy.linkerd.io/v1alpha1) descreve quem está autorizado, usando a identidade mTLS do proxy de origem — não IP, não header, a identidade criptográfica que o Linkerd já verificou no handshake. Você referencia por string de identidade completa ou por ServiceAccount:
apiVersion: policy.linkerd.io/v1alpha1
kind: MeshTLSAuthentication
metadata:
name: checkout-identity
namespace: billing
spec:
identityRefs:
- kind: ServiceAccount
name: checkout
namespace: storefront
AuthorizationPolicy (policy.linkerd.io/v1alpha1) é quem liga as duas pontas: um targetRef (o que está protegido) e um ou mais requiredAuthenticationRefs (quem pode acessar). Se houver mais de uma referência de autenticação, todas precisam ser satisfeitas — não é “qualquer uma serve”.
apiVersion: policy.linkerd.io/v1alpha1
kind: AuthorizationPolicy
metadata:
name: billing-api-checkout-only
namespace: billing
spec:
targetRef:
kind: Server
name: billing-api
requiredAuthenticationRefs:
- kind: MeshTLSAuthentication
name: checkout-identity
Com essas três peças, só o pod rodando com a ServiceAccount checkout no namespace storefront consegue falar com billing-api, em qualquer rota daquela porta. Qualquer outro pod do mesh — mesmo com mTLS válido, mesmo no mesmo namespace — recebe conexão recusada.
O ponto acima protege a porta inteira. Na prática, é comum precisar de granularidade menor: checkout pode chamar POST /orders, mas /admin/refund só pode ser chamado por um serviço interno de operações. Pra isso, o targetRef do AuthorizationPolicy não precisa apontar pro Server — pode apontar pra um HTTPRoute.
O Linkerd aceita tanto o HTTPRoute próprio (policy.linkerd.io) quanto o HTTPRoute padrão da Gateway API (gateway.networking.k8s.io). Se você já usa Gateway API para roteamento (como a maioria dos clusters recentes), reaproveita o mesmo recurso como alvo de autorização — não precisa manter dois objetos de rota:
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: billing-admin-route
namespace: billing
spec:
parentRefs:
- name: billing-api
kind: Server
group: policy.linkerd.io
rules:
- matches:
- path:
type: PathPrefix
value: /admin
apiVersion: policy.linkerd.io/v1alpha1
kind: AuthorizationPolicy
metadata:
name: billing-admin-restricted
namespace: billing
spec:
targetRef:
group: gateway.networking.k8s.io
kind: HTTPRoute
name: billing-admin-route
requiredAuthenticationRefs:
- kind: MeshTLSAuthentication
name: ops-identity
Com isso, /admin/* fica restrito à identidade ops-identity, enquanto o resto das rotas de billing-api segue liberado pra quem satisfizer o AuthorizationPolicy de nível de Server. As duas políticas convivem: a mais específica (rota) governa o que ela cobre, a mais geral (porta) cobre o restante.
AuthorizationPolicy opera em L7, com identidade criptográfica — é um controle diferente (e complementar) de NetworkPolicy, que opera em L3/L4 por IP/CIDR e não depende do Linkerd estar rodando. Um ataque que comprometa o nó ou contorne o proxy sidecar não é coberto pela política de autorização do mesh. Continue usando NetworkPolicy como camada de isolamento de rede; o AuthorizationPolicy entra por cima, como controle de identidade de serviço para serviço, inclusive por rota.
Também vale registrar: a mudança de default para accessPolicy: deny é comportamento atual do Server v1beta3 (a versão storage: true no CRD hoje). Se você tem Server de uma versão anterior do cluster com outro default, confira o accessPolicy explicitamente antes de assumir que “sem AuthorizationPolicy” significa “bloqueado” — não assuma, leia o manifesto aplicado.
Faz sentido priorizar isso em: serviços com endpoint administrativo/destrutivo que não deveria estar acessível por qualquer coisa autenticada no mesh; ambientes multi-tenant onde “estar no cluster” não deveria implicar “poder chamar qualquer serviço”; e qualquer rota que hoje só está protegida por “ninguém mais sabe que ela existe” — segurança por obscuridade que uma varredura de service discovery derruba em minutos.
Não é o primeiro passo se o cluster ainda não tem mTLS habilitado de forma consistente (a injeção do proxy precisa estar em todo pod relevante) nem se você ainda não mapeou quem-chama-quem — aplicar accessPolicy: deny sem esse mapa quebra tráfego legítimo. Comece com Server + AuthorizationPolicy nos serviços de maior risco, valide em um ambiente de homologação observando erros de conexão recusada, e só depois expanda pra granularidade de rota.
AuthorizationPolicy (charts/linkerd-crds/templates/policy/authorization-policy.yaml)Server (charts/linkerd-crds/templates/policy/server.yaml)MeshTLSAuthentication (charts/linkerd-crds/templates/policy/meshtls-authentication.yaml)HTTPRoute própria do Linkerd (charts/linkerd-crds/templates/policy/httproute.yaml)A partir da 1.21.2, o comportamento dos issuers ACME e Vault muda assim:
status do Issuer/ClusterIssuer nem pros Events do cluster. Antes, quando o servidor ACME (ou o Vault, no caso do Vault issuer) respondia algo fora do esperado, o cert-manager copiava esse corpo de resposta pra dentro da condição de status do recurso e pra um Event — objetos que ficam visíveis via kubectl describe ou kubectl get events pra qualquer principal com permissão de leitura no namespace, que costuma ser bem mais gente do que quem pode ler um Secret.Junto veio uma leva de correções sem relação direta com isso — panic no webhook de validação quando o AdmissionReview vem sem campos opcionais, race condition no self-check do HTTP-01, panic no controller de issuing quando um CertificateRequest tem timestamp de falha mas não tem condição Ready, e um bug de agenda cron pontual (29 de fevereiro cruzando século não-bissexto — específico, mas reflete o tipo de teste de borda que o projeto vem fazendo). A 1.20.4, por sua vez, é patch de dependências: Go atualizado pra 1.26.6 (fixes em crypto/tls, encoding/asn1, net/http), golang.org/x/crypto e grpc bumped. As notas de release citam três achados em golang.org/x/crypto que continuam sem correção na linha 1.20 — o próprio changelog registra que eles não afetam a operação do cert-manager, então não é motivo pra travar o upgrade.
O ponto não é “vazamento de segredo direto” — nenhum dos dois issuers coloca token de API ou chave privada na resposta HTTP em condições normais. O ponto é a classe de risco: dado não confiável, vindo de um endpoint externo (ACME ou Vault), sendo refletido sem sanitização num objeto do Kubernetes com modelo de RBAC mais permissivo do que o dado provavelmente merecia.
Dois cenários concretos que essa mudança fecha:
status.conditions[].message — que trata esse campo como texto confiável, um corpo de resposta controlado por um endpoint comprometido virava um jeito de injetar conteúdo arbitrário nesse pipeline.Vale registrar o contraste com o que é tratado como vulnerabilidade formal no projeto: em junho de 2026 saiu a GHSA-8rvj-mm4h-c258, severidade alta, sobre a ClusterRole padrão de edit permitir que qualquer usuário de namespace crie recursos Challenge/Order diretamente e explore credenciais DNS de um ClusterIssuer sem passar pela política do Issuer. São dois problemas diferentes — um é bypass de política via RBAC padrão permissivo demais, o outro é dado não confiável indo pra objeto errado — mas os dois apontam pro mesmo ponto cego: no fluxo ACME do cert-manager, o que “parece” read-only ou inofensivo (Challenge, Order, Event, status) às vezes carrega mais poder ou mais dado do que a intuição sugere.
status.conditions ou Events do cert-manager como fonte de diagnóstico, ajuste pra também consultar o log do controller depois do upgrade — o corpo completo do erro não estará mais no status pra requisições que não são “problem document” ACME.get/list em Events e em Issuer/ClusterIssuer no seu cluster e compare com quem tem acesso a Secret. Se a resposta for “praticamente todo mundo tem Events, poucos tem Secret”, vale entender que isso é intencional no design do Kubernetes — Events são efêmeros e de baixa confidencialidade por padrão — mas só funciona se nada sensível for escrito lá, que era exatamente a falha que essa versão corrige.ClusterRole edit padrão e ClusterIssuers com credenciais DNS, revisite a GHSA-8rvj-mm4h-c258 separadamente — é advisory de junho, já tem tempo, mas continua relevante pra quem não aplicou a mitigação.Fora essas duas frentes, o resto do release é manutenção: menos superfície de bug em cenários de borda, dependências atualizadas. Não é um patch que pede reunião de emergência — mas é o tipo de upgrade que vale entrar na próxima janela normal, não na próxima vez que sobrar tempo.
Gateway do Cilium sem sair do padrão upstream do Kubernetes.
Se você já usa Cilium como CNI e tem Gateway API habilitado (ou está cogitando substituir um Ingress Controller por ele), o release traz capacidade nova real. Mas duas delas têm ressalvas que vale testar antes de generalizar em produção — não é só “atualiza e usa”.
Quatro capacidades novas, todas vindas do upstream do Gateway API e agora implementadas no Cilium:
Gateway compartilhado, sem precisar que o time de plataforma edite o Gateway principal a cada novo listener. Separa “quem é dono do Gateway” de “quem precisa expor uma porta nele”.Service do tipo LoadBalancer à parte.HTTPRoute que delega a decisão de autenticação/autorização a um serviço externo via protocolo ext_authz do Envoy (gRPC ou HTTP), antes da requisição chegar na aplicação. É a implementação do GEP-1494 do Gateway API.EnvoyExtraConfig ou anotação específica do Cilium.As três primeiras CRDs (TCPRoute, UDPRoute, ListenerSet) são opcionais: se você não instalar os CRDs correspondentes, o Cilium simplesmente desabilita o suporte àquela feature, sem quebrar o resto. Isso facilita adoção incremental — mas também significa que “atualizei o Cilium” não é o mesmo que “já tenho TCPRoute disponível”.
O tráfego de TCPRoute e UDPRoute não passa pelo Envoy — ele vai direto pro Service que o Gateway gera, que normalmente expõe a porta do listener como LoadBalancer. Se o seu Gateway roda em modo host network, esse Service vira NodePort em vez de LoadBalancer, e a porta deixa de ser a que você configurou no listener — passa a ser uma porta aleatória da faixa de NodePort do cluster.
Na prática: se você depende de host network (comum em bare metal sem LoadBalancer de nuvem) e quer expor um Postgres ou um DNS via TCPRoute, a porta que chega no cliente não é a que está no manifesto. Vale conferir esse detalhe antes de apontar qualquer coisa em produção pra uma porta fixa.
O ExternalAuth já apareceu em pré-release (v1.20.0-pre.3) e um operador documentou, em relato público (não é advisory oficial do projeto Cilium), um comportamento específico: em cluster com modo túnel + criptografia WireGuard habilitada, a sub-requisição ext_authz do Envoy pro backend de autenticação era descartada silenciosamente sempre que cruzava nó — sem log de política bloqueada, sem erro visível. A causa relatada: o tráfego de ext_authz sai do Envoy com identidade host/remote-node (encryptkey=0, sem criptografia), e não consegue ser entregue a um pod que espera tráfego criptografado (encryptkey=255) — um padrão parecido com o do CVE-2024-28250.
O mesmo relato registra que, ao subir para 1.20.1, o bloqueio nesse cenário específico deixou de ocorrer — mas o próprio autor deixou a validação completa do datapath como pendente. Ou seja: não é uma falha confirmada e corrigida via security advisory formal do Cilium, é um relato de campo. Dá pra tratar como sinal, não como veredito.
Se seu cluster combina os três ingredientes — ExternalAuth, modo túnel e WireGuard node-to-node —, vale rodar o cenário em staging com nós físicos separados (o problema só aparece cruzando nó) antes de confiar nisso pra autenticação em produção. Sem essa combinação específica, a feature não tem nenhum caveat documentado.
Cilium 1.20 adiciona suporte a IPv6 no IPAM de ENI da AWS, em Beta. E separadamente — mas no mesmo tema de gestão de IP — chega um caminho de migração de cluster-pool pra multi-pool IPAM sem precisar reconstruir o cluster. Se você já cogitou migrar de IPAM mas parou no “vai exigir recriar tudo”, esse é o motivo pra reavaliar.
O suporte a Mutual Authentication (Beta) — o mecanismo mTLS mais antigo do Cilium — foi marcado como deprecado nesta versão, com remoção prevista pra uma versão futura (a nota de release não fixa qual). A recomendação do próprio changelog é migrar para o Ztunnel Transparent Encryption (também Beta). Se você tem Mutual Authentication configurado hoje, não é urgente, mas é hora de colocar a migração no radar antes que vire remoção sem aviso maior.
initContainer com timeout apertado ou registry lento.cilium.io/v2alpha1 de CiliumNodeConfig, integração com libnetwork e configuração de CNI customizada — nenhum desses tem detalhe público além do aviso genérico “confira o guia de upgrade” no próprio release.Se você já roda Gateway API no Cilium: o upgrade em si é direto, mas trate TCPRoute/UDPRoute e ExternalAuth como features novas a testar isoladamente, não como parte automática do “upgrade e segue”. Antes de generalizar:
TCPRoute/UDPRoute e o Gateway roda em host network — confirme a porta real que chega no cliente antes de apontar produção.ExternalAuth e o cluster usa modo túnel + WireGuard node-to-node — valide em staging com nós físicos distintos antes de depender disso pra autorização.Fora dessas combinações específicas, o resto do release — ListenerSets pra delegar listener sem soltar o Gateway principal, CORS nativo, binário menor — é ganho direto sem contrapartida conhecida até agora.
Policy no próprio namespace escale até cluster-admin. As outras cinco são bypasses de isolamento entre namespaces, de SSRF e de verificação de assinatura de imagem.
Se você usa Kyverno só pra bloquear latest como tag de imagem, o impacto prático é baixo. Mas se você delega a criação de políticas pra times de plataforma ou tenants — o caso de uso mais comum de um policy engine multi-tenant — vale ler com atenção, porque o requisito de exploração em quase todas é justamente esse: alguém que só devia poder escrever política no próprio namespace.
GHSA-5qq8-67g6-4h2w (CVSS 9.9) nasce de uma discrepância boba de aparência, grave na prática: o Kyverno valida o urlPath de um apiCall com path.Clean() — que normaliza sequências .. literais — mas executa a requisição com o path bruto, sem decodificar. Uma sequência %2e%2e (.. percent-encoded) passa pela validação como se estivesse dentro do namespace do tenant, e só é decodificada de volta pra .. quando o client-go do Kubernetes monta a requisição real — aí sim resolvendo pra fora do namespace.
Com isso, um tenant com permissão de criar Policy (e de criar workloads, no papel de editor) tem dois caminhos documentados até cluster-admin:
MutatingWebhookConfiguration: registra um webhook mutante cluster-wide, intercepta criação de pods no kube-system, sequestra a ServiceAccount do clusterrole-aggregation-controller e injeta um sidecar que dá permissão total à ClusterRole system:basic-user.PolicyException: cria um PolicyException dentro do namespace kyverno — que o tenant não deveria conseguir acessar diretamente — desativando políticas enforcing só pro próprio namespace e admitindo workloads que estavam bloqueados.Não existe CVE atribuído ainda, só o GHSA. O achado é de Artem Cherezov.
GHSA-c5qq-7g2q-cpqp (CVSS 7.7) é a mesma classe de bug da crítica acima, só que aplicada à leitura de recursos em vez de escalada de privilégio: um path como /api/v1/namespaces/atacante-ns/%2e%2e/vitima-ns/configmaps/config passa pela validação lexical (path.Clean() não decodifica percent-encoding) mas é resolvido de verdade pelo url.Parse() na hora de montar a chamada, que decodifica %2e%2e em .. e atravessa pro namespace vizinho — com a ServiceAccount do controller do Kyverno, não a do tenant. Em instalação default, isso já dá leitura de ConfigMaps de qualquer namespace; se a ServiceAccount do controller tiver permissão sobre Secrets, o alcance é maior.
GHSA-59v6-2x73-wfg4 (CVSS 7.7) é um isolamento quebrado por omissão, não por bug de parsing: a biblioteca CEL globalcontext.Lib — ao contrário de resource.Lib e http.Lib — nunca recebeu parâmetro de namespace no registro. Um NamespacedValidatingPolicy (ou as variantes Mutating/Deleting/Generating/ImageValidating) escrita por um tenant pode chamar globalContext.get("<entry>", "") e ler o conteúdo completo de um GlobalContextEntry cluster-scoped, mesmo de dados vindos de outros namespaces. Só afeta quem já usa GlobalContextEntry cruzando namespaces — cluster sem isso não é afetado.
apiCallGHSA-q825-p383-r9v5 (CVSS 7.6) mostra o risco de proteção parcial: em abril de 2026 o Kyverno adicionou blocklist de SSRF e controle de token pro caminho novo baseado em CEL (pkg/cel/compiler/http.go). O executor legado (pkg/engine/apicall/executor.go), usado por ClusterPolicy/Policy clássicas e por GlobalContextEntry, nunca recebeu o mesmo tratamento. Ele monta a requisição com a URL bruta definida pelo autor da política, sem qualquer filtro, e anexa Authorization: Bearer <token> da ServiceAccount sempre que o autor não define header próprio. Resultado: quem tem permissão de criar política pode apontar apiCall.service.url pro metadata endpoint da cloud (169.254.169.254), loopback ou serviço interno, e o Kyverno faz a requisição com o próprio token embutido — sem confirmar se o destino é legítimo.
PolicyExceptionGHSA-5cjf-wwfg-pj4c (CVSS 7.7) atinge quem usa ImageValidatingPolicy com Notary ou Cosign pra checar assinatura de imagem antes do deploy. O PolicyException deveria isentar só as imagens listadas em spec.images — é assim que ValidatingPolicy, MutatingPolicy e GeneratingPolicy já se comportam. Só que no compilador do ImageValidatingPolicy (pkg/image/verification/evaluator/compiler.go), apenas os matchConditions da exceção são compilados; os campos images e allowedValues nunca são processados. Na prática, qualquer PolicyException que dê match na política desliga a verificação de assinatura inteira — não só pras imagens que deveriam estar isentas. Quem tem permissão de criar PolicyException desativa verificação de supply chain cluster-wide, mesmo sem essa intenção.
Todas as seis (mais duas CVEs de dependência — CVE-2026-39821 e CVE-2026-56853, resolvidas com bump de Go 1.26.6 e x/net) estão corrigidas no v1.19.1. Não há mitigação parcial documentada pra nenhuma delas — atualizar é o caminho.
Priorize pela combinação que te afeta:
Policy pra squads): a crítica e as duas de isolamento são motivo pra não esperar a janela de manutenção normal. É exatamente esse modelo de uso que os três bugs exploram.apiCall em ClusterPolicy/Policy clássica ou GlobalContextEntry apontando pra serviço externo: o bypass de SSRF é seu — confira se o executor legado ainda está em uso antes de assumir que a blocklist de abril te protege.ImageValidatingPolicy com Notary/Cosign e permite PolicyException: valide se alguma exceção existente hoje está isentando mais imagens do que deveria — o comportamento errado já pode estar em produção silenciosamente.GlobalContextEntry compartilhado entre namespaces: revise quem tem permissão de escrever NamespacedValidatingPolicy antes de assumir isolamento entre tenants.O padrão que conecta quatro das seis falhas é o mesmo: validação de path feita numa representação (limpa, decodificada) e execução feita em outra (bruta, ou decodificada de novo mais adiante). Vale como lição pra qualquer controller seu que valida uma string e delega a interpretação real dela pra uma lib de terceiro — path.Clean() e url.Parse() não concordam sobre o que %2e%2e significa, e essa divergência é exatamente onde bypass de autorização mora.
O jeito mais frágil de resolver isso é um CronJob rodando kubectl scale. Ele não tem estado (se falhar, o ambiente fica no limbo), some no primeiro kubectl apply do Argo CD, e você precisa manter duas listas de deployments em sincronia. Dá pra fazer melhor com o cron scaler do KEDA.
Desde o Kubernetes v1.37 — Beta, feature gate HPAScaleToZero ligado por padrão —, o HorizontalPodAutoscaler nativo já aceita minReplicas: 0. Duas ressalvas tiram ele da jogada pra esse caso:
start/end embutido. Pra desligar “das 20h às 7h” você precisaria expor uma métrica externa que varie sozinha com o relógio — na prática, reimplementar um cron como métrica.O KEDA não compete com o HPA, aliás: o ScaledObject cria um HorizontalPodAutoscaler por baixo dos panos (é por isso que ter os dois no mesmo alvo dá conflito — mais adiante). O que ele soma são os triggers — mais de 60, incluindo o cron — que o HPA sozinho não tem. Pra “desligar fora do expediente”, o caminho direto continua sendo o cron scaler.
O ponto que confunde: o cron scaler não “dispara” nada num horário. Ele define uma janela [start, end) e, enquanto o relógio está dentro dela, mantém o deployment num número fixo de réplicas. Fora da janela, ele solta a restrição.
Para “desligar fora do expediente”, a janela é o expediente:
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: api-pedidos
namespace: homolog
spec:
scaleTargetRef:
name: api-pedidos
minReplicaCount: 0 # fora da janela -> zero
cooldownPeriod: 300
triggers:
- type: cron
metadata:
timezone: America/Sao_Paulo
start: 0 7 * * 1-5 # 07:00, seg a sex
end: 0 20 * * 1-5 # 20:00, seg a sex
desiredReplicas: "2" # capacidade dentro do expediente
Lê como: “das 7h às 20h, de segunda a sexta, no horário de São Paulo, quero 2 réplicas; fora disso, zero”. O dia-da-semana (1-5) já resolve o fim de semana — ele nunca entra na janela, então fica desligado sábado e domingo.
Alguns detalhes dos campos:
timezone é obrigatório e usa a IANA Time Zone Database. Como você declara o fuso, o horário de verão é tratado sozinho.start / end são cron Linux de 5 campos (minuto hora dia-do-mês mês dia-da-semana), sem segundos. Os dois não podem resolver para o mesmo instante.desiredReplicas é um inteiro como string ("2", com aspas).minReplicaCount: 0 é o que permite a ida a zero. Se você quiser deixar 1 réplica de pé fora do horário (pra health check, uma demo eventual), use minReplicaCount: 1.Se o replicas dos seus deployments está versionado no Git e você usa Argo CD (ou Flux), o KEDA vai alterar spec.replicas o tempo todo — e isso vira drift permanente: o Argo CD vê “Git diz 2, cluster diz 0”, marca como OutOfSync e, no pior caso, sincroniza de volta pra 2 no meio da madrugada.
Duas formas de resolver, escolha uma:
replicas do manifesto. Se o campo não existe no Git, o KEDA passa a ser o dono e não há o que divergir. É a opção mais limpa quando o KEDA cuida do scaling daquele workload de ponta a ponta.Application:spec:
ignoreDifferences:
- group: apps
kind: Deployment
jqPathExpressions:
- .spec.replicas
Sem isso, você não tem uma rotina de desligamento — tem uma guerra de sincronização.
Um ScaledObject aponta pra um scaleTargetRef. Não existe “escale tudo que tem o label X” nativo. Então você tem um ScaledObject por deployment que participa do desligamento. Na prática isso é um for no seu Kustomize ou um range no seu Helm chart:
{{- range .Values.desligarForaDoExpediente }}
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: {{ . }}
namespace: {{ $.Release.Namespace }}
spec:
scaleTargetRef:
name: {{ . }}
minReplicaCount: 0
cooldownPeriod: 300
triggers:
- type: cron
metadata:
timezone: America/Sao_Paulo
start: {{ $.Values.expediente.start | quote }}
end: {{ $.Values.expediente.end | quote }}
desiredReplicas: {{ $.Values.expediente.replicas | quote }}
{{- end }}
Uma lista só (desligarForaDoExpediente: [api-pedidos, api-clientes, frontend, ...]) e a janela definida em um lugar. Serviço novo entra na rotina adicionando uma linha.
Escopo isso para deployments stateless de aplicação. Fique longe de:
StatefulSet com dado. O KEDA até escala StatefulSet, mas levar um Postgres a zero toda noite é pedir corrupção e dor de cabeça de recovery.CronJobs. Não são afetados por ScaledObject (isso é ScaledJob, outro recurso). Se você tem um batch noturno em homolog, ele continua rodando.A janela deve abrir antes do primeiro uso. Se as pessoas chegam às 8h, comece às 7h ou 7h30: cold start de pod, pool de conexão com o banco, cache frio e warmup de JVM não são instantâneos. start: 0 7 * * 1-5 te dá essa folga.
Na descida, o cooldownPeriod (padrão 300s) é quanto o KEDA espera depois do end antes de escalar pra baixo — então o ambiente cai uns 5 minutos depois das 20h, não no minuto exato. Ajuste se quiser corte mais seco.
Precisa manter o ambiente de pé numa noite específica (deploy de emergência, demo pro cliente lá fora)? Anote no ScaledObject:
metadata:
annotations:
autoscaling.keda.sh/paused-replicas: "2"
Isso congela em 2 réplicas e ignora o cron até você remover a anotação. É a válvula de escape sem editar a janela.
Um último cuidado: se o deployment já tem um HPA nativo, remova. O KEDA cria o próprio HPA e dois HPAs no mesmo alvo brigam entre si.
Produção com SLA fica de fora — o risco de alguém precisar do serviço às 3h e ele estar frio não compensa a economia. E se o seu workload tem cold start de vários minutos ou depende de uma cadeia grande de serviços subindo em ordem, o custo de religar todo dia pode passar do que você economiza. Nesses casos, ou você aceita 1 réplica mínima, ou o desligamento fica só pro fim de semana.
Para homolog, dev e staging, porém, essa é uma das economias mais fáceis de cloud native: um ScaledObject por serviço, uma janela, e o ambiente se desliga sozinho todo dia às 20h.
minReplicaCount, cooldownPeriod, pollingInterval)paused-replicas)ignoreDifferencesSem aviso. Sem graceful shutdown. Só um OOM e silêncio total no dashboard.
Já vi isso acontecer por três motivos diferentes. Todos evitáveis. Todos silenciosos até o momento errado. Vou contar cada um com o que causou, como detectar antes que vire incidente, e como corrigir.
O Prometheus armazena cada combinação única de métrica + labels como uma série temporal separada na memória. Isso é o que torna ele poderoso. E é exatamente o que mata ele quando você não presta atenção.
Um request_id como label parece inofensivo. Mas em produção, com milhares de requisições por segundo, cada ID único vira uma série nova. Em horas, você tem dezenas de milhões de séries ativas. O processo não avisa — ele simplesmente consome toda a RAM disponível e morre.
Labels que explodem cardinalidade quase sempre são os mesmos: user_id, request_id, trace_id, session_id, caminhos de URL brutos. Se o valor pode ser diferente a cada requisição, não é label — é dado de trace.
# Séries ativas no TSDB — saudável: 100k–2M. Acima de 5M: problema. Acima de 10M: urgente.
prometheus_tsdb_head_series
# Quais métricas estão explodindo
topk(10, count by (__name__) ({__name__=~".+"}))
# Taxa de criação de séries novas — churn acelerado é sinal de label problemático
rate(prometheus_tsdb_head_series_created_total[5m])
Se você não controla o exporter, dropa o label antes que entre no TSDB:
metric_relabel_configs:
- regex: '(request_id|trace_id|user_id|session_id)'
action: labeldrop
E coloca um alerta pra não ser pego de surpresa de novo:
- alert: CardinalidadeAlta
expr: prometheus_tsdb_head_series > 5000000
for: 10m
labels:
severity: warning
annotations:
summary: "{{ $value }} séries ativas — investiga antes de virar OOM"
Esse é mais silencioso. Não mata o Prometheus na hora — mata ele no pior momento possível.
O default é 15 dias de retenção. Na maioria dos setups, ninguém muda. O problema é que o número de séries cresce com o tempo — novos serviços, novos exporters, novos labels — mas o disco fica o mesmo. Em algum ponto, o volume diário de dados supera o que o disco aguenta para 15 dias.
Sem o parâmetro --storage.tsdb.retention.size configurado, o Prometheus vai consumir todo o disco disponível. Com ele configurado errado, você perde exatamente o histórico que precisaria pra fechar um postmortem.
Já vi time passar horas tentando entender a causa raiz de um incidente sem conseguir — porque o Prometheus tinha deletado os dados de 3 semanas atrás que mostrariam o padrão.
# Uso atual do TSDB em bytes
prometheus_tsdb_storage_blocks_bytes
# Crescimento diário estimado
rate(prometheus_tsdb_storage_blocks_bytes[24h])
O ponto não é aumentar o tempo de retenção. É combinar os dois parâmetros de forma que o disco nunca estoure e você nunca perca dados antes do prazo esperado.
--storage.tsdb.retention.time=7d
--storage.tsdb.retention.size=50GB
O primeiro limite atingido prevalece. Se o volume cresceu mais do que o esperado e o disco está chegando em 50GB antes dos 7 dias, o Prometheus deleta os blocos mais antigos automaticamente. Você não perde a instância — perde só o histórico mais velho, de forma controlada.
Sem o retention.size, o Prometheus vai crescer até ocupar todo o disco disponível. Aí não tem deleção controlada: tem crash.
Uma coisa que pouca gente lembra: o WAL (write-ahead log) ocupa espaço além dos blocos compactados. Em instâncias com alta ingestão, ele pode representar 2–3x o tamanho do head block. Monitora separado.
E se você precisa de histórico longo — mais de 30 ou 60 dias — o Prometheus não é a ferramenta certa pra isso. Thanos, Mimir ou VictoriaMetrics existem pra isso. Deixa o Prometheus local com janela curta e delega o histórico longo pra quem foi projetado pra aguentar.
Esse erro nasce de uma boa intenção: “mais granularidade = melhor observabilidade”. Em alguns casos é verdade. Em outros, você está criando o problema que quer evitar.
O default do Prometheus é 1 minuto. Muitos times reduzem pra 15s ou 10s. O problema aparece quando você aplica esse interval em exporters pesados. O kube-state-metrics e o node-exporter em clusters grandes são os casos mais comuns. Um node-exporter num cluster de 50 nodes pode gerar facilmente 100k samples por scrape. Com interval de 15s, você está ingerindo centenas de milhares de samples por segundo só de infra, antes de qualquer métrica de aplicação.
O sintoma: scrape_duration_seconds maior que o próprio interval. Quando isso acontece, o Prometheus começa a enfileirar scrapes, atrasa alertas, e passa a consumir mais CPU do que os workloads que ele deveria monitorar.
# Targets onde o scrape está demorando mais que o interval
scrape_duration_seconds > 55 # para interval de 1m
# Volume de samples por job
scrape_samples_scraped
# Scrapes que excederam o limite de samples
increase(prometheus_target_scrapes_exceeded_sample_limit_total[1h])
Diferencia o interval por job. Não tem por que scrapear métricas de disco a cada 15 segundos.
scrape_configs:
- job_name: 'app-latency'
scrape_interval: 15s
static_configs:
- targets: ['app:9090']
- job_name: 'node-exporter'
scrape_interval: 5m
static_configs:
- targets: ['node-exporter:9100']
E coloca sample_limit como proteção: se um exporter mal configurado começar a gerar samples demais, o scrape falha. O Prometheus continua de pé.
scrape_configs:
- job_name: 'app'
sample_limit: 50000
Melhor perder um scrape do que perder a instância inteira.
Nenhum deles aparece de uma vez. Todos crescem devagar, por semanas, até o dia em que você precisa do Prometheus funcionando. E ele não está.
A boa notícia é que os três são detectáveis antes de virar incidente, com as queries certas e alertas no lugar certo.
]]>Observabilidade que não monitora a si mesma não é observabilidade.
O motivo de importar mesmo se você nunca configurou Envoy diretamente: ele é o data plane por trás de Istio, Envoy Gateway, Contour, Emissary-Ingress, Gloo e vários outros. Se você roda service mesh ou um API gateway construído sobre Envoy, você está exposto ao que está nessas 13 CVEs até atualizar — mesmo que o produto que você usa tenha outro nome na capa.
As 13 CVEs se dividem em dois grupos com implicações bem diferentes.
Esse é o grupo que merece atenção prioritária, porque não é “o processo cai” — é “o controle de acesso não funciona como você configurou”:
safe_regex falhando aberto (GHSA-23xh-2qxr-3xv8, alta severidade): headers HTTP com valores obs-text (bytes fora do padrão ASCII, mas válidos pela RFC) podiam fazer o matcher de regex do RBAC falhar silenciosamente — e quando falha, a política de autorização não bloqueia a requisição. Se seu RBAC depende de regex em headers, isso é bypass de política./stats?format=html não sanitizava nomes de métricas antes de converter pra HTML. Se algum componente do seu sistema consegue injetar nome de métrica arbitrário (nem sempre trivial, mas possível em setups com labels dinâmicos) e alguém abre o painel admin, o payload executa no navegador de quem está olhando.O restante são bugs de estabilidade sérios, mas sem o componente de “sua política de segurança não estava fazendo o que você achava”:
END_STREAM, e no QUIC ao lidar com endereços IPv6 com escopo em clusters Original Dst.SSL_get0_peer_certificates() e um mismatch de allocator que quebrava profiling de heap com tcmalloc.Boa parte dos fixes de segurança vêm atrás de reloadable_features — flags que existem justamente porque a correção muda comportamento observável, não só corrige um bug isolado. Alguns exemplos:
envoy.reloadable_features.strip_path_parameters_per_segment
envoy.reloadable_features.strip_dotdot_segments_with_parameters
envoy.reloadable_features.rbac_respect_ignore_path_parameters
envoy.reloadable_features.re2_use_latin1_mode
envoy.reloadable_features.http2_track_size_of_dropped_host_header
envoy.reloadable_features.sanitize_html_stats_names
Todas vêm habilitadas por padrão a partir dessas versões — ou seja, o fix já está ativo assim que você atualiza, sem passo extra. A flag existe pra permitir reverter caso o novo comportamento quebre algo inesperado no seu tráfego (por exemplo, se você depende de path com parâmetro não normalizado em alguma rota legada). Mas desabilitar qualquer uma dessas flags volta o comportamento vulnerável — trate reversão como último recurso, não como configuração padrão pós-upgrade.
Antes de tudo, descubra qual versão de Envoy você está rodando de fato. Se você usa Envoy direto, é óbvio. Se você usa Istio, Envoy Gateway, Contour ou Emissary, o Envoy embutido tem seu próprio ciclo — a versão do seu control plane não é a versão do Envoy. Confere no changelog do seu projeto qual patch de Envoy ele já empacotou ou vai empacotar.
Prioriza pela combinação que mais te afeta:
Vale atualizar? Sim, e não é “quando der”. Esse não é um patch de rotina com uma pilha de CVEs de baixa severidade — tem bypass de RBAC e de autenticação por path no meio, categorias de falha que normalmente saem sozinhas com aviso maior, não empacotadas junto com fixes de crash. O fato de terem saído juntas, pras quatro branches ativas ao mesmo tempo, é sinal de que o time levou a sério a superfície combinada.