Nestes últimos anos, o uso de containers para empacotar e entregar aplicações tem se tornado cada vez mais presente nos processos de desenvolvimento. Então, é importante entendermos como podemos garantir a segurança dos containers e, por consequência, de nossas aplicações.
Mas vale lembrar que já escrevemos antes sobre por que a segurança de containers é importante para manter as aplicações seguras, e sugerimos que você consuma também nossos conteúdos prévios sobre o tema para uma maior compreensão.
Não é raro ouvirmos que, ao usar Docker, estamos tornando nossos sistemas ainda mais seguros e, diretamente, tornando todo nosso processo mais seguro. Ah, vale ressaltar que aqui a palavra sistema tem um sentido mais genérico que determina um conjunto de pequenos componentes para formar um todo.
Com o uso de Docker, temos sim condições de tornar todo nosso processo – e nossos sistemas – mais seguros. No entanto, não é por isso que temos que acreditar que tudo se resolve apenas no uso de containers no Docker. Não é incomum ouvirmos de pessoas no mercado de desenvolvimento e de segurança que containers do Docker são apenas aplicações rodando em um ambiente de sandbox, e isso os leva a acreditar que, ao usar containers, seus sistemas host estarão protegidos.
Cuidados com a segurança dos containers
Claro que se você estiver executando o Docker em um sistema controlado e utilizando as melhores práticas de seguranças, suas preocupações serão muito menores – mas alguns cuidados ainda são necessários. O que nos preocupa é que muitas vezes vemos profissionais entenderem que a execução de containers é uma forma mais simples de executar uma máquina virtual e que não há uma ligação direta entre a execução do container e o seu sistema host. De forma geral, containers são mais inseguros que máquinas virtuais.
Se você acredita que os containers devem ser tratados como qualquer outro serviço, e por exemplo, estivesse executando um servidor Apache em um containers, você provavelmente adotaria os mesmo cuidados com o container que adotaria com o serviço em si, certo? E basicamente começaria a:
- Eliminar os privilégios do container que não são estritamente necessários;
- Evitaria executar os serviços como root do sistema sempre que possível;
- Olharia para o root do container como olharia para o root do seu sistema.
Isso pra dizer o mínimo !
E o que temos orientado é que tratem a execução de containers e seus processos privilegiados da mesma forma e com o mesmo cuidado que tratam processos privilegiados fora de um container.
A validação é necessária
Então, basicamente não execute imagens de container de forma aleatória no seu sistema. Esse comportamento nos lembra muito a execução de bibliotecas e componentes de terceiros sem a devida validação, sem o devido cuidado, apenas porque nos parece ter uma fonte segura.
Também, para os mais experientes, isso nos lembra do início do uso do Linux. Ou seja, quando os sysadmins ouviam falar de um serviço novo no Linux e apenas buscavam por estes pacotes – muitas vezes em repositórios nada confiáveis – mas mesmo assim os instalavam e, seguindo as orientações, os executavam com privilégios mais altos. Nada bom, né?
O mesmo está acontecendo agora com os containers. Afinal, todos acreditam que não precisam validar ou mesmo duvidar do que vem empacotado dentro dele.
Para aqueles que nunca tiveram a curiosidade de ler a documentação da Docker, trago aqui um pedaço bem interessante, em tradução livre:
“Os contêineres são leves porque não precisam da carga extra de um hipervisor, mas são executados diretamente no kernel da máquina host”.
Se você foi atencioso, vai perceber a parte onde a documentação deixa bem claro que “são executados diretamente no kernel da máquina host” ! Notaram? Containers têm acesso direto ao kernel do seu sistema host. Só isso já deveria deixar qualquer um atento aos cuidados extremos ao trabalhar com containers.
Mas o que poderia dar errado?
Bom, se você já usou uma distribuição Linux, sabe que temos repositórios que são mantidos pela empresa, como a Red Hat ou mesmo a Ubuntu. E sabe que outros que são mantidos por uma comunidade de desenvolvedores, que podem ter muito esforço, mas também podem deixar passar algumas coisas.
Aqui por exemplo, se você usa uma distribuição como a Red Hat, sabe que a empresa oferece aos administradores e a seus usuários um repositório confiável, onde eles podem baixar software das Atualizações de Segurança para corrigir vulnerabilidades. Então aqui vai nossa primeira dica: execute apenas containers confiáveis !
Como conceito básico, não conte com a tecnologia de containers como sendo a tecnologia que vai resolver seus problemas de segurança ela não protegerá o seu host.
LEIA TAMBÉM: Cloud Security – Como a Segurança é afetada
Então, qual é o problema?
Para entendermos qual é o problema, temos que entender um dos conceitos fundamentais por trás da tecnologia de containers.
Containers são basicamente processos sendo executados de formas isoladas. Por exemplo, é como se estivéssemos executando um serviço dentro de um sandbox.
Este isolamento, a grosso modo, é feito por meio do uso de namespaces, e no Linux, nem tudo tem seu namespaces.
Atualmente, a tecnologia Docker usa apenas 5 namespaces :Process, Network, Mount, Hostname, Shared Memory. Só para você entender, em um sistema de máquina virtual, a sua aplicação não está diretamente em contato com o kernel do sistema, não tem acesso direto a sistemas de arquivos como por exemplo /sys and /sys/fs, /proc/*, que é o caso de sistemas de containers que podem ter este tipo de acesso.
Ok mas, a pergunta continua: qual é o problema ?
Bom, se olharmos para uma estrutura de VM(Virtual Machines) para conseguir subverter a execução do processo e alcançar níveis de privilégio maiores de kernel, o atacante precisará comprometer uma série de camadas entre o sistema, a máquina virtual e, por fim, o host. Já no caso de execução de containers, este acesso já é direto, percebeu? Aqui está uma lista de alguns subsistemas do kernel que não tem um namespace:
- SELinux
- Cgroups
- file systems under /sys
- /proc/sys, /proc/sysrq-trigger, /proc/irq, /proc/bus
O que quer dizer que se você conseguir comprometer o container e este estiver sendo executado com privilégios errados, o acesso a estes subsistemas será garantido de forma mais fácil.
Então, respondendo à pergunta deste tópico, o problema é que temos visto muitos usuários de containers que não os estão configurando de forma correta. E isso pode levar a problemas sérios de comprometimento de sistemas.
SAIBA MAIS SOBRE NOSSOS SERVIÇOS
Conclusão
O que colocamos aqui não inviabiliza a tecnologia de containers e nem sugere que você a abandone. O que queremos é alertar para a necessidade de mais entendimento de como a tecnologia funciona e como ela pode ser melhor aproveitada para entregar todos os benefícios.
Entendemos e acreditamos que o melhor é o entendimento da tecnologia que estamos usando, e como configurar esta tecnologia da melhor forma possível.
Assim, queremos jogar uma luz sobre este problemas e dizer que olhar para a segurança do host pode ser um grande avanço para garantir a segurança de todo o sistema.
Além disso, busque entender como pode ser melhor criado e configurado o container, de forma a garantir uma execução mais segura.
Esperamos ver você em outro artigo.
LEIA TAMBÉM: Como aumentar a segurança de seu container (parte 2)
