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. Diferentes plataformas têm diferentes responsabilidades. Consulte os tópicos a seguir sobre cada plataforma para mais detalhes:
- GKE
- Google Distributed Cloud (somente software) no VMware
- GKE na AWS
- Google Distributed Cloud (somente software) em bare metal
- GKE no Azure
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 aplicação de patches, o GKE é uma camada do sistema operacional (SO) com contêineres em execução. 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 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 Como corrigir responsabilidade compartilhada.
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 Google Cloud de recompensas de vulnerabilidade 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 Google Cloud equipe de segurança 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 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 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, nós recomendamos seguir as práticas recomendadas para upgrades de cluster do GKE para ajudar a garantir que o cluster receba patches de segurança em tempo hábil.
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 Como corrigir responsabilidade compartilhada.
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 Google Cloud's ATO provisória do FedRAMP 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 de linha de base de controles de segurança do FedRAMP.
Para cada vulnerabilidade conhecida, o objetivo do GKE é lançar versões de patch que corrigem a vulnerabilidade dentro do período correspondente. A Google Cloud ATO provisória do FedRAMP não inclui o Google Distributed Cloud, o GKE na AWS, o GKE no Azure ou os clusters anexados do GKE, mas buscamos os mesmos prazos de correção nesses produtos. Depois que o GKE disponibiliza versões de patch para corrigir uma vulnerabilidade conhecida, faça upgrade dos clusters para essas versões para atender aos prazos de aplicação de patches da sua organização.
Como as vulnerabilidades e os patches são comunicados
A melhor fonte para informações atuais sobre vulnerabilidades e patches de segurança é no feed de boletins de segurança dos seguintes produtos:
- Google Kubernetes Engine (GKE)
- Google Distributed Cloud (somente software) no VMware
- GKE na AWS
- GKE no Azure
- Google Distributed Cloud (somente software) em bare metal
Esses boletins seguem um esquema de numeração de vulnerabilidade comum Google Cloud e estão vinculados à página principal Google Cloud de boletins e às notas da versão do GKE. Cada página de boletins de segurança tem um feed RSS no qual os usuários podem se inscrever para receber atualizações.
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 sobre vulnerabilidades de gravidade alta e crítica. Quando a ação do cliente for necessária para resolver essas vulnerabilidades de alta e crítica gravidade, 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 meio de canais de suporte.
Qual é a maneira mais rápida de instalar um patch de segurança?
Todos os clusters vão permanecer corrigidos 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 de patch aceleradas e notificações orientadas a eventos, é possível reduzir os prazos de entrega de patches.
O GKE gerencia os lançamentos de versões em canais de lançamento para garantir que as novas versões sejam qualificadas e absorvidas. Para reduzir os prazos de entrega de patches, é necessário entender como esses lançamentos funcionam e, em seguida, adaptar o comportamento padrão para atender às suas necessidades específicas.
A absorção de uma versão corrigida envolve a execução dela 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 um tempo de imersão suficiente, as versões de patch do GKE são introduzidas primeiro no canal rápido, seguido pelo normal e estável. As versões também são absorvidas em cada canal antes de se tornarem o destino do upgrade para o canal.
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 lançar em ambientes, testando um patch em outros clusters do GKE antes de fazer upgrade do ambiente de produção ambiente. Essa abordagem permite verificar a compatibilidade da carga de trabalho e detectar problemas assim que uma correção de segurança for lançada pelo Google. Em seguida, é possível aplicar a versão corrigida ao restante da frota e controlar o tempo de imersão restante.
Reduzir atrasos de absorção com upgrades automáticos de patch acelerados
Como alternativa, é possível consumir patches mais rapidamente ativando upgrades automáticos de patch acelerados para seus clusters. Esse recurso informa ao GKE para 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 em canais normais e estáveis
Se as cargas de trabalho de produção estiverem em clusters inscritos nos canais normal ou estável, não será necessário sair desses canais ou aguardar o lançamento automático e gradual de um patch para chegar até você se houver uma atualização de segurança específica que você precise priorizar.
Se você qualificou a versão corrigida, é possível iniciar upgrades manualmente nos clusters em normal ou estável para essa versão de patch exata para 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 qualificação e as ações de upgrade de patch, é possível usar notificações de cluster.
Para receber notificações de boletins de segurança ou upgrades programados, configure as notificações para filtrar especificamente os seguintes tipos de evento:
As notificações de cluster permitem receber mensagens em tempo real quando esses eventos ocorrem. É possível integrar essas notificações aos sistemas de gerenciamento de eventos e informações de segurança (SIEM, na sigla em inglês), operações de chat ou acionar pipelines de teste automatizados.