Quando pensamos sobre segurança no Docker, é importante relembrar que a exploração de uma falha nesse ambiente podem ter efeitos catastróficos. Ainda mais quando é algo automatizado.

A ideia é ter certeza que o ambiente e o processo executado é o mais seguro possível.

Nem tudo é tão seguro quanto parece!

Vou apresentar algumas configurações iniciais que podem ser analisadas para tornar seu ambiente ainda mais seguro.

Restrição de acesso

No que tange a isolamento, o Docker tem muito a acrescentar e esse ponto não se limita ao fato das aplicações estarem separadas a nível de disco e processo. Podemos sair da dicotomia “root e não root”, pois entre um usuário sem permissão e o usuário root existe todo um gradiente de permissões que podem, e devem, ser analisadas e removidas caso não seja necessária.

Desde o kernel 2.2, as permissões foram divididas e chamadas de “capabilities”, que no docker podem ser “ligadas” ou “desligadas” por container. Isso permite que o ambiente tenha “a menor permissão necessária”, que é quase um mantra na área de segurança.

Para conhecer a lista de capabilities, segue o seguinte link.

No Docker, caso você não especifique nada sobre adicionar ou remover capabilities, a lista abaixo será aplicada no container:

• CHOWN
• DAC_OVERRIDE
• FSETID
• FOWNER
• MKNOD
• NET_RAW
• SETGID
• SETUID
• SETFCAP
• SETPCAP
• NET_BIND_SERVICE
• SYS_CHROOT
• KILL
• AUDIT_WRITE

Caso deseje remover permissão MKNOD, por exemplo, use o seguinte comando:

# docker run –cap-drop=MKNOD …

Caso deseja adicionar, LEASE por exemplo, use o seguinte comando:

# docker run –cap-add=LEASE …

Restrição de sistema de arquivo

Quando um container é instanciado é criado um novo ponto de montagem com arquivo da imagem usada para esse novo ambiente.

Esse espaço de disco da imagem é montado como somente leitura e assim uma camada superior é criada para receber as modificações que ocorrerem desde então. Caso queira aplicar essas modificações na imagem, pode usar o parâmetro “commit” para tal ação.

As modificações podem ser armazenadas em tags diferentes e assim se tornaria mais fácil fazer “rollback” das modificações, caso seja necessário. Pra usar tag é muito simples:

# docker tag <número ou nome da tag> <nome da imagem>

Multi Level Security

Com o Docker é possível manipular configurações do “MCS labels” para evitar que um container acesse indevidamente dados de outro container, por uma questão de má configuração ou exploração de alguma vulnerabilidade. Podemos aplicar um label a um processo baseado no nível de informação que você deseja que ele tenha acesso.

docker run -d –security-opt label:level:TopSecret httpd

Quer aprender um pouco mais sobre MLS? Leia aqui.

Outras medidas de segurança “fora” do Docker

As versões modernas do Kernel Linux podem ser complementadas com variadas ferramentas de segurança adicionais, tal como TOMOYO, AppArmor, SELinux e GRSEC, que podem funcionar perfeitamente com Docker, algumas inclusive já tem templates de configuração específicos para containers.

Você pode definir políticas customizadas de segurança com essas ferramentas. Basta ler seus respectivos manuais.

Referências:

https://d3oypxn00j2a10.cloudfront.net/assets/img/Docker%20Security/WP_Intro_to_container_security_03.20.2015.pdf

https://docs.docker.com/reference/run/#runtime-privilege-linux-capabilities-and-lxc-configuration

https://github.com/docker/docker/blob/master/daemon/execdriver/native/template/default_template.go

http://docs.docker.com/articles/security/