Testar com sucesso o KernelCare Live Patching: melhores práticas para administradores

Como classificar corretamente o KernelCare Livepatch

O KernelCare é o agente da TuxCare para Aplicação de correções em tempo real no kernel em sistemas Linux suportados. Este agente aplica as correções de segurança disponibilizadas ao kernel em execução, sem que seja necessário reiniciar imediatamente o servidor. A aplicabilidade de um patch depende da combinação específica entre a compilação do kernel, a distribuição e a arquitetura; a mera disponibilidade de um pacote do agente não garante, por si só, esse suporte.

Do ponto de vista técnico, o framework Upstream Linux Livepatch descreve uma transição de consistência, na qual as tarefas afetadas mudam de forma segura para o código alterado. Esta documentação explica o framework geral do kernel, mas não necessariamente a forma de implementação de cada variante do KernelCare. Por conseguinte, no que diz respeito a funcionalidades específicas do produto e a decisões operacionais, as indicações fornecidas por TuxCare determinante.

Um patch descarregado ou marcado como aplicado comprova, numa primeira fase, o funcionamento da cadeia de patches. Não comprova, porém, que as ligações à base de dados, os acessos ao armazenamento, os percursos de rede, os trabalhos em lote e as transações de negócio permaneçam isentos de erros sob carga real. Por isso, um teste robusto avalia em conjunto o estado do patch, as métricas do sistema e os resultados das aplicações.

Ordinárias Atualizações do kernel continuam a ser necessárias. Os patches dinâmicos não alteram o pacote do kernel instalado e não abrangem automaticamente o suporte de hardware, as alterações de funcionalidades ou todas as adaptações de controladores de um novo kernel. Além disso, a TuxCare apenas disponibiliza patches para um kernel específico enquanto o seu fabricante publicar atualizações de segurança para a série em questão.

O KernelCare diz ainda respeito ao kernel e deve ser distinguido da aplicação de patches no espaço do utilizador. Um teste bem-sucedido não comprova nem o estado atual dos patches do LibCare nem a correção total de todas as vulnerabilidades do anfitrião. A aplicação de patches em tempo real complementa, assim, a gestão de pacotes e a gestão de alterações: permite que as correções urgentes do kernel entrem em vigor mais cedo, enquanto as atualizações regulares de pacotes e os reinícios planeados continuam a fazer parte do plano de manutenção.

Componentes, plataformas e delimitações claras

Antes do teste, é necessário separar claramente a arquitetura do TuxCare. O agente do KernelCare é executado no anfitrião de destino, obtém conjuntos de correções e aplica-os ao kernel em execução. ePortal por outro lado, trata-se de um componente opcional e autónomo destinado ao controlo centralizado de fontes de patches e implementações, por exemplo, em redes controladas ou isoladas. Ambos os componentes desempenham funções diferentes e não são intercambiáveis.

À parte disso, o LibCare funciona como um complemento para componentes do espaço do utilizador, como a glibc ou o OpenSSL. Um teste bem-sucedido do KernelCare não verifica nem a instalação nem o estado das correções do LibCare. Por isso, os relatórios de teste devem registar estes níveis separadamente: o estado das correções do kernel, a distribuição centralizada e a aplicação de correções no espaço do utilizador requerem, respetivamente, comprovativos próprios, aprovações e, se for caso disso, sistemas de teste próprios.

A primeira tarefa prática consiste na criação de um inventário fiável. É necessário registar a distribuição e a versão, o kernel efetivamente inicializado, a arquitetura, o tipo de virtualização, os mecanismos de segurança ativados e os módulos do kernel instalados. Igualmente importantes são os controladores de armazenamento e de rede, bem como os agentes de segurança, de cópia de segurança e de monitorização. Estas características determinam se um anfitrião de teste representa de forma realista o futuro grupo de produção e se o patch disponibilizado é compatível com a compilação do kernel.

A decisão determinante sobre o suporte não é tomada apenas por uma lista de distribuição geral. Verifique a combinação específica de distribuição, versão do kernel e arquitetura na base de dados de compatibilidade e patches da TuxCare. Só esta verificação permite distinguir um agente instalável de um kernel efetivamente suportado. Deve ser documentada antes de qualquer planeamento de implementação e repetida em caso de mudança de kernel.

