Quais são as melhores e abrangentes práticas a serem consideradas ao executar o docker em produção?

Por fim, você é tão apaixonado pelo Docker que deseja mover seus sistemas de produção críticos para os negócios on-line com dados confidenciais do cliente para um Docker Swarm. Alguns podem até já o ter feito. A outra organização não pode pagar por uma política que proíbe os processos de produção em execução no modo raiz.

O que poderia ser uma lista de verificação de componentes a serem considerados em um ambiente de produção do Docker? Não é necessário todos eles, mas todos devem ser importantes para serem avaliados.

Isenção de responsabilidade: Eu sei que existe uma política de SE para evitar "grandes listas sem fim", mas acho que essa lista de verificação não pode ser muito grande ... e sem fim hoje em dia.

Então - o que são esses blocos de edifícios?

1. Se ainda não estiver implantado, considere executar um sistema host Linux com configurações de segurança avançadas - kernel reforçado, SELinux etc.
2. Considere usar uma pequena imagem base do Docker, como alpine, busybox ou até scratch, por exemplo, comece com uma imagem base vazia
3. Use a configuração USER diferente da raiz
4. Avalie com cuidado para reduzir ainda mais o conjunto já reduzido de recursos do kernel concedido ao contêiner
5. Considere ter apenas um binário executável por contêiner para iniciar seu processo, idealmente vinculado estaticamente
6. Aqueles que desejam interromper o sistema para obter acesso ao shell podem se perguntar se descobriram que o contêiner está com todos os shells desativados.
7. Monte volumes somente leitura sempre que possível

Pergunta: o que mais?

O host no qual os contêineres estão em execução

Execute o banco de segurança do docker em todos os nós que executam contêineres do docker https://github.com/docker/docker-bench-security

Executando o seguinte comando em um nó que executa contêineres de docker:

docker run -it --net host --pid host --cap-add audit_control \
    -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \
    -v /var/lib:/var/lib \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -v /usr/lib/systemd:/usr/lib/systemd \
    -v /etc:/etc --label docker_bench_security \
    docker/docker-bench-security

retorna uma lista de verificações:

[INFO] 1 - Host Configuration

[WARN] 1.1  - Ensure a separate partition for containers has been created

[NOTE] 4.2  - Ensure that containers use trusted base images

[PASS] 4.6  - Ensure HEALTHCHECK instructions have been added to the container image

Citação do README do repositório:

O Docker Bench for Security é um script que verifica dezenas de práticas recomendadas comuns ao implantar contêineres Docker na produção. Os testes são todos automatizados e são inspirados no CIS Docker Community Edition Benchmark v1.1.0 .

Alguns dos problemas relatados pelo banco de segurança podem ser resolvidos lendo o artigo oficial de segurança do docker e comparando-o com os marcadores definidos na pergunta, as seguintes coisas também são importantes:

• proteger o soquete do daemon do docker implementando ssl
• confiança de conteúdo usando notário e DOCKER_CONTENT_TRUSTvariável

O Docker ainda está em desenvolvimento.

Como acontece com todos os outros bugs de desenvolvimento de software, recursos inseguros podem ser adicionados, podendo haver falhas de arquitetura que levam a violações de segurança. Não subestime isso! Seu sistema pode estar completamente seguro hoje, mas com o patch da próxima semana alguém encontra um bug, escreve uma exploração e, de repente, seu sistema está totalmente aberto.

A menos que você precise, não atualize para a versão mais recente. Use a versão mais recente e bem testada.

Docker não é virtualização

Se alguém escapar de um contêiner do Docker, esse invasor estará na máquina real imediatamente. Não há segundo portão como a virtualização que impedirá uma violação.

Trate um contêiner do Docker como qualquer outro programa. Execute com os direitos de usuário mais baixos possíveis, bloqueie todo o tráfego de rede desnecessário, virtualize todo o host do Docker, se o desempenho permitir.

O Docker não oferece proteção

Qualquer que seja o código executado dentro dos contêineres do Docker, é executado sem dúvida pelo Docker. Qualquer invasor pode simplesmente instalar seu software dentro do contêiner, e o Docker executaria isso como qualquer outro código.

