Entenda os padrões de segurança de Pods do Kubernetes

O Kubernetes “ultrapassou o abismo da adoção” em 2021, depois que 5,6 milhões de desenvolvedores o usaram para orquestrar seus contêineres, segundo a Cloud Native Computing Foundation (CNCF). A pesquisa anual da CNCF registrou que expressivos 96% das organizações estavam considerando adotar o Kubernetes ou já o utilizavam.

No entanto, quanto mais popular o Kubernetes se torna, mais atraente ele fica para hackers e agentes mal-intencionados. À medida que mais desenvolvedores adotam o Kubernetes como plataforma de orquestração de contêineres, também precisam garantir que o utilizam com segurança.

Os padrões de segurança de Pods do Kubernetes são essenciais para manter a segurança do Kubernetes. Eles incluem três políticas cumulativas, que vão de medidas de segurança totalmente rigorosas a outras mais flexíveis. Vamos entender o que são esses padrões, analisar como o controlador de admissão Pod Security os aplica e explorar os casos de uso de cada política.

O que são os padrões de segurança de Pods do Kubernetes?

Os padrões de segurança de Pods do Kubernetes são políticas e diretrizes para manter a segurança e a integridade dos contêineres em clusters Kubernetes. Os padrões definem três perfis com diferentes níveis de restrição para proteger as cargas de trabalho conteinerizadas contra escalações de privilégios conhecidas e seguir as práticas recomendadas atuais de reforço da segurança de Pods:

• Privileged: oferece uma política sem restrições.

• Baseline: oferece proteções com restrições mínimas e impede escalações de privilégios conhecidas.

• Restricted: segue as práticas recomendadas atuais de reforço da segurança de Pods, mas pode limitar a compatibilidade.

Seguir esses padrões ajuda a garantir que os aplicativos conteinerizados atendam aos requisitos de segurança padrão do setor em ambientes Kubernetes. Para isso, o Kubernetes oferece um controlador de admissão Pod Security integrado, que verifica os níveis de isolamento dos Pods de acordo com esses padrões.

Nas versões anteriores do Kubernetes, essa função era desempenhada pelo PodSecurityPolicy. No entanto, o Kubernetes descontinuou esse recurso na versão 1.21 e o removeu por completo na versão 1.25. Em uma publicação no blog, o Kubernetes SIG Security explicou que o controlador de admissão original apresentava “sérios problemas de usabilidade”. O PodSecurityPolicy era confuso, podia conceder acidentalmente permissões mais amplas do que o pretendido e dificultava a verificação das permissões aplicadas em cada situação. Adaptar o PodSecurityPolicy para resolver esses problemas seria um projeto complexo, com risco de comprometer outros recursos. Por isso, ele foi descontinuado e substituído.

Os padrões de segurança de Pods se baseiam nos níveis padrão do PodSecurityPolicy descontinuado, simplificando a migração de sistemas legados que o utilizavam. O controlador de admissão Pod Security integrado aplica esses padrões a clusters ou namespaces.

Como usar o controlador de admissão Pod Security

Depois de ativar o controlador de admissão Pod Security e instalar o webhook, podemos configurar o modo de controle de admissão nos namespaces:

• Enforce: rejeita Pods que violam a política.

• Audit: permite Pods que violam a política, mas adiciona uma anotação de auditoria ao registro do evento.

• Warn: permite Pods que violam a política, mas exibe um aviso aos usuários.

Para configurar o controlador de admissão Pod Security, é preciso identificar dois rótulos:

• Level: Privileged, baseline ou restricted.

• Mode: Enforce, audit ou warn.

Também podemos definir várias verificações de segurança em qualquer namespace. Além disso, podemos especificar a versão e fazer a verificação com base na política fornecida naquela versão secundária específica do Kubernetes.

Por exemplo, para verificar se o namespace “my-namespace” não atende à versão mais recente do nível baseline dos padrões de segurança de Pods, podemos configurar este aviso:

1kubectl label --overwrite ns my-namespace \
2   pod-security.kubernetes.io/warn=baseline \
3   pod-security.kubernetes.io/warn-version=latest

E, se quisermos aplicar o nível de segurança “baseline” e receber notificações nos registros para auditar o nível de segurança e verificar se podemos atender ao padrão Restricted, podemos configurar assim:

1 kubectl label --overwrite ns my-namespace \
2   pod-security.kubernetes.io/enforce=baseline \
3   pod-security.kubernetes.io/enforce-version=latest
4   pod-security.kubernetes.io/audit=restricted \
5   pod-security.kubernetes.io/audit-version=latest

Como usar o perfil de segurança Privileged

Como o perfil de segurança Privileged permite escalações de privilégios conhecidas, devemos usá-lo apenas em casos específicos, nos quais somente usuários confiáveis executem cargas de trabalho de infraestrutura crítica.

O perfil de política Privileged dos padrões de segurança de Pods do Kubernetes oferece permissões irrestritas, necessárias para gerenciar cargas de trabalho sensíveis com flexibilidade para executar tarefas complexas em sistemas críticos. Por exemplo, imagine uma organização que gerencia informações financeiras confidenciais. Nesse caso, usuários privilegiados e confiáveis precisam administrar as cargas de trabalho de sistema e infraestrutura da organização para garantir sua segurança.

Embora esse tipo de acesso às vezes seja necessário, a organização deve concedê-lo apenas aos usuários que realmente precisam dele para exercer suas funções. Ao adotar uma abordagem mais flexível, como o perfil Privileged, é fundamental limitar o escopo das permissões.

