0 
0 Para colher todos os benefícios do Kubernetes e das arquiteturas de aplicativos baseadas em microsserviços, as organizações devem transformar a forma como implementam a segurança. Essa transformação geralmente revela lacunas e silos nas equipes e processos de desenvolvimento e operações. Caso em questão: a lacuna entre os desenvolvedores e a equipe de segurança de rede.
Com base nos resultados da pesquisa de mais de 300 profissionais de DevOps, engenharia e segurança, o ” Relatório de segurança do estado do Kubernetes de 2022 ” (PDF) mostra que a segurança é uma das maiores preocupações sobre a adoção de contêiner e Kubernetes, com os entrevistados observando que problemas de segurança causaram atrasos na implantação de aplicativos em produção.
Quase todos os entrevistados da pesquisa, 93%, disseram ter sofrido pelo menos um incidente de segurança em seu ambiente Kubernetes nos últimos 12 meses, com 31% relatando uma perda de receita ou cliente devido a um incidente de segurança.
A maioria desses incidentes se deve a erro humano, com mais da metade (53%) dos entrevistados dizendo que detectaram uma configuração incorreta no Kubernetes nos últimos 12 meses. Existem muitas práticas recomendadas para evitar configurações incorretas do Kubernetes , mas a realidade é que o Kubernetes é grande e tem uma certa complexidade. As lacunas entre funções, responsabilidades e conjuntos de habilidades — comuns, especialmente para empresas que refatoram aplicativos legados — deixam a porta aberta para vulnerabilidades.
Por exemplo, os desenvolvedores e a equipe de segurança de rede podem estar trabalhando, se não com propósitos cruzados, então em silos. Historicamente, os desenvolvedores não são os únicos a implementar a segurança da rede – eles apenas lançam aplicativos por cima do muro e confiam na equipe de segurança para cuidar da configuração da rede.
Em um mundo Kubernetes, no entanto, o ônus da segurança está no DevOps – ou, pelo menos, essa é a percepção. E faz sentido que as pessoas pensem assim: toda a noção de “shift left” é que a segurança é abordada o mais cedo possível no ciclo de desenvolvimento.
De fato, de acordo com a pesquisa, o DevOps é o papel mais citado como responsável por proteger contêineres e Kubernetes: 15% dos entrevistados consideram os desenvolvedores como os principais proprietários da segurança do Kubernetes, com apenas 18% identificando as equipes de segurança como as mais responsáveis.
Mas mudar para a esquerda não é suficiente, especialmente quando explorações de dia zero são uma ocorrência relativamente comum. Somente uma colaboração estreita entre as equipes de desenvolvimento, operações de TI e rede e outras equipes de segurança pode proteger razoavelmente os aplicativos contra invasores, especialmente aqueles que procuram pontos de entrada a partir dos quais possam se mover o mais longe possível na cadeia de eliminação.
As organizações provavelmente entendem tudo isso em teoria, mas, na realidade, há um pouco de terra de ninguém quando se trata de segurança de rede e Kubernetes: quem gerencia, entende e analisa a configuração de rede no cluster? Quem está identificando e corrigindo configurações incorretas ?
A lacuna entre os desenvolvedores e a equipe de segurança de rede pode aumentar à medida que as empresas avançam em direção a um modelo de confiança zero. Com zero confiança, é claro, nada é confiável. Mas as empresas não podem funcionar dessa maneira. Em algum momento, alguém precisa fornecer permissões para aplicativos e serviços específicos para se comunicarem.
Enigma NetSec do Kubernetes
Por padrão, as implantações do Kubernetes não aplicam a política de rede aos pods do Kubernetes. Sem políticas de rede, qualquer pod pode se comunicar com qualquer outro pod ou endpoint de rede — o equivalente a um computador sem firewall. Alguém deve entrar e definir as políticas de rede de entrada e saída que limitam a comunicação do pod aos ativos definidos.
No passado, os desenvolvedores indicavam quais caminhos de comunicação precisavam ser disponibilizados, e os administradores de rede disponibilizavam esses caminhos por meio de configurações tradicionais de firewall.
O problema é que os engenheiros de segurança de rede não falam a linguagem do Kubernetes. Em um mundo Kube, tudo o que você faz em segurança de rede precisa ser escrito em YAML, uma linguagem de serialização de dados, mas os engenheiros de segurança de rede pensam em termos de endereços IP e tabelas IP. A equipe da NetSec realmente não entende a linguagem em que as políticas são escritas e as ferramentas não são familiares para eles.
Uma ferramenta que preenche a segurança da rede e outras lacunas é o StackRox, um projeto de código aberto nativo da nuvem que fornece às organizações ferramentas, treinamento e uma comunidade de experiências compartilhadas com a criação de segurança do Kubernetes implementada como políticas de segurança que podem ser usadas para monitorar clusters do Kubernetes e as cargas de trabalho em execução nesses clusters.
Quando se trata de configuração de rede, o StackRox permite que desenvolvedores e equipes de segurança visualizem o tráfego de rede existente versus o permitido. Usando controles nativos do Kubernetes, as equipes NetSec podem aplicar políticas de rede com mais eficiência e segmentação mais rígida. O StackRox adicionou recentemente um novo recurso para ajudar os desenvolvedores a definir políticas de rede antes de implantar seu aplicativo no Kubernetes. Este foi desenvolvido em parceria com os desenvolvedores do projeto np-guard . O StackRox roxctl agora tem a opção de chamar np-guard para gerar políticas de rede analisando YAMLs de recursos.
Com o projeto StackRox, as organizações podem abordar todos os casos de uso de segurança significativos em todo o ciclo de vida do aplicativo. A propósito do que mencionei acima, o StackRox facilita o processo de aplicação e gerenciamento de isolamento de rede e controles de acesso para aplicativos. Outros casos de uso incluem:
Gerenciamento de vulnerabilidades: o StackRox ajuda as organizações a se protegerem contra vulnerabilidades conhecidas, identificando vulnerabilidades em imagens e executando contêineres.
Gerenciamento de configuração de segurança: as organizações podem aproveitar o StackRox para garantir que o Kubernetes seja configurado de acordo com as melhores práticas de segurança.
Perfil de risco: o StackRox fornece o contexto necessário para priorizar problemas de segurança em todos os clusters do Kubernetes, analisando uma variedade de dados sobre implantações.
Conformidade: as organizações podem aproveitar as políticas de conformidade da StackRox para atender aos requisitos contratuais e regulatórios.
Detecção e resposta: o StackRox fornece recursos de resposta a incidentes, permitindo que as organizações lidem com ameaças ativas em seus ambientes.
Em geral, usar controles nativos do Kubernetes, como StackRox — em outras palavras, usar a mesma infraestrutura e seus controles para desenvolvimento e segurança de aplicativos — permite que as empresas mudem a segurança para a esquerda para um ciclo de 360 graus, enquanto estendem Benefícios de automação e escalabilidade do Kubernetes.
Você pode baixar o StackRox do GitHub aqui . Lá você também encontrará projetos relacionados, como o KubeLinter, uma ferramenta de análise estática que permite que os desenvolvedores verifiquem facilmente os arquivos YAML do Kubernetes e os gráficos do Helm para identificar configurações incorretas e aplicar as melhores práticas de segurança.
FONTE: DARK READING