Como lidar com as atualizações de segurança nos contêineres do Docker?


117

Ao implantar aplicativos em servidores, normalmente há uma separação entre o que o aplicativo agrupa e o que espera da plataforma (sistema operacional e pacotes instalados) a 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 urgentemente aos pacotes fornecidos pela plataforma sem reconstruir o aplicativo inteiro.

Tradicionalmente, as atualizações de segurança são aplicadas simplesmente executando um comando do gerenciador de pacotes para instalar versões atualizadas dos pacotes no sistema operacional (por exemplo, "yum update" no RHEL). Mas com o advento da tecnologia de contêineres, como o Docker, onde as imagens do contêiner agrupam essencialmente o aplicativo e a plataforma, qual é a maneira canônica de manter um sistema com contêineres atualizado? O host e os contêineres têm seus próprios conjuntos de pacotes independentes, 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 do Docker são especialmente apresentados, seria interessante saber qual é a maneira recomendada pela Redhat de lidar com as atualizações de segurança dos contêineres.

Reflexões sobre algumas das opções:

  • Permitir que o gerenciador de pacotes atualize pacotes no host não atualizará pacotes dentro dos contêineres.
  • Ter que regenerar todas as imagens de contêiner para aplicar atualizações parece interromper a separação entre o aplicativo e a plataforma (a atualização da plataforma requer acesso ao processo de criação do aplicativo que gera as imagens do Docker).
  • A execução de comandos manuais em cada um dos contêineres em execução parece complicada 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 liberação do aplicativo.

Portanto, nenhuma dessas abordagens parece satisfatória.


1
A melhor idéia para isso que eu vi até agora é o Project Atomic . Eu não acho que é bastante pronto para o horário nobre embora.
Michael Hampton

1
Valko, com qual fluxo de trabalho você terminou? Estou executando contêineres de longo prazo (hospedando php-cgi, por exemplo) e o que encontrei até agora é: docker pull debian/jessieatualizar a imagem, reconstruir minhas imagens existentes, interromper os contêineres e executá-los novamente ( com a nova imagem). As imagens que eu construo têm o mesmo nome que as anteriores, então a inicialização é feita através do script. Em seguida, removo imagens "sem nome". Eu certamente apreciaria um melhor fluxo de trabalho.
miha

1
miha: Isso soa parecido com o que acabei fazendo. Basicamente, atualizando e reconstruindo continuamente todas as imagens como parte de novos lançamentos. E reiniciando os contêineres usando as novas imagens.
Markus Hallmann #

1
A melhor resposta aqui ajuda muito, porque há um script que contém principais comandos de linha para fazer exatamente o que Johannes Ziemke disse:
Hudson Santos

Pergunta interessante. Eu mesmo me pergunto. Se você tiver 20 aplicativos em execução em um host docker, precisará atualizar as imagens base, reconstruir e reiniciar! 20 aplicativos e você nem sabe se a atualização de segurança afetou todos eles, ou apenas um deles. Você precisa recriar a imagem para o Apache quando a atualização de segurança afetou apenas a libpng, por exemplo. Então você acaba com reconstruções e reinicializações desnecessárias ...
Dalibor Filus 03/08

Respostas:


47

Uma imagem do Docker agrupa aplicativo e "plataforma", isso está correto. Mas geralmente a imagem é composta de uma imagem base e da aplicação real.

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


3
Obrigado, isso parece razoável. Apenas ainda desejamos atualizar a plataforma, por assim dizer, não teria que acionar a reembalagem de todo o aplicativo (considere, por exemplo, ter que reconstruir 100 imagens de aplicativos diferentes devido a uma única imagem base ser atualizada). Mas talvez isso seja inevitável com a filosofia do Docker de agrupar tudo em uma única imagem.
Markus Hallmann #

3
@ValkoSipuli Você sempre pode escrever um script para automatizar o processo.
precisa saber é o seguinte

Por que não o apt-get upgrade, dnf upgrade, pacman -syu, etc equivalente dentro do contêiner? Você pode até criar um script de shell que faça isso e, em seguida, executar o aplicativo, e usá-lo como o ponto de entrada do contêiner para que, quando o contêiner for iniciado / reiniciado, ele atualize todos os seus pacotes.
Arthur Kay

8
@ArthurKay Duas razões: 1) Você aumenta o tamanho do contêiner, pois todos os pacotes que são atualizados serão adicionados à camada do contêiner enquanto mantém o pacote desatualizado na imagem. 2) Derrota a maior vantagem das imagens (contêiner): A imagem que você executa não é a mesma que você cria / testa porque altera os pacotes no tempo de execução.
Johannes 'fish' Ziemke

7
Há uma coisa que eu não entendo: se você é uma empresa que compra um software enviado como contêiner de docker, precisa aguardar que o fabricante do software reconstrua o pacote de aplicativos sempre que surgir um problema de segurança ? Qual empresa desistiria do controle sobre suas vulnerabilidades abertas dessa maneira?
Sentenza

7

Os recipientes devem ser leves e intercambiáveis. Se o seu contêiner tiver um problema de segurança, você recriará 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 de gerenciamento de pacotes padrão, como o apt-get para instalar suas dependências, a reconstrução puxará as atualizações dos repositórios)

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



0

Antes de tudo, muitas de suas atualizações que você executou no passado simplesmente não estarão no próprio contêiner. O contêiner deve ser um subconjunto pequeno e bastante leve do sistema de arquivos completo que você está acostumado a ver no passado. Os pacotes que você deve atualizar devem ser aqueles que fazem parte do seu DockerFile e, como você possui o DockerFile, deve poder acompanhar os pacotes e IDs de contêiner que precisam de atualizações. A interface do usuário do Cloudstein, que será lançada em breve, controla esses ingredientes do DockerFile para você, para que você possa criar o esquema de atualização mais adequado para seus contêineres. Espero que isto ajude


-1

geralmente é ainda pior do que as três opções que você forneceu. A maioria das imagens de janela de encaixe não é criada com gerenciadores de pacotes; portanto, você não pode simplesmente fazer um shell na imagem de janela de encaixe e emitir uma atualização. Você precisará reconstruir ou obter novamente a imagem da janela de encaixe.

O fato de que você precisa reconstruir ou está prestando atenção a outras pessoas para reconstruir para patches de segurança não parece razoável na maioria dos casos.

Eu estava pensando em implantar sonarr e radarr em contêineres de docker, mas saber que eles não receberão as atualizações de segurança regulares que meu contêiner recebe é uma quebra de negócio. O gerenciamento de atualizações de segurança para meu contêiner é bastante complicado, sem que seja necessário, de alguma forma, aplicar manualmente as atualizações de segurança a cada imagem do docker individualmente.


1
Sua postagem não seria considerada uma resposta, pois você não fornece uma resposta para a pergunta. Por favor, adicione-o como um comentário à pergunta e remova sua "resposta". O StackExchange não é um fórum, mas deve ser considerado como uma sessão de perguntas e respostas, na qual os especialistas respondem a perguntas com as quais podem fornecer ajuda.
Phillip -Zyan K Lee- Stockmann
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.