Como administrar a segurança do Kubernetes

Para administrar a segurança do Kubernetes, é preciso corrigir vulnerabilidades de segurança conhecidas durante a fase de criação, redefinir configurações incorretas durante a fase de criação/desenvolvimento e responder a ameaças no ambiente de execução. Essas foram respostas coletadas no último relatório "O estado da segurança do Kubernetes e de containers", que constatou que 24% dos problemas sérios de segurança de containers eram vulnerabilidades passíveis de remediação, quase 70% eram erros de configuração e 27% eram incidentes de segurança no ambiente de execução.

Os containers estão em toda parte

O Kubernetes é uma plataforma de orquestração de containers open source usada para gerenciar centenas (às vezes, milhares) de containers Linux® agrupados em clusters. Ele depende muito das interfaces de programação de aplicações (APIs) que conectam microsserviços em containers. Essa natureza distribuída dificulta investigar rapidamente quais containers podem ter vulnerabilidades, estar mal configurados ou representar os maiores riscos para sua organização.

A solução é desenvolver uma visão abrangente das implantações de containers que capturem eventos críticos no nível do sistema em cada container.

Imagens e registros podem ser utilizados incorretamente

As imagens dos containers (também conhecidas como imagens base) são templates imutáveis usados para criar novos containers. As imagens de container recém-copiadas podem então ser modificadas para servir a outros propósitos.

A solução é definir políticas que determinam como as imagens são criadas e armazenadas nos registros de imagem. As imagens base precisam ser testadas, aprovadas e escaneadas regularmente. Além disso, apenas as imagens de registros permitidos devem ser usadas para lançar containers em um ambiente do Kubernetes.

Comunicação habilitada de containers

Os containers e pods precisam interagir entre si nas implantações, bem como com outros endpoints internos e externos para funcionar adequadamente. Se um container for violado, a capacidade de um hacker se mover dentro do ambiente estará diretamente relacionada a quanto esse container consegue se comunicar com outros containers e pods. Em um ambiente de containers em expansão, implantar segmentação de rede pode ser muito difícil, dada a complexidade de configurar essas políticas manualmente.

A solução é rastrear o tráfego que se desloca entre os namespaces, implantações e pods e determinar quanto desse tráfego é realmente permitido.

Políticas padrão de rede de containers

Por padrão, as implantações do Kubernetes não aplicam uma política de rede a um pod, que é a menor unidade de uma aplicação do Kubernetes. Essas políticas de rede se comportam como regras de firewall. Elas controlam a forma como os pods se comunicam. Sem políticas de rede, qualquer pod consegue interagir com outro pod. 

A solução é definir políticas de rede que limitem a comunicação de pods apenas a ativos definidos e criar segredos em volumes somente leitura dentro de containers, em vez de enviá-los como variáveis de ambiente.

Conformidade para containers e Kubernetes

Os ambientes nativos em nuvem viabilizados pelo Kubernetes devem (como todos os outros ambientes de TI) obedecer às práticas recomendadas de segurança, padrões do setor e de referência e políticas organizacionais internas e provar essa conformidade. Às vezes, isso significa adaptar estratégias de conformidade para que os ambientes do Kubernetes atendam aos controles originalmente escritos para arquiteturas de aplicação.

A solução é monitorar aderência à conformidade e automatizar auditorias.

Ambiente de execução

O Kubernetes é uma infraestrutura imutável. Não é possível aplicar patchs durante a execução dos containers. Os containers em execução devem ser destruídos e recriados. Containers comprometidos podem executar processos maliciosos, como mineração criptográfica e varredura de portas.

A solução é destruir qualquer container corrompido ou em execução, reconstruir uma imagem de container íntegra e, em seguida, relançá-la.

A segurança do Kubernetes começa na fase de criação, gerando imagens base fortes e adotando processos de varredura de vulnerabilidade.

• Use imagens base mínimas: evite usar imagens com gerenciadores de pacotes de sistema operacional ou shells, que poderiam conter vulnerabilidades desconhecidas, ou remova o gerenciador de pacotes depois.

• Não adicione componentes desnecessários: como regra geral, ferramentas comuns podem se tornar riscos de segurança quando incluídas em imagens.

• Use apenas imagens atualizadas: atualize as versões dos componentes.

• Use um verificador de imagens: identifique as vulnerabilidades em imagens, detalhadas por camadas.

• Integre a segurança em pipelines de CI/CD: automatize uma faceta de segurança repetível que interromperá criações de integração contínua e emitirá alertas quanto a vulnerabilidades graves e reparáveis.

• Rotule as vulnerabilidades permanentes: adicione imediatamente a uma lista de permissões vulnerabilidades conhecidas que não possam ou não precisem ser corrigidas ou não sejam críticas. 

