TL;DR — A semana cloud native girou em torno de ownership. Um texto no blog da CNCF mostrou que NIS2 e DORA travam quando a regulação vira ticket de segurança em vez de artefato no sprint da plataforma. Outro defendeu que agentes de IA proponham o próximo estado do sistema pelo mesmo pipeline dos humanos, sem root. E o Kubernetes 1.37 chegou ao OKE com certificados de Pod e DRA estáveis. O recado: evidência de conformidade é entrega de engenharia, não planilha.
A semana passada foi sobre levar a consulta até o dado. Esta voltou para dentro do cluster — e para uma pergunta que quase toda empresa evita fazer em voz alta: quem é o dono do que a auditoria vai pedir?
Não houve um grande lançamento de provedor. Houve, no blog da CNCF, uma sequência de textos de praticantes que, lidos juntos, desenham o mesmo diagnóstico: o time de plataforma virou o lugar onde regulação, segurança e operação precisam se transformar em objetos concretos — policy, log, imagem, pipeline. Quando isso não acontece, a responsabilidade fica num board de tickets que ninguém consegue fechar.
Por que a conformidade trava mesmo com time de segurança dedicado?
Porque a regulação entra na empresa como nome de lei, não como entrega.
O texto da CNCF sobre NIS2 e DORA descreve uma reunião que qualquer engenheiro de plataforma reconhece: jurídico traz um artigo da diretiva, a plataforma olha para a segurança, a segurança olha para a plataforma, e um ticket genérico cai na fila de segurança. Três sprints depois, o cluster não mudou e a evidência não existe. Nas palavras do autor, "a segurança pode escrever a política. A segurança não pode fazer merge de um Helm chart".
A proposta é uma cadeia de rastreabilidade em dois estágios. Risco, jurídico e segurança são donos da interpretação: escopo, questão de controle e definição de evidência. Plataforma e times de aplicação são donos da entrega: o artefato, o item de sprint e a operação recorrente que gera a evidência sem fire drill antes da inspeção. O ponto de transferência é o artefato, não o número do artigo.
| Em vez de um ticket que diz… | …coloque no sprint |
|---|---|
| "Implementar NIS2 art. 21 (cadeia de suprimentos)" | Catálogo de imagens hardened + pipeline de rebuild + SBOM retido no CI |
| "Atender requisito de tratamento de incidentes" | Audit policy do kube-apiserver com logs no SIEM e retenção documentada; runbook com pacote de fatos para notificação no prazo |
| "Controle de acesso conforme regulação" | Gerenciador de segredos como único caminho de credenciais; admission policy com Pod Security Standards restritos e exceções registradas |
O que isso tem a ver com quem opera no Brasil?
Tudo, mesmo que a sigla seja europeia. Quem presta serviço de TIC para clientes na União Europeia pode ser cobrado como fornecedor no escopo do DORA. E o padrão de falha é o mesmo que vemos por aqui com a LGPD e com as resoluções do Banco Central sobre política de segurança cibernética e contratação de nuvem: a norma vira documento, o documento vira fila e o cluster continua igual.
A leitura prática é organizacional antes de ser técnica. Se a sua plataforma Kubernetes é tratada como produto interno, a evidência de conformidade é uma feature desse produto — com dono, estimativa e demo. O texto ainda faz uma ressalva honesta que vale repetir: nenhuma tabela de blog é mapeamento oficial de conformidade; o escopo depende da avaliação de risco e do regulador de cada organização.
Agentes de IA devem ter root no cluster?
Não — e o argumento da semana não foi medo, foi rastreabilidade. Um texto no blog da CNCF defendeu que agentes não devem alterar o sistema diretamente, pela mesma razão que humanos não devem ter root irrestrito em produção: é preciso saber o que mudou e quem mudou. Um AGENTS.md bem escrito não impede um erro irreversível de um sistema não determinístico.
A saída proposta usa algo que o cloud native já tem: sistemas imutáveis, que separam o runtime da definição de estado. O agente roda como workload efêmero e isolado, observa, diagnostica e propõe o próximo estado abrindo um pull request — que passa pela mesma revisão, CI, assinatura e deploy de uma mudança humana. É a mesma lógica de ownership do caso NIS2: a plataforma é dona do caminho até a produção, e quem quer que proponha a mudança (pessoa ou agente) entra por ele.
O Meshery, que virou projeto Incubating da CNCF na mesma semana, seguiu essa linha no roadmap: o novo servidor MCP do projeto dá a assistentes de IA acesso somente leitura ao registry e ao estado do cluster.
O que o kubelet não te avisa?
Que os inodes estão acabando. Uma análise publicada na CNCF mostrou um detalhe que muda o desenho de alertas: o image garbage collection do kubelet age por percentual de bytes (85% para começar, 80% para parar) e nunca olha contagem de arquivos. No Linux, o kubelet tem limite de inodes, mas só na evicção dura — nodefs.inodesFree e imagefs.inodesFree em 5% livres. Ou seja: quando ele reage a inodes, já está expulsando pods. Imagens com milhares de arquivos pequenos esgotam a tabela de inodes com o disco ainda folgado.
É outro caso de ownership: o sinal existe, mas ninguém é dono dele até a emergência. A correção é barata — um alerta de trajetória sobre inodes livres e builds multi-estágio que não carregam lixo para a imagem. Se você está montando essa camada de alertas, o nosso guia de observabilidade self-hosted com a stack LGTM no Kubernetes cobre a base de métricas e regras.
Outros destaques da semana
- Kubernetes 1.37 no OKE. A Oracle disponibilizou o 1.37 no seu Kubernetes gerenciado. Entre as novidades upstream: scale-to-zero no HPA (beta, para métricas de objeto ou externas), inicialização resiliente do watch cache (estável), certificados de Pod com ClusterTrustBundles (estáveis) e DRA estável para GPUs e dispositivos. O scale-to-zero nativo encosta no que muita gente já fazia com KEDA — veja quando cada um faz sentido no nosso artigo sobre autoscaling por sinal com KEDA e HPA.
- Fim de vida na AWS. O roundup semanal da AWS listou serviços entrando em manutenção (como o Chime SDK SIP Media Application e o WorkSpaces Secure Browser) e em sunset (Managed Blockchain e DevOps Guru). Quem depende deles precisa de plano de saída com data — de novo, um artefato com dono.
- OVHcloud entra na CNCF como Platinum. Um provedor europeu independente ganha assento no Governing Board da fundação. Para quem busca alternativas fora dos três grandes hyperscalers com APIs do ecossistema CNCF, é mais um sinal de que portabilidade é critério de compra, não detalhe.
- Catálogo Iceberg sobre Spanner. O Google detalhou o catálogo runtime do seu Lakehouse, apoiado no Spanner, para commits atômicos de metadados Iceberg em escala — continuação direta da conversa da semana passada sobre formato aberto como contrato.
- Resiliência de IA vira tema de arquitetura. A Equinix defendeu que aplicações de IA em produção precisam de plano B: redundância de modelo, failover entre regiões e observabilidade de latência. É o mesmo raciocínio de DR aplicado a uma dependência nova.
Perguntas Frequentes
NIS2 e DORA são leis europeias. Por que uma empresa brasileira deveria se importar?
Por dois motivos. Primeiro, quem atende clientes ou matrizes na União Europeia pode cair no escopo como fornecedor de TIC e ser cobrado por evidência. Segundo, o problema descrito — regulação virando fila do time de segurança sem artefato técnico — é exatamente o que acontece aqui com LGPD e com as resoluções do Banco Central sobre segurança cibernética e contratação de nuvem. O modelo de rastreabilidade (requisito → questão de controle → artefato → evidência recorrente) funciona para qualquer regulação.
Quais artefatos Kubernetes costumam servir de evidência de conformidade?
Os mais comuns são: audit policy do kube-apiserver com logs enviados ao SIEM e retenção documentada; admission policy aplicando Pod Security Standards restritos e bloqueando tags de imagem não fixadas, com exceções registradas; catálogo de imagens hardened com pipeline de rebuild; um gerenciador de segredos como único caminho de credenciais; SBOM gerado e retido no CI; e runbook de incidente com o pacote de fatos para notificação no prazo. Todos podem ser estimados, demonstrados em sprint review e produzir evidência sem trabalho manual.
Deixar um agente de IA abrir pull request em vez de executar comandos não deixa tudo mais lento?
Deixa o caminho mais longo, mas é o mesmo caminho que uma mudança humana já percorre: revisão, CI, assinatura e deploy. Em troca você ganha rastreabilidade (o que mudou e quem mudou), rollback pelo histórico e a garantia de que um erro não determinístico do agente não chega direto à produção. O agente continua útil observando, diagnosticando e propondo; quem aplica é a plataforma.
Preciso de um alerta de inodes separado se já monitoro o uso de disco?
Sim. O image garbage collection do kubelet atua por percentual de bytes, e o único limite de inodes padrão no Linux é a evicção dura com 5% livres — ou seja, o kubelet só reage quando já está expulsando pods. Workloads com muitos arquivos pequenos, como imagens com node_modules, esgotam inodes com o disco ainda folgado. Um alerta de trajetória sobre inodes livres (por exemplo, com predict_linear) dá tempo de agir antes da evicção.
Vale atualizar para o Kubernetes 1.37 agora?
Se você roda workloads event-driven ou de GPU, os ganhos são concretos: scale-to-zero no HPA (em beta, para métricas de objeto ou externas), DRA estável para alocar GPUs e dispositivos, e certificados de Pod com ClusterTrustBundles estáveis para identidade de workload. Como em qualquer minor, teste em um cluster de homologação, revise APIs depreciadas e confirme a compatibilidade dos add-ons antes de promover a produção.