Nesta edição: atualização do pgAdmin 4 v9.18 com quatro correções de segurança; recursos de permissões e bind mounts no Kubernetes v1.37; remoções de opções depreciadas no CRI-O v1.37.0; e práticas para observabilidade, cache, rede e integrações de IA.
Leitura de aproximadamente 5 minutos
Em 30 segundos
Atualize o pgAdmin 4 para v9.18: a versão corrige quatro vulnerabilidades, incluindo bypass de autenticação em modo Webserver authentication.
Planeje a adoção dos controles de noexec, nosuid, nodev e permissões de emptyDir do Kubernetes v1.37 para volumes graváveis.
Antes de atualizar para CRI-O v1.37.0, substitua insecure_registries e --insecure-registry pela configuração insecure em registries.conf.
01Segurança & depreciações
pgAdmin 4 v9.18 corrige quatro vulnerabilidades de segurança
O pgAdmin 4 v9.18 inclui 29 correções de bugs e corrige CVE-2026-86861 a CVE-2026-86864. As correções abrangem bypass de autenticação no modo Webserver authentication, injeção de argumentos e connection string em Backup, injeção de connection string em Restore e Maintenance e uma falha de time-of-check to time-of-use na gravação de arquivos. A versão também endurece a Content-Security-Policy para scripts inline.
Por que importa em produção
No modo Webserver authentication, um cliente que alcançasse o pgAdmin poderia afirmar uma identidade por cabeçalho, inclusive administrativa, sem apresentar credencial. Outras falhas poderiam redirecionar conexões e credenciais exportadas ou permitir escrita fora do diretório de armazenamento do usuário.
O que verificar
Atualize para pgAdmin 4 v9.18 conforme o processo de mudança. Revise a exposição de rede, a autenticação webserver e a lista de proxies confiáveis. Valide os fluxos de Backup, Restore e Maintenance após a atualização.
Kubernetes v1.37 adiciona controles para mounts e emptyDir
O Kubernetes v1.37 adiciona modos de permissão para emptyDir e opções de bind mount. Os controles incluem noexec, nosuid e nodev, além da possibilidade de definir permissões para emptyDir, como o sticky bit em modo 01777. Antes disso, emptyDir era criado com modo 0777 e não havia mecanismo nativo para aplicar essas opções ao bind mount criado para volumes em containers.
Por que importa em produção
Volumes graváveis podem permitir download, chmod +x e execução de binários mesmo com readOnlyRootFilesystem: true quando noexec não está presente. Em Pods com múltiplos containers compartilhando emptyDir, o sticky bit ajuda a impedir que um container exclua ou renomeie arquivos de outro.
O que verificar
Mapeie volumes graváveis e dependências de execução a partir deles. Defina políticas para noexec, nosuid e nodev e avalie modos de emptyDir compatíveis com cada aplicação, incluindo 01777 onde houver diretórios compartilhados como /tmp.
CRI-O v1.37.0 remove opções depreciadas de registries inseguros
O CRI-O v1.37.0 remove a configuração insecure_registries e a flag --insecure-registry. A configuração insecure em registries.conf deve ser usada em substituição. A versão também adiciona enable_cni_status_monitoring, desabilitada por padrão, e cni_status_grace_period, com padrão de 60s, para monitoramento contínuo de CNI STATUS e tolerância a interrupções breves durante upgrades. Os artefatos incluem assinatura, SBOM em SPDX, relatório OpenVEX e atestação de proveniência SLSA.
Por que importa em produção
A remoção pode interromper upgrades em nós que ainda usam as opções depreciadas. O monitoramento contínuo de status CNI altera a forma de detectar indisponibilidades de plugins, enquanto os artefatos de cadeia de suprimentos podem ser incorporados à validação de releases.
O que verificar
Audite manifests, arquivos de configuração e automações em busca de insecure_registries e --insecure-registry. Migre para registries.conf, teste enable_cni_status_monitoring com o período de 60s e valide assinaturas, SBOM e proveniência antes da implantação.
Análise automatizada de causa-raiz para workloads com Prometheus
A orientação aborda análise automatizada de causa-raiz com Amazon Managed Service for Prometheus e AWS DevOps Agent. O foco são workloads instrumentados com Prometheus em Kubernetes, Amazon EC2, containers e servidores on-premises, buscando reduzir o tempo gasto na investigação de falsos positivos e na correlação manual de métricas.
Por que importa em produção
Alertas baseados em limiares estáticos podem gerar fadiga e aumentar o tempo de investigação de degradações. A correlação automatizada pode apoiar o diagnóstico, mas seu resultado depende da instrumentação e dos dados disponíveis.
O que verificar
Conduza um piloto com alertas e incidentes conhecidos. Meça a precisão das correlações e o tempo de diagnóstico, e estabeleça revisão operacional para conclusões automatizadas antes de usá-las em resposta a incidentes.
Lookup em três camadas com Bloom filter, Valkey e Aurora PostgreSQL
O padrão combina Bloom filter, cache de correspondência exata e uma fonte relacional de verdade em Amazon ElastiCache for Valkey e Amazon Aurora PostgreSQL. A proposta é realizar decisões de associação abaixo de um milissegundo em throughput de pico sem risco de falsos positivos, usando a camada exata e a fonte relacional para preservar a correção.
Por que importa em produção
Bloom filters podem reduzir consultas desnecessárias, mas isoladamente admitem falsos positivos. A composição com cache de correspondência exata e fonte de verdade relacional busca manter a correção nas decisões de associação.
O que verificar
Valide o padrão com a distribuição real dos dados. Teste invalidação e coerência de cache, indisponibilidade de cada camada e latências p95 e p99 antes de adotá-lo em fluxos críticos.
Incidente de taxas elevadas de erro em modelos de API foi resolvido
Foram registradas taxas elevadas de erro em modelos de API. O incidente foi marcado como resolvido, com recuperação completa dos serviços impactados. Entre os componentes afetados estão Realtime, Files, Embeddings, Responses, Login, Sora, Images, Chat Completions, Audio, Moderations, Batch e Fine-tuning.
Por que importa em produção
Aplicações dependentes desses componentes podem ter enfrentado falhas durante o período. O impacto potencial abrange fluxos de inferência, processamento assíncrono, autenticação, arquivos e modalidades como áudio e imagens.
O que verificar
Revise logs, métricas e filas do período afetado. Confirme o comportamento de retries e fallbacks e verifique perda, duplicação ou processamento parcial de operações.
Escolha de arquitetura de inspeção para AWS Network Firewall
O conteúdo compara três padrões de implantação para AWS Network Firewall em ambientes multi-VPC e multi-conta: Traditional Inspection Amazon VPC, Multiple VPC Endpoints, lançado em maio de 2025, e Transit Gateway Native Attachment, lançado em julho de 2025. O objetivo é apoiar uma arquitetura consistente para conformidade, detecção de ameaças e filtragem de tráfego.
Por que importa em produção
A arquitetura de inspeção influencia roteamento, operação e a aplicação de controles em redes distribuídas. Padronizar sem avaliar a topologia e os requisitos pode introduzir limitações operacionais ou de cobertura de tráfego.
O que verificar
Mapeie VPCs, contas, caminhos de tráfego e requisitos de inspeção. Compare os três padrões com as restrições de roteamento e os controles necessários antes de definir o padrão para novas implantações.
A versão v3.13.0 do SDK openai-python, publicada em 2026-09-10, adiciona a Agents API.
Por que importa em produção
A alteração habilita o uso da Agents API em aplicações Python e pode demandar validação de compatibilidade em clientes e integrações existentes.
O que verificar
Teste openai-python v3.13.0 em staging. Verifique a compatibilidade das dependências, dos clientes e dos fluxos que usam agentes antes da atualização em produção.
Priorize uma janela de atualização para pgAdmin 4 v9.18 e, em paralelo, audite nós CRI-O quanto ao uso de insecure_registries e --insecure-registry antes do upgrade para v1.37.0.
Radar de Produção — Semana 38 de 2026 | Caio Barbieri