À medida que as organizações adotam cada vez mais uma abordagem nativa da Nuvem para desenvolver e dimensionar aplicações, os contêineres e os Kubernetes estão desempenhando um papel crítico no gerenciamento de complexidades crescentes, permitindo que cargas de trabalho sejam implementadas em ambientes multinuvem.
Mas uma pesquisa recente com profissionais de DevOps apontou que 94% sofreram pelo menos um incidente de segurança de Kubernetes no ano passado e 59% consideram a segurança sua maior preocupação quando se trata de usar Kubernetes e contêineres. Enquanto mais e mais equipes de DevOps recorrem ao Kubernetes para acompanhar as demandas de escalabilidade de suas organizações, princípios básicos como segurança e proteção de Dados não devem ser negligenciados.
Implementando o Kubernetes
Os desenvolvedores estão sendo solicitados para criar aplicações maiores e mais escaláveis em ambientes mais dinâmicos. Portanto, para a equipe de operações ou infraestrutura, acompanhar as mudanças nas práticas de desenvolvimento de software pode parecer um trabalho árduo. O Kubernetes é apenas o desafio mais recente (e possivelmente mais complexo), mas seu objetivo permanece o mesmo: como reduzir riscos, minimizar custos e fornecer um melhor resultado geral para os negócios?
As equipes de desenvolvimento são as ‘pioneiras’ – elas exploram novos caminhos e constroem algo onde nada existia antes. As equipes de operações e infraestrutura, por outro lado, são os ‘colonos’ – chegando em uma segunda onda para consolidar novos desenvolvimentos e garantir que sobrevivam a longo prazo. Este é exatamente o caso do Kubernetes. No momento em que o Kubernetes está no estágio de virtualização ou adoção, normalmente a responsabilidade pelo resultado comercial real recai sobre as equipes de operações.
Mas é um grande pedido esperar que essas equipes entendam as complexidades do Kubernetes e dos contêineres. Mesmo com a nova tecnologia, os princípios básicos precisam ser respeitados – segurança, Backup e recuperação ainda são necessários. Mas são os requisitos técnicos exclusivos que podem apresentar desafios.
Segurança em Kubernetes e Zero Trust
Como um programa nativo da Nuvem, muitos dos desafios de segurança do Kubernetes vêm da natureza dispersa da arquitetura da Nuvem. Cargas de trabalho diferentes podem ser executadas em vários locais diferentes, incluindo diversas Nuvens, bem como servidores locais e externos. Isso não apenas aumenta consideravelmente a ‘ameaça’ em que um ataque ou erro pode ocorrer, mas também pode significar desafios de visibilidade, dificultando o monitoramento de contêineres e a detecção de problemas.
Embora o Kubernetes seja projetado para ser seguro, respondendo apenas a solicitações que ele pode autenticar e autorizar, ele também oferece aos desenvolvedores opções de configuração sob medida, o que significa que é tão seguro quanto as políticas RBAC (Role-based access control) que os desenvolvedores configuram. O Kubernetes também usa o que é conhecido como “flat network” que permite que grupos de contêineres (ou pods) se comuniquem com outros contêineres por padrão. Isso aumenta as preocupações com a segurança, pois, em teoria, os invasores que comprometem um pod podem acessar outros recursos no mesmo cluster.
Apesar dessa complexidade, a solução para mitigar esse risco é bastante direta – uma estratégia de confiança zero. Com uma superfície de ataque tão grande, um design de rede bastante aberto e cargas de trabalho em diferentes ambientes, uma arquitetura de confiança zero, que nunca confia e sempre verifica, é crucial ao construir com o Kubernetes.
O princípio da arquitetura de confiança zero é mover o foco da segurança para longe do perímetro de uma aplicação enquanto se aplica esses princípios por toda parte. Todas as solicitações internas são consideradas suspeitas e a autenticação é necessária de cima para baixo. Essa estratégia ajuda a mitigar o risco, assumindo que as ameaças existem na rede o tempo todo e, portanto, mantém constantemente procedimentos de segurança rígidos para cada usuário, dispositivo e conexão. Para a arquitetura fluida e descentralizada do Kubernetes, isso é obrigatório.
Restaurar e recuperar
Outro princípio básico necessário para mitigar os riscos dos aplicativos Kubernetes é o Backup e a recuperação. Este é um conceito bem conhecido, mas há muitas considerações exclusivas ao fazer backup de Kubernetes e contêineres. Esses requisitos diferentes para backup de dados são porque o Kubernetes é fundamentalmente diferente de outras arquiteturas. Ele não possui aplicativos de mapeamento para servidores ou máquinas virtuais, por exemplo.
Os sistemas de backup do Kubernetes também precisam ser centrados em aplicações, em vez de focados na infraestrutura. Isso se deve à filosofia DevOps e aos princípios de “shift left”, que significam essencialmente que o desenvolvedor tem mais controle sobre a infraestrutura e as implantações. Outros requisitos exclusivos para o backup do Kubernetes são a escala do aplicativo, as lacunas de proteção e a integração do ecossistema.
Ao recuperar ambientes do Kubernetes, é necessário um plano de execução detalhado que identifique as dependências do cluster, atualize os aplicativos para refletir novos componentes de armazenamento e traduza o plano em interfaces de APIs relevantes do Kubernetes. Embora o backup exija uma solução nativa em Kubernetes mais personalizada, esses processos de recuperação permanecem críticos para a integridade dos negócios a longo prazo. A restauração eficiente e a recuperação de desastres não são negociáveis no ambiente atual, com interrupções que custam cerca de € 1.459 por minuto.
Além disso, no entanto, o backup tem um valor enorme em termos de testes e desenvolvimento e possibilita a mobilidade das aplicações, que se refere à capacidade de migrar uma aplicação para um ambiente diferente – entre locais, nuvens, clusters ou Kubernetes. Isso é cada vez mais importante à medida que os ambientes de TI se tornam mais complexos e as empresas precisam responder a novos requisitos de negócios, adotar novas plataformas de TI ou otimizar custos.
Preparar-se para a mudança
Apesar do Kubernetes apresentar novos desafios técnicos, em última análise, quanto mais as coisas mudam, mais elas permanecem as mesmas. As equipes de operações e infraestrutura estão bem acostumadas a incorporar novas ferramentas na tecnologia em constante expansão e os princípios básicos, como mitigação de riscos por meio de proteção de dados moderna, ainda servem a seu propósito.
Uma vez que esses recursos tenham sido estabelecidos, as equipes de operação podem começar a olhar mais longe e explorar o aproveitamento do valor de seus dados por meio de atividades como teste e otimização. Através de um backup robusto que oferece suporte à mobilidade de aplicações, as equipes também podem percorrer um longo caminho para proteger essas aplicações no futuro, garantindo que os serviços possam enfrentar com mais facilidade a próxima onda de mudanças. Embora o Kubernetes seja a ferramenta atual que está mudando o cenário dos desenvolvedores, certamente ela não será a última.
Por Michael Cade, tecnólogo global Senior da Veeam.
Você também pode gostar
