Como lidar com atualizações de segurança em contêineres Docker?

Ao implantar aplicativos em servidores, normalmente há uma separação entre o que o aplicativo agrupa consigo mesmo e o que ele espera da plataforma (sistema operacional e pacotes instalados) para fornecer. Um ponto disso é que a plataforma pode ser atualizada independentemente do aplicativo. Isso é útil, por exemplo, quando as atualizações de segurança precisam ser aplicadas com urgência aos pacotes fornecidos pela plataforma sem reconstruir todo o aplicativo.

Tradicionalmente, as atualizações de segurança foram aplicadas simplesmente executando um comando Gerenciador de pacotes para instalar versões atualizadas de pacotes no sistema operacional (por exemplo, "atualização yum" no RHEL). Mas com o advento da tecnologia de contêiner, como o Docker, onde as imagens de contêiner agrupam essencialmente o aplicativo e a plataforma, Qual é a maneira canônica de manter um sistema com contêineres atualizado? Tanto o host quanto os contêineres têm seus próprios conjuntos independentes de pacotes que precisam ser atualizados e atualizados no host não atualizarão Nenhum pacote dentro dos contêineres. Com o lançamento do RHEL 7, onde os contêineres Docker são especialmente apresentados, seria interessante ouvir Qual é a maneira recomendada da Redhat de lidar com atualizações de segurança dos contêineres.

Pensamentos sobre algumas das opções:

  • Deixar os pacotes de atualização do Gerenciador de pacotes no host não atualizará os pacotes dentro dos contêineres.
  • Ter que regenerar todas as imagens de Contêiner Para aplicar atualizações parece quebrar a separação entre o aplicativo e a plataforma (atualizar a plataforma requer acesso ao processo de compilação do aplicativo que gera as imagens do Docker).
  • Executar comandos manuais dentro de cada um dos contêineres em execução parece complicado e as alterações correm o risco de serem substituídas na próxima vez que os contêineres forem atualizados a partir dos artefatos de lançamento do aplicativo.

Portanto, nenhuma dessas abordagens parece satisfatória.

Um aplicativo de pacotes de imagem do Docker e "plataforma", está correto. Mas geralmente a imagem é composta por uma imagem base e a aplicação real.

Portanto, a maneira canônica de lidar com atualizações de segurança é atualizar a imagem base e, em seguida, reconstruir a imagem do aplicativo.

Os recipientes devem ser leves e intercambiáveis. Se o contêiner tiver um problema de segurança, você reconstruirá uma versão do contêiner corrigida e implantará o novo contêiner. (muitos contêineres usam uma imagem base padrão que usa ferramentas padrão de gerenciamento de pacotes como apt-get para instalar suas dependências, a reconstrução extrairá as atualizações dos repositórios)

Embora você possa consertar dentro dos contêineres, isso não vai escalar bem.

Isso é tratado automaticamente no SUSE Enterprise Linux usando zypper-docker (1)

SUSE / zypper-docker

Docker Início Rápido

Em primeiro lugar, muitas de suas atualizações que você tradicionalmente executou no passado simplesmente não estarão dentro do próprio contêiner. O contêiner deve ser um subconjunto bastante leve e pequeno do sistema de arquivos completo que você está acostumado a ver no passado. Os pacotes que você deve atualizar seriam aqueles que fazem parte do seu DockerFile e, como você tem o DockerFile, deve ser capaz de acompanhar esses pacotes e IDs de contêiner que precisam de atualizações. A interface do usuário do Cloudstein que será lançada em breve acompanha esses ingredientes do DockerFile para você, para que se possa construir o esquema de atualização que melhor se encaixa em seus contêineres. Espero que isso ajude

A melhor resposta here ajuda muito porque há um script que contém as principais linhas de comando para fazer exatamente o que Johannes ziemke disse:

A melhor ideia para isso que vi até agora é Project Atomic. não acho que esteja quite pronto para o horário nobre.

Valko, com que fluxo de trabalho você acabou? Estou executando contêineres de longo prazo(hospedando php-cgi, por exemplo) e o que encontrei até agora é: docker pull debian/jessie para atualizar a imagem, reconstruir minhas imagens existentes, parar os contêineres e executá-los novamente (com a nova imagem). As imagens que construo têm o mesmo nome das anteriores, então o início é feito por meio do script. Em seguida, removo imagens “sem nome”. Eu certamente apreciaria um fluxo de trabalho melhor.

Pergunta interessante. Eu mesmo me pergunto sobre isso. Se você tiver 20 aplicativos em execução em um host docker, precisará atualizar imagens básicas, reconstruir e reiniciar! 20 aplicativos e você nem sabe se a atualização de segurança afetou todos eles, ou apenas um deles. Você tem que reconstruir a imagem para dizer Apache quando a atualização de segurança afetou apenas libpng, por exemplo. Então você acaba com reconstruções e reinicializações desnecessárias…

miha: isso soa semelhante ao que acabei fazendo. Basicamente continuamente atualizando e reconstruindo todas as imagens como parte de fazer novos lançamentos. E reiniciando os contêineres usando as novas imagens.

Não tenho a resposta, mas caso alguém queira um script simples que possa ajudar a automatizar a verificação de atualizações de imagem base: [dockcheck] (GitHub - foresto/dockcheck: Docker image update checker)