Vantagens da segurança nativa do Kubernetes

Há duas abordagens principais para a segurança de containers: centrada no container e nativa do Kubernetes. 

Na primeira abordagem, as plataformas operam protegendo imagens de container e o runtime do container. Essas ferramentas oferecem controles no nível do container, por exemplo, usando técnicas como proxies em linha ou shims para controlar as comunicações entre containers.

A segurança nativa do Kubernetes opera na camada do Kubernetes. O contexto é obtido do Kubernetes, e as políticas são enviadas a ele para que sejam aplicadas.

A segurança nativa do Kubernetes conta com integrações avançadas com o Kubernetes para obter o contexto e aproveitar os controles nativos do Kubernetes. Essa arquitetura aumenta a segurança de duas maneiras: fornecendo um contexto claro e detectando ameaças específicas.

Isso baseia-se no princípio de que a implementação da segurança é mais eficaz quando está alinhada ao sistema que gerencia as aplicações em container. 

Para uma plataforma ser considerada nativa do Kubernetes, ela deve:

• Ter integração direta ao servidor da Kubernetes API para obter visibilidade das cargas de trabalho e infraestrutura do Kubernetes
• Avaliar as vulnerabilidades do software do Kubernetes
• Basear as funcionalidades de segurança (como o gerenciamento de políticas) nos recursos do modelo de objetos do Kubernetes, incluindo implantações, namespaces, serviços, pods e mais
• Analisar dados declarativos de configurações e artefatos específicos do Kubernetes, como manifestos de carga de trabalho
• Usar funcionalidades de segurança integradas do Kubernetes para a imposição sempre que possível, aumentando a automação, a escalabilidade e a confiabilidade
• Ser implantada e executada como aplicação do Kubernetes, incluindo integração e suporte a ferramentas comuns das cadeias de ferramentas nativas em nuvem

A segurança nativa do Kubernetes oferece visibilidade à configuração dos containers e à implantação do Kubernetes. 

Também é importante entender se as cargas de trabalho estão isoladas e de que maneira. Por padrão, o Kubernetes permite que todas as implantações se comuniquem entre si, seja dentro ou fora dos seus namespaces. A grande visibilidade das configurações da política de rede destaca quais cargas de trabalho não estão isoladas. Isso é feito de preferência em um formato visual, em vez de por texto em um arquivo YAML.

Para entender sua postura geral de segurança, certifique-se de que as configurações do Kubernetes (permissões de função, acesso a segredos, tráfego de rede permitido) e as definições dos componentes do control plane estejam bloqueados, sigam as práticas recomendadas e tenham o menor privilégio necessário para executar as aplicações.

Descubra como proteger os containers, da criação e implantação à execução

Assim como ocorre com outros recursos de computação, muitas organizações optam por executar o Kubernetes na nuvem. Isso pode ser feito de várias maneiras:

• Kubernetes autogerenciado
• Distribuição comercial do Kubernetes
• Serviço do Kubernetes gerenciado

Independentemente do modelo escolhido, você e o provedor de nuvem compartilham a responsabilidade de proteger a implantação. Isso é especialmente válido para serviços Kubernetes gerenciados, mas pode ser confuso saber qual é a responsabilidade exata de cada parte.

No caso de serviços Kubernetes gerenciados, o provedor de nuvem gerencia o control plane do Kubernetes, incluindo os componentes do Kubernetes que controlam o cluster e os dados sobre o estado e a configuração do cluster.

Normalmente, os serviços incluem configurar o control plane, habilitar a redundância dos nós, em geral executando-os em diferentes regiões para impedir interrupções caso a infraestrutura do provedor de nuvem fique inativa.

Normalmente, os provedores de nuvem:

• Mantêm o Kubernetes atualizado
• Aplicam patch ao control plane
• Podem aplicar patch ao sistema operacional do nó, dependendo da sua escolha de sistema
• Oferecem imagens de sistema operacional otimizadas para container para os nós
• Podem incluir verificadores de vulnerabilidades, mas você deve criar a política, por exemplo, usar o controlador de admissão para permitir ou negar com base nos resultados da verificação

