Dockerコンテナ内でセキュリティ更新を処理する方法は?


117

サーバーにアプリケーションを展開する場合、通常、アプリケーションがそれ自体にバンドルするものと、提供するプラットフォーム(オペレーティングシステムおよびインストール済みパッケージ)に期待するものとが分離されます。これの1つのポイントは、プラットフォームをアプリケーションとは無関係に更新できることです。これは、たとえば、アプリケーション全体を再構築せずにプラットフォームが提供するパッケージにセキュリティ更新プログラムを緊急に適用する必要がある場合に役立ちます。

従来、セキュリティアップデートは、パッケージマネージャコマンドを実行して、オペレーティングシステムにパッケージの更新バージョンをインストールするだけで適用されてきました(たとえば、RHELの「yum update」)。しかし、コンテナイメージがアプリケーションプラットフォームの両方を本質的にバンドルするDockerなどのコンテナテクノロジーの出現により、コンテナを備えたシステムを最新の状態に保つ標準的な方法は何ですか?ホストとコンテナの両方に独自の独立したパッケージのセットがあり、ホスト上で更新および更新が必要な場合、コンテナ内のパッケージは更新されません。Dockerコンテナが特に注目されているRHEL 7のリリースでは、コンテナのセキュリティ更新を処理するRedhatの推奨される方法を聞くのは興味深いでしょう。

いくつかのオプションについての考え:

  • ホスト上のパッケージマネージャーにパッケージを更新させても、コンテナー内のパッケージは更新されません。
  • 更新を適用するためにすべてのコンテナイメージを再生成する必要があると、アプリケーションとプラットフォームの分離が崩れるようです(プラットフォームを更新するには、Dockerイメージを生成するアプリケーションビルドプロセスにアクセスする必要があります)。
  • 実行中の各コンテナ内で手動コマンドを実行するのは面倒で、アプリケーションリリースアーティファクトからコンテナが次に更新されるときに変更が上書きされる危険があります。

したがって、これらのアプローチはどれも満足のいくものではありません。


1
私がこれまで見てきたこのための最良のアイデアは、Project Atomicです。私はそれはないと思う、非常にかかわらず、プライムタイムの準備ができて。
マイケルハンプトン

1
Valko、どのようなワークフローになりましたか?長期コンテナ(たとえば、php-cgiをホストしている)を実行していますが、これまでに見つかったのはdocker pull debian/jessie、イメージを更新し、既存のイメージを再構築してから、コンテナを停止して再度実行することです(新しい画像で)。作成するイメージの名前は以前のものと同じであるため、開始はスクリプトを介して行われます。次に、「名前のない」画像を削除します。ワークフローを改善していただければ幸いです。
ミハ14年

1
miha:それは私がやったことに似ているように聞こえます。基本的に、新しいリリースを作成する一環として、すべてのイメージを継続的に更新および再構築します。そして、新しいイメージを使用してコンテナを再起動します。
マルクスホールマン14年

1
最良の答えここでは、ヨハネスZiemkeが言った正確に何をするメインcommandlinesを含むスクリプトがあるため、多くのことができます:
ハドソンサントス

興味深い質問。私はそれについて自分で疑問に思います。1つのDockerホストで20のアプリケーションを実行している場合、ベースイメージをアップグレードし、再構築して再起動する必要があります!20のアプリケーションがあり、セキュリティ更新プログラムがそれらすべてに影響を与えたのか、それとも1つだけに影響を与えたのかさえわかりません。たとえば、セキュリティ更新プログラムがlibpngのみに影響した場合、Apacheのイメージを再構築する必要があります。したがって、不必要な再構築と再起動が必要になります...
Dalibor Filus

回答:


47

Dockerイメージには、アプリケーションと「プラットフォーム」がバンドルされています。これは正しいです。ただし、通常、イメージはベースイメージと実際のアプリケーションで構成されます。

したがって、セキュリティ更新プログラムを処理する標準的な方法は、ベースイメージを更新してから、アプリケーションイメージを再構築することです。


3
おかげで、これは理にかなっています。プラットフォームを更新するだけで、いわばアプリケーション全体の再パッケージ化をトリガーする必要はありません(たとえば、単一のベースイメージが更新されるため、100の異なるアプリケーションイメージを再構築する必要があると考えてください)。しかし、これは、単一のイメージ内にすべてをまとめるというDocker哲学では避けられないかもしれません。
マルクスホールマン14年

3
@ValkoSipuliプロセスを自動化するスクリプトをいつでも作成できます。
-dsljanus

なぜapt-getアップグレード、dnfアップグレード、pacman -syuなど、コンテナー内で同等ではないのですか?あなたもそれを行うシェルスクリプト作成することができ、その後、アプリケーションを実行し、コンテナが開始されたときに/それがすべてのパッケージをアップグレードし、再起動するように、コンテナのエントリポイントとしてそれを使用。
アーサーケイ

8
@ArthurKay 2つの理由:1)アップグレードされたすべてのパッケージがコンテナレイヤーに追加され、古いパッケージがイメージに保持されるため、コンテナーサイズが大きくなります。2)(コンテナ)イメージの最大の利点を無効にします:実行時にパッケージを変更するため、実行するイメージはビルド/テストするイメージとは異なります。
ヨハネス '魚'ジームケ

7
理解できないことが1つあります。ドッカーコンテナーとして出荷されるソフトウェアを購入する会社の場合、セキュリティの問題が発生するたびにソフトウェアの製造元がアプリケーションパッケージを再構築するのを待つ必要がありますか?どの会社がその方法でオープンな脆弱性の制御を放棄するでしょうか?
センテンツァ

7

コンテナは軽量で互換性があると想定されています。コンテナにセキュリティ上の問題がある場合、パッチを当てたバージョンのコンテナを再構築し、新しいコンテナをデプロイします。(多くのコンテナは、apt-getなどの標準パッケージ管理ツールを使用して依存関係をインストールする標準ベースイメージを使用します。再構築は、リポジトリから更新をプルします)

コンテナ内にパッチを適用することはできますが、それはうまくスケールしません。



0

まず、過去に実行していた更新の多くは、コンテナ自体には含まれません。コンテナは、過去に見慣れたファイルシステム全体のかなり軽量で小さなサブセットである必要があります。更新する必要があるパッケージは、DockerFileの一部であるパッケージになります。DockerFileがあるため、更新が必要なパッケージとコンテナーIDを追跡できる必要があります。すぐにリリースされるCloudsteinのUIは、これらのDockerFileの成分を追跡して、コンテナーに最適な更新スキームを構築できるようにします。お役に立てれば


-1

一般に、あなたが提供した3つの選択肢よりもさらに悪いです。ほとんどのdockerイメージはパッケージマネージャーを使用してビルドされていないため、単にdockerイメージにシェルして更新を発行することはできません。Dockerイメージを再構築するか、再取得する必要があります。

再構築する必要がある、またはセキュリティパッチのために再構築するために他の人に期待しているという事実は、ほとんどの場合、不合理に思えます。

私はドッカーコンテナにソナーとレーダーを配備することを検討していましたが、コンテナが取得する定期的なセキュリティアップデートを取得できないことは契約違反です。コンテナのセキュリティ更新プログラムを管理することは、各ドッカーイメージに個別にセキュリティ更新プログラムを手動で適用する必要がなく、面倒です。


1
質問への回答を提供しないため、投稿は回答とは見なされません。質問へのコメントとして追加し、「回答」を削除してください。StackExchangeはフォーラムではありませんが、専門家が支援できる質問に答えるQ&Aと見なすべきです。
フィリップ-Zyan K Lee-ストックマン
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.