0
0
Os métodos tradicionais de segurança de software não são adequados para kubernetes: um conjunto renovado de implementações de segurança são necessárias para torná-lo menos vulnerável.
O que há de diferente na segurança de Kubernetes?
Este artigo percorre várias ideias-chave que compreendem a segurança do software e destaca por que eles são um ajuste ruim para a infraestrutura baseada em Kubernetes. O segundo semestre discute abordagens kube-idiomáticas para a segurança e ideias sobre a redução de vulnerabilidades.
Mas primeiro, alguma história (porque se repete).
Proteger dispositivos de computação é um problema antigo. Ela se reinventou na era dos dispositivos em rede, e as coisas nunca mais foram as mesmas. A proliferação em larga escala da internet introduziu várias novas dimensões ao problema, e as soluções se adaptaram bem. Cada vez que a comunidade tecnológica muda o paradigma operacional, seus irmãos de segurança têm subido ao desafio.
As máquinas virtuais são consideradas um marco bastante importante na história da computação. Não apenas pela mudança tectônica que eles introduziram, mas em termos de como eles mudaram a maneira como computadores e computação foram pensados. Foi introduzida uma abstração que produziu análogos a dispositivos de computação reais. A abstração obviamente se estendeu a todos os componentes, como computação, armazenamento e rede. O desafio de segurança na época tornou-se bastante complexo, porque como você garante algo virtual?
A resposta estava na adaptação às áreas de superfícies de ataque, segurança em nível de sistema e uso de inúmeros outros meios inovadores para salvaguardar a infraestrutura virtualizada – que a comunidade de segurança realizou com grande sucesso. O mesmo tipo de mudança de paradigma é agora observado com a introdução e a adoção em escala planetária de contêineres e, consequentemente, Kubernetes
Mudando paradigmas
Grandes partes da pilha de aplicativos são abstratas com o uso de recipientes. A arquitetura tradicional de aplicação – tipicamente rotulada como “monolítica” – previa um método eficiente em escalas mais baixas de operação. Suas limitações tornaram-se muito evidentes à medida que as aplicações começaram a crescer em escopo e suas operações cada vez mais adicionadas de concorrência. O acoplamento apertado entre os componentes foi sintomático dessa arquitetura, que não promoveu qualquer reutilização de código, permitiu inchaço e não proporcionou agilidade suficiente. A comunidade então mudou para a arquitetura dos microsserviços. Implantar aplicativos usando contêineres foi um ajuste natural, pois todos eles poderiam compartilhar um denominador fundamental para sua pilha de tecnologia.
The use of containers (and Kubernetes) alters the principles of application development and deployment significantly. Kubernetes applies a high-level abstraction to the entire lifecycle of an application. A workload, the Kube-equivalent of a live application, is managed entirely from creation to shutdown (including subsequent restarts). Several instances of corrective action such as restarting unresponsive nodes, crashed pods, and others happen automatically when using the Kubernetes orchestrator.
With Kubernetes in place, security teams are left with limited visibility into the impact each change has. Commits, which are pushed automatically through a CI/CD system, help engineering teams achieve the velocity they need, but at the cost of being able to introduce change management and compliance at each stage.
A próxima área onde Kubernetes quebra modelos tradicionais de segurança é a natureza distribuída e efêmera das próprias cargas de trabalho. Kubernetes, que orquestra contêineres usando nós, pods e clusters, torna impossível introduzir um mapeamento cardeal entre cargas de trabalho, serviços e solicitações de clientes.
O agendamento dinâmico é um atributo imperativo dos sistemas baseados em Kubernetes. Não há provisionamento estático ou partição do sistema de arquivos ao trabalhar com ele. Isso o torna mais complexo ao projetar sistemas seguros.
Resolvendo o problema
A solução – para os problemas ilustrados acima e vários outros que surgem no espaço Kubernetes – pode ser segmentada em duas áreas primárias:
Segurança de tempo de construção
O estágio em que os contêineres imutáveis – que consistem em componentes de so host, bibliotecas e cargas de trabalho reais – são exportados é classificado como o tempo “Construir”. Existem várias maneiras de assar em práticas recomendadas de segurança durante o tempo de construção.
O primeiro princípio de melhorar a segurança nesta fase é o endurecimento do so host. Os controles de admissão também são uma peça importante do quebra-cabeça, assim como expor os pontos finais do serviço. Uma ferramenta/técnica cada vez mais popular para alcançar a segurança do tempo de construção é o uso de buildpacks. Todas essas políticas fundamentais de segurança e quaisquer práticas recomendadas podem ser implementadas facilmente usando buildpacks. Eles podem então ser consumidos repetidamente.
Ameaças da cadeia de suprimentos de código aberto podem ter um grande impacto ao implantar aplicativos em Kubernetes. Devido à natureza em grande parte de código aberto da pilha, ela pode ser propensa a vulnerabilidades em qualquer nível – como já foi declarado anteriormente. O Projeto de Lei de Materiais de Software (SBOMs) desempenha um papel importante no fornecimento da transparência necessária para proteger as cadeias de suprimentos que levam às aplicações que operam na produção.
Kubernetes emprega inúmeras senhas e certificados (segredos chamados coletivamente) a fim de facilitar a comunicação segura entre seus componentes. Em intervalos regulares, esses segredos são substituídos por novos. Os componentes individuais são obrigados a usar esses novos segredos. Proteger e agendar esses segredos é uma parte importante para garantir as implantações da Kubernetes.
Segurança de tempo de execução
Isso normalmente se refere ao conjunto de práticas de segurança que são empregadas quando as cargas de trabalho estão operacionais na produção (ou no estágio). Eles abrangem hosts, cargas de trabalho, as interfaces em rede que conectam esses componentes e serviços que interagem entre si. Eles se preocupam com vulnerabilidades que podem surgir quando os aplicativos são executados – ou executados.
Existem várias áreas que fornecem os ganchos necessários para melhorar a segurança do tempo de execução ao trabalhar com Kubernetes. Aqui estão algumas das melhores abordagens para reforçar a segurança do tempo de execução:
- O isolamento das cargas de trabalho é importante para fornecer uma base para a natureza auto-curativa de Kubernetes. Consequentemente, ajuda a evitar que quaisquer problemas que possam surgir de cargas de trabalho afetadas de atravessar para outros.
- Kubernetes possui uma API RBAC robusta que pode ser usada para regular e controlar o acesso a todos os tipos de recursos. Políticas dinamicamente configuráveis que podem ser ajustadas programáticamente fornecem um excelente modelo para criar verificações quando as vulnerabilidades são identificadas.
- Devido à arquitetura baseada em CRD, os serviços podem ser (re)configurados conforme necessário. Além disso, o uso de conexões diretas de pod, portas de nó e IPs de serviço de publicidade pode melhorar muito a segurança dos serviços baseados em Kubernetes. Cada vez mais, a segurança baseada em eBPF está aumentando como padrão-ouro ao garantir serviços.
- Registros de atividades para DNS, atividade kubernetes e tráfego de aplicativos são as três principais fontes de logs que capturam vários eventos. As metas de auditoria e conformidade que – tanto para os emergentes quanto para as empresas – usando esses dados como base garantirão maior segurança para o sistema.
Existem normas que regem a segurança de Kubernetes?
Várias estratégias para garantir Kubernetes são originárias de estruturas e modelos disponíveis publicamente. A equipe da Microsoft tem um excelente recurso que pode servir como ponto de partida para investigar as estratégias kubernetes certas para usar para qualquer equipe.
O Instituto Nacional de Normas e Tecnologia (NIST) publica uma estrutura para a segurança dos contêineres. É uma publicação focada para gerenciar riscos em torno de contêineres de aplicativos e gerenciamento de contêineres. Ele também estabelece práticas recomendadas de segurança para imagens de contêineres, sistemas operacionais de host, registros de contêineres, orquestradores de contêineres (como Kubernetes) e outros componentes que fazem parte da pilha.
Outra estrutura de segurança popular é o MITRE ATT&CK Framework. ATT&CK significa Táticas Contraditórias, Técnicas & Conhecimento Comum. Ele defende melhorar a segurança através de testes automatizados de segurança de forma contínua. Ele descreve várias vulnerabilidades. Uma razão importante para essa estrutura ser popular é que ela faz a curadoria de uma lista de técnicas e táticas comumente usadas durante ataques de segurança cibernética, a fim de preparar a infraestrutura contra ataques.
Há também estruturas de segurança específicas de Kubernetes. Um exemplo é o Kubernetes Benchmark publicado pelo Centro de Estudos da Internet (CIS). Ele oferece diretrizes detalhadas para o endurecimento de clusters, juntamente com configurações apropriadas que podem ajudar a proteger componentes de cluster através da configuração correta. Este benchmark também prescreve alertas com base na conformidade quando usado em contextos corporativos.
Outra notável estrutura de segurança nativa do ecossistema Kubernetes é a conformidade PCI DSS (Payment Card Industry Data Security Standard). Embora seja destinado a uma única vertical, os requisitos técnicos e operacionais prescritos são aplicáveis a qualquer distribuição kubernetes. Este padrão coloca ênfase na proteção de dados, privacidade e recomenda uma postura de segurança que reduz toda a vida útil do contêiner.
A natureza em evolução da segurança na nuvem
Aplicativos baseados em nuvem são suscetíveis a serem infiltrados. Desenvolvedores de aplicativos e operadores de plataforma não têm escolha a não ser ficar alertas e manter o foco em manter seu software seguro. Tanto que proteger pilhas de aplicativos nativos em nuvem é uma disciplina própria – DevSecOps.
A segurança kubernetes é construída sobre o modelo de fixação em camadas – especificamente: infraestrutura de nuvem, clusters, contêineres e código. A abordagem subjacente à segurança de Kubernetes é de defesa em profundidade. Este é um complemento perfeito para a abordagem em camadas que pode, em última análise, fornecer redundância contra explorações.
FONTE: HELPNET SECURITY