Neste documento, descrevemos como o Google gerencia vulnerabilidades e patches de segurança no Google Kubernetes Engine (GKE). Essas informações podem ser úteis para especialistas em segurança que oferecem suporte à resolução de problemas ou vulnerabilidades de segurança que precisam de assistência estratégica, como incidentes e problemas encaminhados pelo suporte.
Como corrigir responsabilidade compartilhada
A aplicação de patches é uma responsabilidade compartilhada entre o Google e o cliente, conforme descrito em Responsabilidade compartilhada do GKE.
Como descobrimos vulnerabilidades
O Google investiu grandes investimentos em um projeto de segurança proativo e reforço da proteção, mas até mesmo os sistemas de software mais projetados podem ter vulnerabilidades. Para encontrar essas vulnerabilidades e corrigi-las antes de serem exploradas, o Google fez investimentos significativos em várias frentes.
Para fins de patch, o GKE é uma camada de sistema operacional (SO) com contêineres sendo executados na parte superior. Os sistemas operacionais, Container-Optimized OS ou Ubuntu, são reforçados e contêm a quantidade mínima de software necessária para executar contêineres. Os recursos do GKE são executados como contêineres sobre as imagens de base. O GKE trabalha de forma consistente para reduzir o número de dependências que os componentes do sistema têm, o que ajuda a reduzir a superfície de ataque e melhorar a eficiência do gerenciamento de vulnerabilidades. Por exemplo, os componentes do sistema do GKE podem usar imagens de base mínimas quando possível.
O Google identifica e corrige vulnerabilidades e patches ausentes das seguintes maneiras:
Container-Optimized OS: o Google verifica as imagens para identificar possíveis vulnerabilidades e patches ausentes. A equipe do Container-Optimized OS revisa e resolve problemas.
Ubuntu: o Canonical fornece ao Google versões do sistema operacional que têm todos os patches de segurança disponíveis.
O Google verifica os contêineres usando o Artifact Registry Container Analysis para descobrir vulnerabilidades e patches ausentes no Kubernetes e nos contêineres gerenciados pelo Google. Se houver correções disponíveis, o scanner começará automaticamente o processo de patch e liberação.
Além da verificação automatizada, o Google descobre e corrige vulnerabilidades desconhecido aos scanners das seguintes maneiras.
O Google realiza auditorias, testes de penetração e descoberta de vulnerabilidades em todas as plataformas. Para conferir uma lista de plataformas, consulte a seção anterior Responsabilidade compartilhada de aplicação de patch.
Equipes especializadas do Google e fornecedores confiáveis de terceiros conduzem suas próprias pesquisas de ataque. O Google também trabalhou com o CNCF para oferecer a maior parte da organização e experiência com consultoria técnica para a auditoria de segurança do Kubernetes.
O Google envolve ativamente a comunidade de pesquisa de segurança por meio de vários programas de recompensa por vulnerabilidade. Um programa dedicado de recompensas de vulnerabilidade do Google Cloud oferece recompensas significativas, incluindo US $133.337 para a melhor vulnerabilidade de nuvem encontrada a cada ano. No GKE, há um programa que recompensa os pesquisadores de segurança caso eles possam interromper nossos controles de segurança. O programa abrange todas as dependências de software do GKE.
O Google colabora com outros parceiros de software de código aberto e do setor que compartilham vulnerabilidades, pesquisa de segurança e patches antes do lançamento público da vulnerabilidade. O objetivo desta colaboração é aplicar patches às principais partes da infraestrutura da Internet antes que a vulnerabilidade seja anunciada para o público. Em alguns casos, o Google contribui com as vulnerabilidades encontradas para essa comunidade. Por exemplo, o Projeto Zero do Google descobriu e divulgava as vulnerabilidades do Spectre e Meltdown. A equipe de segurança do Google Cloud também encontra e corrige regularmente as vulnerabilidades na Kernel-based Virtual Machine (KVM).
A colaboração de segurança do Google acontece em muitos níveis. Sometimess vezes, ocorre por meio de programas em que as organizações se inscrevem para receber notificações de pré-lançamento sobre vulnerabilidades de software para produtos como o Kubernetes e Envoy A colaboração também acontece de maneira informal devido ao nosso engajamento com muitos projetos de código aberto, como o kernel do Linux, ambientes de execução de contêiner, tecnologia de virtualização e outros.
No Kubernetes, o Google é um membro ativo e fundador do Comitê de Resposta de Segurança (SRC, na sigla em inglês) e escreveu grande parte do Processo de liberação de segurança (em inglês). O Google é membro da lista de distribuidores do Kubernetes (em inglês) que recebe uma notificação prévia de vulnerabilidades e está envolvido na triagem, na aplicação de patches, no desenvolvimento de mitigação e na comunicação de quase {101. }todas as vulnerabilidades graves de segurança do Kubernetes. O Google também descobriu várias vulnerabilidades do Kubernetes, como CVE-2019-11254, CVE-2019-11255 e CVE-2021-25741.
Embora vulnerabilidades menos graves sejam descobertas e corrigidas fora desses processos, as vulnerabilidades de segurança mais graves são informadas de modo privado por meio de um dos canais listados anteriormente. Os relatórios antecipados dão ao Google tempo antes que a vulnerabilidade se torne pública para pesquisar como ela afeta o GKE, desenvolver patches ou mitigações e preparar orientações e comunicações para os clientes. Quando possível, o Google corrige todos os clusters antes da versão pública da vulnerabilidade.
Como as vulnerabilidades são classificadas
O GKE faz grandes investimentos em fortalecimento da segurança de toda a pilha, incluindo o SO, o contêiner, o Kubernetes e as camadas de rede, além de definir bons padrões, configurações com segurança reforçada e componentes gerenciados. Combinados, esses esforços ajudam a reduzir o impacto e a probabilidade das vulnerabilidades.
A equipe de segurança do GKE classifica as vulnerabilidades de acordo com o sistema de pontuação de vulnerabilidades do Kubernetes. As classificações consideram muitos fatores, incluindo a configuração do GKE e o reforço da proteção de segurança. Devido a esses fatores e aos investimentos que o GKE faz na segurança, as classificações de vulnerabilidade do GKE podem ser diferentes de outras fontes de classificação.
Veja na tabela a seguir as categorias de gravidade de vulnerabilidade:
| Gravidade | Descrição |
|---|---|
| Crítico | Uma vulnerabilidade facilmente explorada em todos os clusters por um invasor remoto não autenticado que leva ao comprometimento total do sistema. |
| Alta | Uma vulnerabilidade fácil de explorar para muitos clusters que levam à perda de confidencialidade, integridade ou disponibilidade. |
| Média | Uma vulnerabilidade que pode ser explorada para alguns clusters em que a perda de confidencialidade, integridade ou disponibilidade é limitada por configurações comuns, dificuldade de exploração, acesso necessário ou interação do usuário. |
| Baixa | Todas as outras vulnerabilidades. A exploração é improvável ou as consequências da exploração são limitadas. |
Consulte os boletins de segurança para ver exemplos de vulnerabilidades, correções e mitigações, além das respectivas classificações.
Como as vulnerabilidades são corrigidas para clusters do GKE
A correção de uma vulnerabilidade envolve o upgrade para um novo número de versão do GKE. As versões do GKE incluem componentes com controle de versão para o sistema operacional, componentes do Kubernetes e outros contêineres que compõem a plataforma do GKE. A correção de algumas vulnerabilidades exige apenas um upgrade do plano de controle, executado automaticamente pelo Google no GKE, enquanto outras requerem o plano de controle e os upgrades do nó.
Para manter os clusters protegidos contra vulnerabilidades de todas as gravidades, recomendamos seguir as práticas recomendadas para upgrades de cluster do GKE e garantir que seu cluster receba patches de segurança de maneira oportuna.
O Google recomenda fazer upgrade dos clusters do Kubernetes pelo menos uma vez por mês. Para conferir uma lista de plataformas, consulte a seção anterior Responsabilidade compartilhada de aplicação de patch.
Alguns verificadores de segurança ou verificações manuais de versões podem presumir incorretamente que um componente como runc ou containerd não tem um patch de segurança upstream específico. O GKE aplica patches aos componentes regularmente e executa apenas upgrades de versão quando necessário, ou seja, os componentes do GKE são funcionalmente semelhantes a seus equivalentes upstream, mesmo se a versão do componente GKE não corresponde à versão upstream número. Para detalhes sobre uma CVE específica, consulte Boletins de segurança do GKE.
Cronogramas de aplicação de patches
O objetivo do Google é reduzir as vulnerabilidades detectadas em um período apropriado para os riscos que elas representam. O GKE está incluído na ATO provisória do FedRAMP daGoogle Cloud que exige que as vulnerabilidades conhecidas sejam corrigidas em períodos específicos de acordo com o nível de gravidade delas, conforme especificado no controle RA-5(d) do registro de avaliação de risco (RA) RA-5, "Verificação de vulnerabilidades", na planilha Base de controles de segurança do FedRAMP.
Para cada vulnerabilidade conhecida, o objetivo do GKE é lançar versões de patch que corrijam a vulnerabilidade no período correspondente. Depois que o GKE disponibilizar versões de patch para corrigir uma vulnerabilidade conhecida, faça upgrade dos clusters para essas versões e cumpra os prazos de aplicação de patch da sua organização.
Como as vulnerabilidades e os patches são comunicados
As melhores fontes de informações atuais sobre vulnerabilidades e patches de segurança do GKE são os boletins de segurança e as notas da versão.
A partir de 1º de junho de 2026, o GKE não vai mais publicar boletins de segurança para a Google Distributed Cloud (somente software), o GKE na AWS ou o GKE no Azure. Para conferir boletins de segurança mais recentes e correções de vulnerabilidade para esses produtos, consulte os seguintes documentos:
Vs vezes, as vulnerabilidades são mantidas privadas sob os embargos por tempo limitado. Embargos ajuda a evitar a publicação precoce de vulnerabilidades que possam levar a tentativas de exploração generalizadas antes que as etapas possam ser tomadas para solucioná-las. Em situações de embargo, as notas da versão se referem a "atualizações de segurança" até que a suspensão seja liberada. Depois que o embargo é levantado, o Google atualiza as notas da versão para incluir as vulnerabilidades específicas.
A equipe de segurança do GKE publica boletins de segurança para vulnerabilidades de gravidade alta e crítica. Quando a ação do cliente for necessária para resolver essas vulnerabilidades desse tipo, o Google entrará em contato com os clientes por e-mail. Além disso, o Google também pode entrar em contato com os clientes por meio de contratos de suporte por canais de suporte.
Qual é a maneira mais rápida de instalar um patch de segurança?
Todos os clusters vão receber patches automaticamente com os upgrades automáticos do GKE. Esta seção descreve como aplicar patches mais rápido do que os upgrades automáticos para correções de segurança específicas ou de forma contínua. Ao combinar ambientes de teste, upgrades manuais cross-channel, configurações aceleradas de patch e notificações baseadas em eventos, é possível reduzir os prazos de entrega de patches.
O GKE gerencia os lançamentos de versões em todos os canais para garantir que as novas versões sejam qualificadas e testadas. Para reduzir os prazos de atualização, você precisa entender como esses rollouts funcionam e adaptar o comportamento padrão para atender às suas necessidades específicas.
Para testar uma versão com patch, execute-a em clusters ao longo do tempo para observar a estabilidade. Esse processo ajuda a detectar bugs que só aparecem após o uso prolongado em diversos ambientes. Para garantir tempo de imersão suficiente, os lançamentos de patch do GKE são introduzidos primeiro no canal rápido, seguido pelos canais regular e estável. As versões também são testadas em cada canal antes de se tornarem o destino de upgrade dele.
Qualificar patches antecipadamente e gerenciar o lançamento com o sequenciamento de lançamento
Para qualificar um patch de segurança que você quer acelerar, use o sequenciamento de lançamento para fazer o lançamento em vários ambientes, testando um patch em outros clusters do GKE antes de fazer upgrade do ambiente de produção. Essa abordagem permite verificar a compatibilidade da carga de trabalho e detectar problemas assim que uma correção de segurança é lançada pelo Google. Em seguida, aplique a versão corrigida ao restante da frota e controle o tempo de imersão restante.
Reduza os atrasos de absorção com upgrades automáticos acelerados de patch
Como alternativa, é possível consumir patches mais rapidamente ativando os upgrades automáticos acelerados de patch para seus clusters. Esse recurso instrui o GKE a ignorar o tempo de imersão no canal para atualizações de patch, principalmente patches de segurança. Se você usar essa abordagem, o Google recomenda executar um cluster de teste no canal rápido (também com upgrades automáticos de patch acelerados) para qualificar patches.
Upgrades manuais para versões de patch mais recentes nos canais Regular e Stable
Se as cargas de trabalho de produção estiverem em clusters inscritos nos canais Regular ou Estável, não será necessário sair desses canais nem esperar que o lançamento automático e gradual de um patch chegue até você se houver uma atualização de segurança específica que precise ser priorizada.
Se você qualificou a versão corrigida, é possível iniciar manualmente upgrades nos clusters Regular ou Stable para essa versão de patch exata e controlar o tempo de imersão restante.
Automatizar o gerenciamento de patches com notificações de cluster
Não é necessário monitorar a página da Web de boletins de segurança para informações de patch. Para receber notificações programáticas rápidas de patches disponíveis e acionar ações de qualificação e upgrade de patches, use as notificações de cluster.
Para receber notificações sobre boletins de segurança ou upgrades programados, configure suas notificações para filtrar especificamente os seguintes tipos de eventos:
Com as notificações de cluster, você recebe mensagens em tempo real quando esses eventos acontecem. É possível integrar essas notificações aos seus sistemas de gerenciamento de eventos (SIEM) e informações de segurança, operações de chat ou acionar pipelines de teste automatizados.