O Secure Boot constitui uma classe de plataforma própria. O agente necessita de uma cadeia de confiança adequada para os seus módulos do kernel. A TuxCare indica que, para o processo automatizado de Secure Boot em sistemas RPM suportados, é necessária, no mínimo, a versão 3.0-2 do agente; esta indicação não constitui uma versão mínima geral para o KernelCare e não se aplica ao registo manual do MOK. O processo automatizado pressupõe, entre outros requisitos, o arranque EFI, o shim e o Secure Boot ativado, não estando previsto para o Debian ou o Ubuntu. Por conseguinte, é necessária uma reinicialização planeada para validar esta configuração.

Antes da instalação, é também necessário verificar se existem serviços de «Live Patching» já em funcionamento. De acordo com a TuxCare, o KernelCare não pode ser utilizado em paralelo com o Canonical Livepatch. A operação em paralelo não constitui um teste de compatibilidade válido, mas sim um critério de exclusão: primeiro, o serviço existente deve ser removido de acordo com o procedimento operacional aprovado ou a plataforma de teste deve ser desligada. A comparação interna entre KernelCare, Ksplice, kpatch e kGraft.

O que um teste fiável tem de demonstrar

Um teste fiável começa com objetivos verificáveis, em vez de uma simples mensagem do tipo „Patch instalado“. É necessário comprovar a existência de um kernel em execução compatível, uma fonte de patches acessível e autorizada, bem como a aplicação do conjunto de patches mais recente. Além disso, a equipa deve registar a versão de segurança efetiva comunicada pela KernelCare. Estas comprovações confirmam a cadeia de fornecimento técnica, mas ainda não o funcionamento da aplicação.

O segundo nível de verificação é o Saúde das aplicações. Os serviços têm de permanecer acessíveis, as transações centrais têm de ser concluídas corretamente e as interfaces têm de fornecer os resultados esperados. No caso dos sistemas de bases de dados, a replicação e as consultas podem ser decisivas; no caso dos serviços Web, por exemplo, a autenticação, as tarefas em segundo plano e as integrações externas fazem parte do âmbito dos testes.

Para o acompanhamento, fornece kcarectl --status Códigos de saída legíveis por máquina. A TuxCare atribui o valor 0 ao nível de patch mais recente, 1 à ausência de patches aplicados, 2 a novos patches ainda não aplicados e 3 a um kernel não suportado. Estes estados são adequados para regras de alarme, mas devem ser avaliados em conjunto com registos do kernel, métricas de serviços e verificações técnicas.

Distinga ainda entre a versão inicializada e a versão efetiva. uname -r mostra o kernel inicializado, enquanto kcarectl --uname que indique a versão segura do kernel identificada pela TuxCare. Se estas informações não forem devidamente tidas em conta no Scanner e na CMDB, um Livepatch eficaz pode aparecer como uma atualização em falta.

A aprovação pressupõe a apresentação de documentação técnica completa, a aprovação nos testes de aplicação e um ciclo de carga representativo. Pode tratar-se de uma janela de processamento em lote, de um pico de carga típico ou de um failover planeado. No caso de um kernel não suportado, de um aumento de erros ou de falhas nos testes específicos, a expansão é interrompida e o resultado é analisado; um estado positivo do agente não anula esses sinais.

Criar uma linha de base de staging próxima do ambiente de produção

Um teste robusto começa com um host de staging que reflita, com a maior precisão possível, o público-alvo futuro. Registe a distribuição, o kernel inicializado, a arquitetura, o tipo de virtualização e os mecanismos de segurança ativados. O inventário deve incluir igualmente os módulos do kernel carregados ou críticos para o funcionamento, os caminhos de armazenamento e de rede, os agentes de segurança e monitorização, bem como os componentes centrais da aplicação. A compatibilidade deve ser sempre verificada para o kernel que está efetivamente em execução e não apenas para a distribuição.

Além disso, antes da intervenção, documente o estado da aplicação: transações técnicas bem-sucedidas, taxas de erro, tempos de resposta, tarefas em segundo plano e, se necessário, a adesão ao cluster ou o estado da replicação. Estes Linha de base permite identificar eventuais discrepâncias posteriores. Verifica também se existe uma cópia de segurança ou um instantâneo adequado à aplicação e como se decide, na prática, a sua recuperação; um instantâneo da máquina virtual não substitui, neste contexto, uma cópia de segurança consistente da base de dados.