É sempre de responsabilidade do cliente proteger a carga de trabalho do Kubernetes, incluindo estes aspectos de segurança:

• Imagens de container: origem, 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: gerenciamento de segredos, rótulos e anotações
• Segmentação de rede: políticas de rede no cluster
• Runtime: detecção de ameaças e resposta a incidentes

O que são o SPIFFE e o SPIRE?

As plataformas de segurança nativa do Kubernetes oferecem diversas vantagens importantes. 

Maior proteção 

A segurança nativa do Kubernetes oferece insights mais detalhados, analisando os dados declarativos para descobrir vulnerabilidades no Kubernetes e nos containers. 

Melhor eficiência operacional 

Usar o mesmo framework para o gerenciamento da infraestrutura e para a segurança reduz a curva de aprendizado do Kubernetes, e o contexto do Kubernetes permite a detecção de ameaças mais rápida e prioriza as avaliações de risco.

Risco operacional reduzido 

O uso dos controles nativos garante que a segurança siga o ritmo e a escalabilidade do Kubernetes. E, com as políticas incorporadas no Kubernetes, não há conflito entre os controles externos e o orquestrador.

A segurança nativa do Kubernetes ajuda a reduzir os problemas operacionais oriundos de configurações inconsistentes, falta de coordenação e erros do usuário.

Considerando a curva de aprendizado da maioria dos usuários do Kubernetes, é fácil cometer erros. Por exemplo, conceder privilégios elevados usando os controles de acesso baseado em função (RBAC) do Kubernetes, dando a um usuário ou conta de serviço permissões administrativas completas para o cluster. Outro exemplo é expor segredos do Kubernetes indevidamente, permitindo que as implantações acessem segredos mesmo quando não é necessário.

As plataformas com segurança nativa do Kubernetes identificam as configurações incorretas de maneira automática e contínua.

Os controles de segurança integrados ao Kubernetes também removem o risco de ter software de controle separados que, em caso de falha, não abrem, permitindo todo o tráfego sem segurança, ou não são encerrados, impedindo todo o tráfego da aplicação.

Quando o orquestrador do Kubernetes impõe controles de política, a segurança imediatamente conta com a mesma escalabilidade que o Kubernetes e com todas as opções de imposição de política. 

Por outro lado, usar proxies em linha ou shims para a imposição gera pontos únicos de falha, desafios de escalabilidade e limitações no desempenho.

Por exemplo, com o Kubernetes, você pode aplicar políticas de rede para segmentar o tráfego, usar controladores de admissão para aplicar políticas a solicitações para o servidor da Kubernetes API, usar segredos para armazenar credenciais confidenciais e aplicar controle de acesso baseado em função (RBAC) para autorizar determinados recursos para usuários e contas de serviço específicos.

Você também pode usar outras ferramentas padronizadas, como plug-ins de rede, para adotar o Container Network Interface (CNI) junto à plataforma com segurança nativa do Kubernetes, e fazer alterações conforme necessário.

Com uma plataforma única para provisionar e operar os serviços de infraestrutura, o Kubernetes simplifica e centraliza os fluxos de trabalho das equipes de desenvolvimento de aplicações e de operações. 

Essa abordagem consolidada, em que todos usam uma single source of truth e a mesma infraestrutura, pode ser aplicada à segurança e ao implantar uma plataforma com segurança nativa do Kubernetes. 

Isso economiza tempo e dinheiro, diminui a curva de aprendizado e acelera a análise e a correção.

Quando as equipes de DevOps e segurança usam ferramentas diferentes, é fácil surgir conflitos nas configurações. 

O setor de DevOps pode especificar uma política de rede do Kubernetes que permite o tráfego entre dois nós, e a equipe de segurança pode aplicar um controle usando um software separado que bloqueia o tráfego.

As configurações mostrariam que o tráfego da aplicação deveria estar fluindo. A equipe de DevOps não teria ideia de por que a aplicação apresenta falha, já que não vê os controles exercidos pelo software de controle separado.

Quando as equipes de DevOps e segurança usam as mesmas estruturas para criar e disponibilizar apps em container e protegê-las, é preciso conhecer menos interfaces, ferramentas e modelos. 

