Técnicas de contêineres na verificação de segurança: Docker and Co. - um risco de segurança para as empresas?

Anonim

Os contêineres são áreas encapsuladas em kernel em um sistema e fornecem ambientes isolados para processos em execução. A idéia básica é fornecer blocos prontos para aplicativos. Atualmente, os contêineres podem ser construídos com vários padrões: Docker, AppC ou o antepassado LXC podem ser mencionados aqui. Infelizmente, esses padrões não são compatíveis entre si. A Open Container Initiative, fundada em 22 de junho de 2015, dá origem à esperança bem fundamentada de que um padrão comum seja estabelecido aqui em um futuro próximo. Não menos importante, porque os membros consistem em alguns representantes bem conhecidos da cena.

O Docker Hub - riscos e efeitos colaterais

Uma das grandes simplificações que o Docker trouxe aos desenvolvedores é o Docker Hub. Permite publicar e baixar imagens de contêineres concluídas. Mas isso abre a porta para espalhar imagens manipuladas de contêineres. Somente com o Docker 1.8 é possível assinar imagens. Para uma operação segura, é essencial criar você mesmo as imagens e operar um registro Docker privado. Infelizmente, isso atualmente reduz a capacidade de reutilização da empresa ou sobreposição de aplicativos.

  1. Ponte Docker
    Sem inserir nenhum parâmetro de configuração adicional, o Docker criará uma rede padrão com base na ponte docker0 na inicialização; encaminha pacotes de dados somente entre interfaces diretamente conectadas; para que os contêineres sejam acessíveis a partir do sistema host local, mas não do lado de fora.
  2. mapeamento de porta janela de encaixe
    Mapeamento de portas: o primeiro e o segundo contêineres são acessíveis através de uma porta DNAT separada do sistema host (do intervalo 49153-65535) e da ponte docker0 do lado de fora; a disponibilidade do terceiro contêiner na rede é limitada ao sistema host e aos contêineres da própria instância do Docker.
  3. Ponte vSwitch aberta
    Se você não deseja fazer seu trabalho com os olhos vendados, pode verificar se a nova ponte foi criada conforme desejado.
  4. Open vSwitch Masquerade
    Na configuração padrão, o Docker Bridge não é roteado para o exterior; O vSwitch aberto fornece a todos os pacotes de saída a identidade do roteador.
  5. OpenvSwitch
    Um exemplo de configuração do Docker usando o Open vSwitch para rede entre contêineres de contêineres.
  6. flanela
    Fluxo de comunicação entre contêineres do Docker em dois hosts diferentes usando flanela.
  7. tecer
    Os roteadores de tecer em diferentes hosts se vêem como parceiros de comunicação iguais (os chamados pares).
  8. recipientes weave
    O comando ifconfig dentro do contêiner confirma a existência de uma interface de rede criada pelo Weave chamada ethwe.
  9. Tecer ping na AWS
    O contêiner Docker 42f519bf8e94 em um host EC2 (ip-15-0-0-104) faz ping em outro contêiner Ubuntu (8ce9c00e4aaf) por meio de uma rede virtual Weave, executando em um host EC2 remoto (ip-15). 0-0-23) na mesma sub-rede de uma nuvem privada virtual (VPC) em execução na AWS.
  10. Tecer Ping
    Exemplo de um ping na AWS ..
  11. Início rápido na AWS
    Para uma introdução mais abrangente ao Amazon Web Services (AWS), consulte o trabalho Início rápido no AWS: Amazon Web Services. Administração EC2 em procedimento rápido "

Container Runtime - um desafio para a segurança

Para poder executar, os contêineres exigem um tempo de execução, que é executado como um daemon no host e controla o ciclo de vida do contêiner. Existem dois representantes dignos de nota: Dockers runc e rkt, desenvolvido pelo CoreOS. Tecnicamente, os tempos de execução são baseados em dois conceitos do kernel Linux: isolamento de namespace e grupos de controle. Isso torna possível isolar certos grupos de processos e recursos um do outro, semelhante ao Solaris Zones. A completude desse isolamento coloca outros desafios em termos de segurança

• Mapeamento de usuário

Como não há espaços para nome de usuário, os UIDs dos arquivos disponíveis no contêiner são atualmente mapeados um a um no sistema host. Teoricamente, isso permite que os contêineres iniciem ataques a arquivos de outros usuários do sistema host.

spoods.de

• Acesso a recursos críticos do host