Uma máquina virtual de teste simplificada é útil para verificar a instalação, o registo e a acessibilidade da fonte do patch. No entanto, não fornece informações fiáveis sobre controladores próximos do ambiente de produção, módulos específicos ou padrões de carga. A estrutura «Upstream Linux Livepatch» classifica tecnicamente as ativações através de uma transição de consistência; no entanto, não é possível deduzir daí nenhum mecanismo específico do KernelCare. Independentemente disso, os perfis de trabalho reais e os componentes operacionais adicionais devem ser incluídos num teste de preparação representativo.

Não defina a duração da observação de forma genérica. No caso de um serviço com importações noturnas, o teste deve incluir, pelo menos, uma dessas importações; no caso de um cluster de alta disponibilidade, pode ser relevante realizar uma transição controlada em caso de falha. Defina antecipadamente os valores-alvo e os critérios de interrupção. Caso surjam novas mensagens do kernel, erros repetidos dos agentes ou desvios técnicos, a aprovação não será concedida e os resultados serão analisados antes de se proceder a uma nova ronda de testes.

Avaliar corretamente o estado do patch com o kcarectl

Registe o estado antes e depois de um processo de aplicação de patches aprovado utilizando os mesmos comandos. Desta forma, é possível distinguir qual o kernel que foi inicializado, qual a versão do agente que o anfitrião utiliza e se um conjunto de patches está efetivamente ativo. Os resultados devem ser incluídos no registo de alterações ou no registo de testes, acompanhados do carimbo de data/hora, do identificador do anfitrião e da versão da aplicação testada. Uma simples mensagem de sucesso do instalador não constitui prova suficiente para este efeito.

As consultas seguintes são de leitura e adequam-se à análise do estado atual. Execute-as no ambiente de destino com as autorizações previstas para esse ambiente. Só um processo de atualização planeado posteriormente é que altera o estado das correções; a execução destes comandos constitui, portanto, uma base para comparação e monitorização, e não o próprio processo de aplicação de correções.

uname -r
kcarectl --version
kcarectl --info
kcarectl --patch-info
kcarectl --status
kcarectl --uname

É particularmente importante a distinção entre o sistema inicializado e versão efetiva do kernel. Um scanner de vulnerabilidades que apenas uname -r Se for avaliado, pode dar uma impressão desatualizada, apesar de um Livepatch disponibilizar a correção em questão. Por isso, compare o inventário e as regras de conformidade com os dados disponíveis da TuxCare, tais como a versão efetiva e a lista local de CVE em /proc/kcare/cvelist.

Para alertas, é adequado kcarectl --status melhor do que uma simples pesquisa de texto nas saídas da consola, porque os códigos de saída podem ser analisados automaticamente. Um código 2, por exemplo, requer uma avaliação para determinar se um novo conjunto de patches deve ser implementado dentro do prazo previsto; o código 3 refere-se a um caso de compatibilidade ou de inventário. Nenhum destes códigos substitui a análise dos registos do kernel, das métricas dos serviços e das transações técnicas.

Escalar de forma controlada as fases de QA, Canary e produção

Uma implementação controlada começa num ambiente de controlo de qualidade (QA) dedicado, passa depois por um pequeno grupo «Canary» representativo e só é alargada quando se obtêm resultados documentados como estáveis. Cada fase passa pelos mesmos testes de estado e de aplicação. O período de observação depende do ciclo de carga: nos sistemas em lote, conta-se um ciclo completo de processamento; nos clusters, podem incluir-se a replicação e uma transição controlada em caso de falha.

Durante a observação, deve verificar as taxas de erro, as latências, as mensagens do kernel e dos agentes, bem como, se for o caso, o quórum e a replicação. Só depois de cumpridos os critérios de aprovação é que se passa ao grupo seguinte. O artigo interno explica outros aspetos básicos relativos à implementação em ambiente de produção KernelCare Enterprise: Aplicação de correções em tempo real sem janelas de manutenção.