• Implemente defesa em profundidade: padronize verificações de políticas e fluxos de trabalho de remediação para detectar e atualizar imagens vulneráveis.

Configure a segurança da infraestrutura do Kubernetes antes que as cargas de trabalho sejam implantadas. Primeiro, é preciso saber o máximo possível sobre o processo de implantação: o que está sendo implantado (imagem, componentes, pods), onde (clusters, namespaces e nós) e como os elementos estão sendo implantados (privilégios, políticas de comunicação, garantias aplicadas), o que ele pode acessar (segredos, volumes) e as normas de conformidade.

• Use namespaces: a separação das cargas de trabalho em namespaces pode ajudar a conter ataques e limitar o impacto de erros ou ações destrutivas por parte de usuários autorizados.

• Use políticas de rede: o Kubernetes permite que cada pod interaja com todos os outros pods por padrão, mas as políticas de segmentação de rede podem substituir essa definição.

• Restrinja as permissões a segredos: somente crie segredos que sejam necessários para as implantações.

• Avalie os privilégios de containers: somente habilite as capacidades, funções e privilégios que permitam ao container desempenhar sua função. 

• Avalie a origem da imagem: use imagens de registros conhecidos.

• Implantações de verificação: aplique políticas com base nos resultados das verificações. 

• Use rótulos e anotações: rotule ou anote as implantações com os dados de contato da equipe responsável por uma aplicação em container para agilizar a triagem.

• Viabilize o controle de acesso baseado em função (RBAC): o RBAC controla a autorização de usuário e conta de serviço para acessar o servidor da API do Kubernetes de um cluster.

Abordagens proativas de segurança durante a criação e implantação podem reduzir a probabilidade de incidentes de segurança no ambiente de execução, mas identificar e responder a ameaças requer um monitoramento contínuo da atividade do processo e das comunicações de rede.

• Use informações contextuais: use as informações de tempo de criação e de implantação no Kubernetes para avaliar a atividade observada em relação à esperada durante a execução a fim de detectar atividades suspeitas.

• Verifique as implantações em execução: monitore as implantações em execução para as vulnerabilidades recém-descobertas em imagens de containers.

• Use controles integrados: configure o contexto de segurança para os pods a fim de limitar as capacidades deles.

• Monitore o tráfego da rede: observe e compare o tráfego de rede em tempo real àquele permitido pelas políticas de rede do Kubernetes para identificar comunicações inesperadas.

• Use listas de permissão: identifique os processos realizados durante o curso normal da execução da aplicação para criar uma lista de permissões.

• Compare a atividade de execução em pods implantados de forma semelhante: as réplicas com desvios significativos requerem investigação.

• Reduza os pods suspeitos a zero: use os controles nativos do Kubernetes para conter brechas, instruindo automaticamente o Kubernetes a reduzir a zero os pods suspeitos ou destruir e reiniciar instâncias.

A segurança vai além das imagens e cargas de trabalho e inclui toda a infraestrutura do Kubernetes: clusters, nós, plataforma do container e até nuvens.

• Aplique as atualizações do Kubernetes: atualizar as distribuições do Kubernetes aplicará patches de segurança e instalará novas ferramentas de segurança.

• Configure o servidor da API do Kubernetes: desative o acesso não autenticado/anônimo e use a criptografia de TLS para conexões entre kubelets e o servidor da API.

• Proteja o etcd: o etcd é um armazenamento de chave/valor usado pelo Kubernetes para acesso a dados. Proteja o kubelet. Desabilite o acesso anônimo ao kubelet iniciando o kubelet com o sinalizador --anonymous-auth=false e use o controlador de admissão NodeRestriction para limitar o que o kubelet pode acessar.

Segurança em nuvem

Independentemente de que tipo de nuvem (pública, privada, híbrida ou multicloud) hospeda os containers ou opera o Kubernetes, o usuário da nuvem (não o provedor de nuvem) é sempre responsável por proteger a carga de trabalho do Kubernetes, incluindo:

• Imagens de container: origens, conteúdo e vulnerabilidades

• Implantações: serviços de rede, armazenamento e privilégios

• Gerenciamento de configurações: funções, grupos, vinculações de funções e contas de serviço

• Aplicação: gestão de segredos, rótulos e anotações

• Segmentação de rede: políticas de rede no cluster do Kubernetes

• Ambiente de execução: detecção de ameaças e resposta a incidentes

Usar containers e o Kubernetes não muda seus objetivos de segurança, que é reduzir as vulnerabilidades.

• Integre a segurança o quanto antes no ciclo de vida do container: a segurança deve permitir aos desenvolvedores e às equipes de DevOps criar e implantar com confiança aplicações prontas para produção.

• Use os controles de segurança nativos do Kubernetes: os controles nativos impedem que os controles de segurança entrem em conflito com o orquestrador. 

• Deixe o Kubernetes priorizar a correção.