O DevOps usa arquivos de manifesto do Kubernetes para definir os recursos de que uma aplicação precisa. Usar esses mesmos ativos para coletar o contexto de segurança e aplicar políticas reduz a complexidade e aprimora o resultado obtido. 

Para a segurança nativa, o Kubernetes é visto como a source of truth das políticas de segurança com a qual todos trabalham, incluindo as equipes de segurança, operações, DevOps e engenharia de confiabilidade de sites (SRE). 

Além disso, os problemas de segurança mapeiam os objetos e recursos do Kubernetes que as equipes usam no dia a dia, simplificando ainda mais as operações.

Evite o risco operacional de implementar software de segurança separados usando a imposição nativa do Kubernetes em suas políticas de segurança.

Os containers dificultam a segurança das aplicações nativas em nuvem de diversas maneiras, incluindo o fato de que os incidentes podem se espalhar, os containers produzem grandes volumes de dados para processamento e são efêmeros, tornando obsoleta a resposta a incidentes tradicional.

A segurança nativa do Kubernetes permite que você detecte ameaças aos seus containers com mais precisão e reduz o tempo e esforço necessários para aplicar uma segurança eficaz ao seu ambiente.

Ao obter o contexto do Kubernetes, o comportamento esperado é claro. Como resultado, a segurança nativa do Kubernetes identifica anomalias com maior precisão, oferecendo mais confiança para aplicar as opções de imposição, como excluir um pod.

Além disso, usar o contexto do Kubernetes reduz os falsos positivos e a fadiga de alerta.

A segurança nativa do Kubernetes também permite adotar uma abordagem baseada em riscos para as tarefas de segurança. 

É provável que suas implantações violem políticas, mas por onde você deve começar? Mais uma vez, o contexto do Kubernetes ajuda. 

Ao reunir diferentes aspectos de metadados do Kubernetes, incluindo se um cluster está em desenvolvimento ou produção, se tem exposição à internet, quão essencial é a aplicação e se há processos suspeitos em execução, sua equipe sabe o que requer atenção no momento. 

Detectar vulnerabilidades específicas do Kubernetes, especialmente as que colocam o servidor da Kubernetes API em risco, é essencial para impedir, identificar e corrigi-las. As ferramentas de segurança nativas do Kubernetes identificam as vulnerabilidades automaticamente.

A integração ao servidor da Kubernetes API oferece monitoramento seguro para os containers em execução nos clusters do Kubernetes e para os recursos do Kubernetes, como implantações, conjuntos de daemon, serviços, pods e mais.

A natureza aberta das implantações do Kubernetes representa outro vetor de ameaças. Como o Kubernetes é, antes de tudo, uma plataforma para operações de infraestrutura, a facilidade de uso é prioridade. Com isso, nem todos os componentes são seguros por padrão. 

Para proteger suas implantações do Kubernetes, outro elemento essencial é aplicar políticas de rede do Kubernetes para limitar as comunicações. As plataformas com segurança nativa do Kubernetes podem automaticamente definir uma linha de base para as atividades da rede, identificar as vias de comunicação necessárias para atender a aplicação e criar o arquivo YAML corretor para reduzir o escopo de acesso à rede.

E, com as configurações de segurança automáticas, você poderá identificar e interromper ameaças continuamente na camada do Kubernetes.

A segurança nativa do Kubernetes também oferece alta portabilidade e reutilização. Seguindo uma abordagem única e padronizada, as políticas são aplicadas consistentemente em todos os ambientes onde o Kubernetes é executado. 

Com a segurança nativa do Kubernetes, os usuários podem especificar uma configuração (por exemplo, uma política de rede) a ser aplicada a todos os pods em uma implantação, em vez de definir controles no nível do sistema em cada host de um cluster. 

Ao vincular políticas a sistemas de CI/CD e ao framework do controlador de admissão do Kubernetes, as organizações conseguem aplicar políticas de controle no estágio inicial do ciclo de vida de desenvolvimento do software, prevenindo exposições no runtime. 

E usar as estruturas do Kubernetes, como o controlador de admissão, mantém a segurança altamente vinculada às cadeias de ferramentas do Kubernetes.

Teste o Kubernetes empresarial