Além do que você mencionou na pergunta, considere usar métricas e alertas para ser notificado se alguma imagem do Docker estiver fazendo coisas estranhas. Existe um pico repentino de CPU em andamento? O programa está fazendo uma varredura repentina nas portas de rede? Existe acesso suspeito ao disco? Você deve receber uma notificação se isso acontecer. Existem muitas ferramentas disponíveis para medir essas coisas, você deve usá-las.

Imagens do Docker em si

Uma opção adicional é usar Clair .

Clair é um projeto de código aberto para a análise estática de vulnerabilidades em contêineres de aplicativos (atualmente incluindo appc e docker).

Em intervalos regulares, Clair ingere metadados de vulnerabilidade de um conjunto configurado de fontes e os armazena no banco de dados.

Os clientes usam a API Clair para indexar suas imagens de contêiner; isso cria uma lista de recursos presentes na imagem e os armazena no banco de dados.

Os clientes usam a API Clair para consultar o banco de dados em busca de vulnerabilidades de uma imagem específica; vulnerabilidades e recursos correlatos são feitos para cada solicitação, evitando a necessidade de verificar novamente as imagens.

Quando ocorrem atualizações nos metadados da vulnerabilidade, uma notificação pode ser enviada aos sistemas de alerta de que ocorreu uma alteração.

Nosso objetivo é permitir uma visão mais transparente da segurança da infraestrutura baseada em contêiner. Assim, o projeto recebeu o nome de Clair após o termo em francês, que se traduz em claro, brilhante e transparente.

Além dos pontos neste tópico; a seguinte seria minha recomendação:

• Obtenha controle sobre o Docker PID1 com dumb-init
  • ref: PID1 e problema de colheita de zumbis
• Não execute a janela de encaixe na produção sem um sistema de orquestração de contêiner
  • Escolha entre Kubernetes, Mesos, Swarm etc.
• Use gosu para controle do usuário dentro de uma imagem do docker
• Siga o paradigma de aplicativo de 12 fatores, se você estiver executando aplicativos com estado em contêineres, altere-o.
  • Se você realmente precisar executar aplicativos com estado (mysql, zookeeper, elasticsearch) em contêineres, aproveite os paradigmas do orquestrador como o Kubernetes Statefulsets
• Faça um gerenciamento de configuração / segredo robusto com ferramentas como hashicorp vault / consul
• Envie o mesmo contêiner criado pelos desenvolvedores para produzir através de um pipeline de CI que o leva a realizar testes de integração e de teste completamente.
• Crie notificações em torno de CVEs e patches, gatilho constrói na notificação de patch
• Tenha um registro extensivo para obter informações sobre o contêiner em execução. Você não deseja conceder aos devs SSH acesso ao host ou aos contêineres
  • recomendação: fluente
• Tenha métricas de contêiner e host
  • recomendação: prometheus + nó-exportador

Se você estiver preenchendo o ponto de entrada do Docker com sedcomandos, considere esta prática:

• Use uma ferramenta como confd para gerenciar os arquivos de configuração das imagens do docker e mantê-los atualizados

O Confd lerá dados de muitos armazenamentos de valores-chave suportados e renderizará modelos de configuração dinamicamente.

Pode-se usar o A2D para criar um aplicativo em uma imagem do docker, levando em consideração certas coisas, por exemplo, permissões não raiz, localização do aplicativo:

docker run -v $PWD:/projectName utrecht/a2d:1.0.0 \
       -projectName someProjectName -dockerfile /projectName/Dockerfile

retorna:

FROM golang:1.12.4-alpine as builder
COPY . ./someProjectName/
WORKDIR someProjectName
RUN adduser -D -g '' someProjectName && \
    apk add git && \
    CGO_ENABLED=0 go build && \
    cp someProjectName /someProjectName && \
    chmod 100 /someProjectName

FROM scratch
COPY --from=builder /etc/group /etc/group
COPY --from=builder /etc/passwd /etc/passwd
COPY --from=builder --chown=someProjectName:someProjectName /someProjectName /usr/local/someProjectName
COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
USER someProjectName
ENTRYPOINT ["/usr/local/someProjectName"]