Feeds atrasados e UPDATE_DELAY resolvem tarefas semelhantes a diferentes níveis. Um feed é transmitido através de PREFIX escolhido como fonte de patch com atraso fixo. UPDATE_DELAY Por outro lado, retém os conjuntos de patches através da configuração do cliente até uma idade mínima especificada. STICKY_PATCHSET limita o cliente a uma determinada versão máxima do conjunto de patches.

Um manual kcarectl --update carrega o conjunto de patches mais recente e aplica-o ao kernel em execução. Utilize este comando apenas em sistemas de teste autorizados ou durante um período de manutenção definido. Antes de o fazer, guarde os valores de referência e, em seguida, realize imediatamente as verificações técnicas e funcionais.

O ePortal permite gerir centralmente conjuntos de patches e a sua distribuição. Segundo a TuxCare, quando as atualizações automáticas estão ativadas, os clientes verificam a disponibilidade de conjuntos de correções a cada quatro horas. No entanto, isso não garante um tempo de execução: a acessibilidade, o registo, as políticas e a compatibilidade do kernel têm de ser monitorizados em cada onda.

Registe, por cada ciclo, o estado do patch, os anfitriões selecionados, a janela de observação, os resultados dos testes e o responsável pela aprovação. Em caso de anomalias, a implementação é suspensa. Estas Lançamento Canary limita o alcance de efeitos inesperados, mas não substitui nem o teste de compatibilidade nem o ciclo de reinicialização planeado.

Testar o Secure Boot e casos especiais críticos

Servidor com Arranque seguro devem ser incluídos num grupo de teste específico. O agente necessita de uma cadeia de confiança funcional para os seus módulos do kernel; uma instalação bem-sucedida ainda não comprova a existência dessa cadeia. A TuxCare especifica a versão mínima do agente 3.0-2 para o processo automatizado de Secure Boot em sistemas RPM suportados. Esta indicação não se aplica como versão mínima geral para o KernelCare nem para o registo manual do MOK.

Para o método automatizado, é necessário que estejam disponíveis, entre outros, o arranque EFI, o shim e o Secure Boot ativado. Segundo a TuxCare, este procedimento não está previsto para o Debian e o Ubuntu. Por isso, registe a distribuição, o modo de arranque e a versão do agente antes do teste e não trate uma plataforma diferente como uma mera variante de configuração, mas sim como um caminho separado, a ser avaliado manualmente.

O teste só termina após um reinício programado. Em seguida, verifica com a ferramenta descrita pela TuxCare mokutil ou com base em mensagens adequadas do kernel, para verificar se o certificado está efetivamente disponível na cadeia de confiança. Só depois disso é que se procede, neste host, a uma obtenção controlada do Livepatch, com as mesmas verificações técnicas e especializadas que nas restantes fases do processo de controlo de qualidade.

Também os sistemas com controladores proprietários, módulos de armazenamento ou de rede, programas eBPF, software de segurança e agentes de monitorização necessitam de um conjunto de testes representativo próprio. Esta não é uma afirmação geral sobre incompatibilidade. Em termos técnicos, o framework «Upstream Linux Livepatch» descreve transições de consistência para as tarefas em causa; no entanto, isto não comprova que o KernelCare utilize o mesmo mecanismo em todas as plataformas suportadas.

Por isso, simule as combinações que realmente ocorrem em produção: por exemplo, armazenamento multipath sob carga, ligações de rede encriptadas, agentes de segurança e a função de failover de um nó do cluster. Documente os módulos carregados, as mensagens do kernel, bem como o estado das aplicações e do cluster antes e depois da aplicação do patch. Uma máquina virtual de teste simplificada, sem estes componentes, pode confirmar a instalação do agente, mas não fornece informações fiáveis sobre esta classe de sistemas.

Monitorização, análise de erros e escalamento seguro

Monitorize o Live Patching em dois níveis: o ficheiro legível por máquina Estado da atualização mostra o estado do agente, enquanto os registos do kernel, as taxas de erro, as latências e o estado do cluster refletem o funcionamento da aplicação. O facto de o sistema estar atualizado com os patches mais recentes não exclui a possibilidade de, simultaneamente, existir uma falha na aplicação ou um desvio técnico. Por isso, os sistemas de alarme e de autorização devem integrar ambos os níveis e investigar separadamente a causa de um desvio.

