Se você acompanha as tendências mais recentes de cloud computing, com certeza já esbarrou no termo eBPF várias vezes. É difícil não notar. Vamos entender por quê.
Está em busca de uma solução moderna de segurança, observabilidade e monitoramento sem abrir mão da performance? O eBPF pode ser a resposta! Neste artigo, vamos mergulhar nos motivos que fizeram desse recurso do Kernel do Linux um dos maiores buzzwords do stack cloud-native. Também vamos conhecer uma solução de cloud popular e pronta para uso, baseada em eBPF, e ver como ela pode turbinar a segurança, a observabilidade e o monitoramento do seu sistema na nuvem. Bora desvendar esse hype!
Se você já manja de eBPF e quer ir direto para a parte de Cilium/Dataplane V2, fique à vontade para pular para a Parte 2 !
O eBPF vive no espaço do Kernel do Linux, um território que a maioria de nós não costuma frequentar. Então, por que alguém que está "lá nas nuvens" deveria se importar com um recurso tão de baixo nível do Kernel do Linux? A verdade é que o eBPF é uma espécie de revolução. Ele tem um impacto enorme tanto em áreas de baixo nível quanto de alto nível.
Imagine, por exemplo, que você queira escrever uma lógica customizada que precise inspecionar de perto todos os pacotes de rede que trafegam entre seus containers e só permita a passagem de pacotes HTTP que atendam a critérios específicos.
Todo mundo sabe que, para mesclar, injetar e limitar tráfego de rede, é preciso estar no espaço do kernel. O Kernel do Linux é o lugar onde se manipula o funcionamento interno do sistema operacional Linux e sua robusta camada de rede, feita para performance, segurança e confiabilidade.
Antes do eBPF entrar em cena, era preciso escrever código de kernel do Linux (na linguagem C). Isso podia ser feito alterando o código-fonte do kernel ou escrevendo um módulo de kernel carregável. Além da complexidade inerente, isso trazia vários riscos, já que um módulo de kernel funciona como uma biblioteca dinâmica (tipo um arquivo .DLL ou .so) acoplada ao kernel.
Um bug de crash no seu código poderia causar kernel panic e derrubar o sistema operacional inteiro. Como usuário de cloud — ou, mais especificamente, como alguém que usa Kubernetes para fazer deploy de microsserviços — existem vários outros motivos para evitar escrever código de kernel customizado: segurança, velocidade de desenvolvimento, complexidade ou até inviabilidade do ambiente. No fim das contas, é matar uma formiga com bazuca.
Aí veio o eBPF 🐝
O eBPF surgiu e permitiu injetar lógica no kernel sem mexer no código dele — em outras palavras, direto do user-space. Ele não só simplifica esse processo como também o torna bem mais seguro. O processo de verificação do eBPF garante que o código carregado no seu kernel seja seguro para execução, aplicando uma série de checagens de segurança. Por exemplo, ele garante que:
- Seu código execute de forma finita (sem loops infinitos)
- Seu código não trave nem cause bugs fatais que possam comprometer o sistema
- O processo que está carregando seu código eBPF tenha os privilégios necessários
- Haja um limite de tamanho para o seu código
- Código inalcançável não seja permitido
Além do processo de verificação, há certas restrições que se aplicam ao seu código, como o fato de o eBPF obrigar o acesso a determinados recursos do kernel apenas por meio de helper functions específicas do eBPF. Resumindo: o eBPF oferece rede de segurança, facilidade de desenvolvimento, deploy tranquilo e performance aprimorada. Muitas ferramentas e engines já estão aproveitando a tecnologia eBPF para trazer novos recursos a workloads cloud-native de forma transparente e performática.
Se quiser colocar o eBPF para rodar, dá uma olhada neste vídeo .
Projetos populares movidos a eBPF 🔋
- Cilium — networking, segurança e observabilidade para Kubernetes baseados em eBPF
- Falco — segurança em runtime cloud-native
- Tracee — segurança em runtime e forense com eBPF
- Pixie — plataforma de troubleshooting de aplicações para Kubernetes (vale conferir!)
Espero que estas informações tenham sido úteis. Esta lista mostra outros projetos baseados em eBPF. Na Parte 2, vamos explorar o Cilium como uma solução popular de eBPF para K8s e descobrir o que o Dataplane V2 tem a ver com isso.
Obrigado pela leitura! Para ficar por dentro, siga-nos no DoiT Engineering Blog , no canal da DoiT no LinkedIn e no canal da DoiT no Twitter . Para conhecer oportunidades de carreira, acesse https://careers.doit-intl.com .