Ao usar o perfil de segurança Privileged, também é importante incluir os modos de aviso e auditoria do nível Restricted do controlador de admissão Pod Security. Essa abordagem avisa os usuários sobre o status de cada ação, e todos os registros de eventos incluem anotações de auditoria nas entradas relevantes.

Por fim, é essencial adotar outras práticas recomendadas além das medidas específicas para Pods. Por exemplo, você pode exigir autenticação multifator (MFA) para reduzir os riscos potenciais de conceder permissões amplas.

Como usar o perfil de segurança Baseline

A política Baseline é ideal para operadores de aplicativos e desenvolvedores de aplicativos não críticos que querem proteger seu ambiente sem torná-lo complexo demais. Ela permite gerenciar cargas de trabalho conteinerizadas comuns e, ao mesmo tempo, se proteger contra escalações de privilégios conhecidas.

Por exemplo, imagine que a organização do nosso exemplo execute vários microsserviços não críticos em sua infraestrutura para dar suporte às operações comerciais. O perfil de política Baseline ajuda a proteger essas cargas de trabalho sem exigir muito esforço adicional dos operadores ou desenvolvedores de aplicativos. Ao implementar essa medida de segurança com restrições mínimas, a organização reduz os riscos potenciais e impede que invasores mal-intencionados obtenham privilégios elevados por meio de vulnerabilidades em imagens de contêiner ou de outros vetores de ataque.

Digamos que a organização do exemplo use um serviço de um fornecedor terceirizado que precisa de acesso somente para leitura aos dados armazenados em clusters Kubernetes. A política de segurança de Pods Baseline restringe o acesso privilegiado ao mínimo necessário para o fornecedor e impede tentativas não autorizadas, feitas pelo fornecedor ou por qualquer outra pessoa, de elevar o nível de permissões além dos requisitos do perfil baseline.

O perfil de segurança Baseline também oferece flexibilidade para organizações com cargas de trabalho padrão, incluindo APIs e aplicativos web. Essas organizações não precisam de medidas adicionais de configuração, a menos que testes e análises posteriores indiquem essa necessidade.

É importante lembrar que o perfil de segurança Baseline é intencionalmente genérico, para atender a uma ampla variedade de cargas de trabalho. Por isso, muitas vezes ele inclui restrições pouco úteis para um caso de uso específico. Em vez de usar o perfil Privileged por padrão, já que conceder acesso irrestrito à raiz não é seguro, provavelmente será necessário configurar controles específicos para cada aplicativo, de acordo com o caso de uso.

Como usar o perfil de segurança Restricted

O perfil de política Restricted é o mais seguro dos três, pois aplica as práticas recomendadas atuais de reforço da segurança de Pods.

Digamos que a organização do nosso exemplo implante várias cargas de trabalho conteinerizadas para processar transações financeiras confidenciais. No entanto, ela também tem sistemas legados que executam aplicativos não conteinerizados e não seguem os padrões de segurança modernos. A política de segurança de Pods Restricted garante que todos os contêineres sigam as práticas recomendadas, incluindo o uso de sandbox, a restrição de contas de usuário e o controle de privilégios de rede.

Com o perfil de segurança Restricted, operadores de aplicativos e desenvolvedores de aplicativos críticos para a segurança garantem, entre outras medidas, que:

• Todos os contêineres executados em um Pod sejam somente para leitura.

• Os recursos do Linux sejam limitados ao necessário para o funcionamento do contêiner.

• O nome de host de cada contêiner seja definido explicitamente por meio de uma variável de ambiente.

• O uso de recursos como CPU e memória por processo em um contêiner seja especificado durante a criação dos Pods.

O perfil de política Restricted oferece maior visibilidade sobre as possíveis superfícies de ataque, especialmente para organizações que lidam com cargas de trabalho vulneráveis. A política aplica as práticas recomendadas atuais de reforço da segurança de Pods para ajudar a proteger contra escalações de privilégios e outras atividades mal-intencionadas.

Você pode reforçar a segurança com mecanismos de proteção em camadas, aplicados em diferentes pontos. Isso inclui reduzir recursos desnecessários dos aplicativos, mantendo as funções essenciais, e usar recursos avançados de mitigação de ameaças.

Como trabalhar com os padrões de segurança de Pods

Os padrões de segurança de Pods do Kubernetes ajudam desenvolvedores a manter seus aplicativos conteinerizados seguros no ambiente Kubernetes. Os três perfis de segurança — Privileged, Baseline e Restricted — têm diferentes níveis de restrição, de acordo com as necessidades dos usuários. O controlador de admissão Pod Security habilita esses padrões em clusters ou namespaces, aplicando políticas, auditando ou exibindo avisos conforme o nível escolhido. Se quiser, você também pode especificar uma versão.

As organizações podem usar os padrões de segurança de Pods para atender aos requisitos de segurança padrão do setor e se proteger contra possíveis escalações de privilégios e outras atividades mal-intencionadas. Em última análise, aplicar esses padrões por meio do controlador de admissão Pod Security simplifica o processo de desenvolvimento e protege todas as cargas de trabalho executadas em clusters Kubernetes.

Depois de configurar os padrões de segurança de Pods no Kubernetes, veja como o Snyk Container ajuda a encontrar e corrigir vulnerabilidades em contêineres durante todo o processo de desenvolvimento, oferecendo insights e recomendações para manter seus contêineres seguros.