Para a triagem automatizada, fornece kcarectl --status Códigos de saída definidos: 0 corresponde ao nível de patch mais recente, 1 a ausência de patches aplicados, 2 a patches disponíveis, mas ainda não aplicados, e 3 a um kernel não suportado. O código 3 requer, em primeiro lugar, uma verificação de compatibilidade; o código 2 não constitui um erro de aplicação, mas deve ser avaliado à luz da política de implementação e atualização prevista.

Em caso de anomalias, recolha primeiro dados que possam ser correlacionados temporalmente: informações de estado e de patches, mensagens dos agentes, registo do kernel, momento da consulta, cargas de trabalho afetadas e alterações em módulos ou na infraestrutura. No caso dos nós de cluster, isso inclui a adesão ao cluster, o estado de replicação e os eventos de failover. Estes dados permitem distinguir um estado de patch de uma falha de aplicação ou de rede ocorrida simultaneamente e tornam um caso de assistência técnica mais compreensível.

A TuxCare documenta kcarectl --force como opção, juntamente com uma atualização que obriga à aplicação de um patch, caso algumas threads não possam ser congeladas. A documentação do Linux upstream alerta, no que diz respeito ao seu próprio mecanismo de força, para possíveis danos, exige, em seguida, um reinício planeado e desaconselha a aplicação de mais patches em tempo real. No entanto, não comprova que kcarectl --force utiliza internamente a mesma semântica. Por isso, são determinantes as instruções de suporte da TuxCare específicas do produto e o diagnóstico do host em questão; esta opção não é adequada como medida regular de implementação ou de resolução de problemas.

Planear a estratégia de reinício e a aprovação documentada

A aplicação de correções em tempo real reduz o tempo necessário para corrigir vulnerabilidades do kernel suportadas, mas não altera o pacote do kernel instalado. Novos pacotes do kernel, suporte a hardware, alterações a controladores ou firmware e melhorias funcionais do kernel continuam a exigir a gestão regular de pacotes e reinícios programados.

Por isso, defina um ritmo de reinicialização para cada classe de plataforma. O KernelCare apenas disponibiliza patches para um kernel específico enquanto o seu fabricante continuar a fornecer atualizações de segurança para a série em questão. Além disso, uma janela de manutenção restabelece a conformidade entre o kernel inicializado, os controladores carregados e o estado nominal documentado.

A TuxCare documenta kcarectl --unload para descarregar os patches do KernelCare. Daí não decorre qualquer garantia geral de uma recuperação completa. A documentação do upstream indica, no que diz respeito ao Atomic Replace e aos Livepatches cumulativos, que as alterações de estado podem dificultar o retorno ao estado anterior; no entanto, não descreve automaticamente a implementação concreta de cada versão do KernelCare.

Por isso, antes de efetuar uma descarga, verifique a documentação relativa à versão do agente instalado e, se necessário, coordene as medidas de resolução de avarias com a TuxCare. O robusto Ponto de retorno fica um kernel de arranque definido e testado, com um reinício programado e, se for caso disso, uma verificação de consistência ou uma recuperação da aplicação.

A aprovação de uma onda de implementação documenta o kernel suportado, o estado dos patches, os testes de aplicações realizados, os ciclos de carga relevantes, os registos, os responsáveis e os critérios de interrupção. Não constitui um compromisso geral relativamente a conjuntos de patches futuros. Alterações no kernel, nos módulos ou na aplicação podem exigir a realização de novos testes de controlo de qualidade (QA) e de teste «Canary».

• Documentar o kernel suportado, a fonte do patch e a versão do patch aplicada.
• Comprovar o funcionamento das aplicações, o ciclo de carga, os registos do kernel e o estado do cluster, sem que se verifiquem desvios inexplicáveis.
• Definir a fase de implementação, os responsáveis, os canais de alarme e os critérios de interrupção.
• Agendar a próxima atualização do kernel com janela de manutenção, kernel de arranque e verificação de reinício.

Assim, a decisão operacional é clara: uma atualização em tempo real bem-sucedida permite a continuação controlada da respetiva onda. Por outro lado, sinais técnicos ou especializados não esclarecidos levam à suspensão, à análise ou a um reinício planeado. O planeamento do reinício faz parte do conceito de segurança e recuperação, não é uma admissão de que o «Livepatch» falhou.