E ai pessoal! Neste texto vou falar sobre algumas quest\u00f5es ligadas \u00e0 seguran\u00e7a no uso do Docker. Poucas pessoas se preocupam, mas eventualmente a falta de aten\u00e7\u00e3o a alguns fatores pode prejudicar sua aplica\u00e7\u00e3o e seu neg\u00f3cio.<\/p>\n
Kernel exploits (explora\u00e7\u00e3o do kernel) Denial-of-service attacks (ataque de nega\u00e7\u00e3o de servi\u00e7o) Container breakouts (invas\u00e3o de container) Poisoned images (imagens \u201cenvenenadas\u201d) Application secrets (segredos de aplica\u00e7\u00f5es) No t\u00f3pico anterior foi levantada algumas preocupa\u00e7\u00f5es de seguran\u00e7a que devemos ter ao usar containers, agora vamos ver algumas poss\u00edveis solu\u00e7\u00f5es para tentar resolver estes problemas. Mas como ent\u00e3o devemos armazenar nossas credenciais de acesso quando usamos containers? Uma \u00f3tima solu\u00e7\u00e3o \u00e9 utilizar o Docker Secrets Management.<\/p>\n O Docker Secrets funciona como um cofre onde voc\u00ea pode colocar coisas sens\u00edveis l\u00e1 e s\u00f3 quem tem a chave do cofre consegue utilizar, no caso essa chave \u00e9 designada aos n\u00f3s dos servi\u00e7os que a chave for atribu\u00edda. Mais de como funciona pode ser visto no blog Mundo Docker – Docker Secrets<\/a>.<\/p>\n Outras dicas de seguran\u00e7a menciono abaixo em forma de t\u00f3picos:<\/p>\n Proteja seu host<\/strong><\/p>\n Redu\u00e7\u00e3o dos privil\u00e9gios<\/strong><\/p>\n Alto uso de recursos do container<\/strong><\/p>\n Autenticidade da imagem<\/strong><\/p>\n Vulnerabilidades de seguran\u00e7a presentes na imagem<\/strong><\/p>\n
\n<\/strong>Ao contr\u00e1rio de uma Virtual Machine, ao usar containers o kernel \u00e9 compartilhado entre todos os containers e o host, aumentando a import\u00e2ncia de qualquer vulnerabilidade que explore o kernel.<\/p>\n
\n<\/strong>Como todos os containers compartilham recursos do kernel, se um container pode monopolizar o acesso a certos recursos, incluindo mem\u00f3ria, ou at\u00e9 IDs de usu\u00e1rio (UIDs), pode faltar recursos para outros containers, resultando em uma nega\u00e7\u00e3o de servi\u00e7o (DoS).<\/p>\n
\n<\/strong>Um invasor que tem acesso a um container n\u00e3o pode ter acesso a outros containers ou ao host. Se voc\u00ea usa root no container, voc\u00ea ser\u00e1 root no host.<\/p>\n
\n<\/strong>Como voc\u00ea sabe que as imagens que voc\u00ea est\u00e1 usando s\u00e3o seguras, n\u00e3o foram adulteradas, e v\u00eam de onde elas afirmam vir?<\/p>\n
\n<\/strong>Quando um container acessa um banco de dados ou servi\u00e7o, provavelmente exigir\u00e1 credenciais, como um token ou mesmo usu\u00e1rio e senha. Se um invasor tiver acesso ao container ter\u00e1 acesso a estes dados.<\/p>\nBoas pr\u00e1ticas de seguran\u00e7a ao usar Docker<\/h2>\n
\nInicio esse t\u00f3pico com uma pergunta.
\nComo devemos armazenar dados sens\u00edveis, como senhas, chaves privadas, tokens, chaves de APIs?
\nPara come\u00e7ar a responder esta pergunta, eu acho mais f\u00e1cil e direto responder como n\u00e3o devemos armazenar dados sens\u00edveis.
\nN\u00e3o use vari\u00e1veis de ambiente ou incorpore na imagem de container. \u00c9 uma dica meio \u00f3bvia mas acontece e muito. Se quiserem ler sobre um caso, de utiliza\u00e7\u00e3o de credenciais incorporadas na imagem e que vazou, tem um consideravelmente conhecido que aconteceu com a IBM: IBM Data Science Experience: Whole-Cluster Privilege Escalation Disclosure.<\/p>\nDocker Secrets Management<\/h3>\n
\n
\n
\n
\n
\n