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

Question

Ao implantar aplicativos em servidores, normalmente há uma separação entre o que o aplicativo agrupa consigo 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 recriar o aplicativo inteiro.

Tradicionalmente, as atualizações de segurança foram aplicadas simplesmente executando um comando do gerenciador de pacotes para instalar versões atualizadas de pacotes no sistema operacional (por exemplo, "yum update" no RHEL). Mas com o advento da tecnologia de contêineres, como o Docker, em que as imagens de contêiner basicamente empacotam o aplicativo e a plataforma, qual é a maneira canônica de manter um sistema com contêineres atualizados? Tanto o host quanto os contêineres possuem seus próprios conjuntos independentes de pacotes que precisam de atualização e atualização no host; eles não atualizam 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 para lidar com as atualizações de segurança dos contêineres.

Pensamentos sobre algumas das opções:

• Permitir que os pacotes de atualização do gerenciador de pacotes no host não atualizem os pacotes dentro dos contêineres.
• Ter de gerar novamente todas as imagens do contêiner para aplicar as atualizações parece quebrar 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 dentro de cada um dos contêineres em execução parece incômoda e as alterações correm o risco de serem sobrescritas na próxima vez em que os contêineres forem atualizados a partir dos artefatos de liberação do aplicativo.

Portanto, nenhuma dessas abordagens parece satisfatória.

    

Answer 1

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

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

    

Answer 2

Os contêineres devem ser leves e intercambiáveis. Se o seu 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 de 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 aplicar patch em contêineres, isso não será bem dimensionado.

    

Answer 3

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

SUSE / zypper-docker

Início rápido do Docker

    

Answer 4

Em primeiro lugar, muitas de suas atualizações que você executava tradicionalmente no passado simplesmente não estã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 são aqueles que fazem parte do DockerFile e, como você tem o DockerFile, você deve ser capaz de controlar 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 acompanha esses ingredientes do DockerFile para que você possa criar o esquema de atualização mais adequado para seus contêineres. Espero que isso ajude