Os contêineres do Docker acessam um conjunto restrito de comandos do kernel via lista de permissões. No entanto, essa lista de vulnerabilidades do kernel torna relativamente fácil permitir que o contêiner saia do contêiner, a menos que tenha muito cuidado na configuração dos recursos. Ainda existe uma falta de experiência na comunidade para possíveis vetores de ataque, bem como melhores práticas.

• Permissões de root do daemon: o daemon é executado com privilégios de root e, atualmente, não há maneiras de configurar restrições baseadas em função nos comandos executáveis. Portanto, é aconselhável, de acordo com o Docker, permitir apenas o acesso de "usuários confiáveis". Seria desejável um conceito baseado em função e uma divisão do Docker Daemon em partes privilegiadas e não privilegiadas.

O ecossistema de contêineres - o mercado está confuso

Para poder usar contêineres de maneira significativa para a operação de um aplicativo complexo, é indispensável interconectar vários contêineres e gerenciar o cluster resultante. Nesta área, o mercado ainda é muito confuso. Você precisa de muitas ferramentas pequenas, que permitem apenas uma operação estável em combinação. É importante distinguir entre as seguintes categorias:

Orquestração

Isso se refere às possibilidades de como vários contêineres podem ser descritos junto com suas conexões e implantados. Os representantes mais conhecidos são Kubernetes, Apache Mesos e Docker Swarm e frota CoreOS.

• hosts de contêiner

Sistemas operacionais mínimos especiais, que são personalizados apenas para a operação de contêineres, são chamados de hosts de contêiner. Os representantes mais conhecidos são CoreOS, Atomic Host e Ubuntu Core.

Rede

Como vários contêineres podem se comunicar entre hosts diferentes e como você pode gerenciá-los facilmente de acordo com as políticas IaC (Infraestrutura como Código)? A flanela CoreOS ou o recurso experimental do Docker 1.7 em diante são uma opção.

• Plataforma como serviço

As plataformas PaaS prometem uma solução integrada que aborda todos os desafios discutidos. Aqui está principalmente o OpenShift Origin na versão 3, que depende do Docker, Kubernetes e Atomic Host.

Se você observar a maturidade dessas ferramentas, poderá ver que muitas estão na versão beta tardia ou em uma primeira versão estável. Isso se reflete na falta ainda de recursos de múltiplos clientes e de auditoria, o que, por sua vez, dificulta o amplo uso em ambientes controlados ou multiusuários.

conclusão

Apesar dessas fraquezas, as tecnologias de contêiner estão fazendo um grande progresso no suporte aos esforços de Entrega Contínua e DevOps. A velocidade com que o desenvolvimento está avançando nessa área sugere que, em um futuro próximo, mesmo com as funções de segurança necessárias para uma operação corporativa, será alcançado um nível que permitirá o uso simples e amplo de contêineres.

Para poder usar essas tecnologias ainda hoje, dependendo da necessidade de proteção, é necessária uma combinação com mecanismos de segurança clássicos. Aqui, a separação de um aplicativo em diferentes áreas de proteção deve ser feita pelo menos no nível de máquinas virtuais, separadas por firewalls clássicos (virtualizados). Como atualmente ainda não é seguro operar várias áreas de proteção no mesmo cluster de contêineres. O conceito de função ausente no tempo de execução permite apenas uma separação com a granularidade de hosts. Esses recursos foram parcialmente implementados em produtos PaaS, como o Red Hat OpenShift.

Em resumo, os contêineres são uma tecnologia promissora cujo valor agregado é incontestável. Infelizmente, os aspectos de segurança estão lentamente se tornando o foco dos desenvolvedores. Portanto, para uso em ambientes produtivos, atualmente, consideráveis ​​gastos adicionais precisam ser investidos para garantir uma operação segura. (Wh)

Contêiner do Docker: links úteis

Docker: http://docker.com

AppC: https://github.com/appc/spec/

LXC: https://linuxcontainers.org

Iniciativa Open Container: https://www.opencontainers.org

Docker 1.8. Versão: https://blog.docker.com/2015/08/docker-1-8-content-trust-toolbox-registry-orchestration/

RunC: https://runc.io

Tempo de execução do contêiner: https://github.com/coreos/rkt

CoreOS: https://coreos.com

Documentação de segurança do Docker: http://docs.docker.com/articles/security/#docker-daemon-attack-surface

Kubernetes: http://kubernetes.io

Apache Mesos: http://mesos.apache.org

Dockor Swarm: https://www.docker.com/docker-swarm

frota: https://coreos.com/using-coreos/clustering/

Host atômico: http://www.projectatomic.io

Ubuntu Core: https://wiki.ubuntu.com/Core

flanela: https://github.com/coreos/flannel

Origem do OpenShift: http://www.openshift.org/