ホストを危険にさらすことなく任意のDockerfileイメージを構築する方法
Dockerfileから直接イメージを構築するサーバーを構築しています。
docker build -t arbitrarydocker .
このDockerファイルは、他のクライアントDockerfilesと同じサーバー上に構築されます。 docker build -t arbitrarydocker .を実行するプロセスをロックして、次のようなことを行わないようにするにはどうすればよいですか。
ADD /contents/of/Host/secrets ./space/in/hacker/docker/container
私が考えることができる最良の方法は、プロセスをforkし、独自のシークレットが制限された機能で保持されている1つのフォルダーのみへのディレクトリアクセスが制限されている作成ユーザーで実行することです。データが次のクライアントビルドにリークされないようにdockerfileがビルドされた後、メモリを完全に消去する方法があるかどうかも疑問に思っています。
安全にそれを行う唯一の方法がクライアントごとに専用のビルドサーバーを用意することである場合、私はそれを行うことができますが、それは避けたいです。
すべてのビルドはCentosで行われます。
ここで明白なことを述べて、ただ"/ contents/of/Host/secretsをビルダーVMに含めないでください。"おそらく、何かが起こっているそれは明白な答えをそれほど明らかに正しくないものにします。
Dockerビルドプロセスは必須（宣言ではない）であり、dockerfileで任意のダウンロードや実行などを行うため、「任意のDockerビルド」は文字通り「任意のコード実行」であることを指摘しておきましょう。インターネットからのコードは、Dockerビルドの世界ではTotally A Thing™です。
言い換えると、Dockerビルドプロセス全体が潜在的に悪意のあるものであるため、攻撃者が提供するコードをサンドボックス化するという観点から考える必要があります。ビルダー（攻撃者）のランタイム環境と実質的に他のすべての間の強力なセキュリティ境界が必要です。 Dockerコンテナーはセキュリティの境界ではないことを聞いたことがありますが、攻撃者が制御するDockerコンテナーはpretendでもセキュリティの境界になることはありません。ビルダーは独自のVMで実行する必要があり、ビルダーと独自のシステム間のすべてのアクセスは、明確に定義された通信チャネルによって仲介される必要があります。バックドアアクセスなし。
それを念頭に置いて、もう一度/contents/of/Host/secrets。 dockerビルドはビルダーVMで実行されます。 VMは信頼できないため隔離されており、攻撃者と意図的に共有していないシークレットにはアクセスできません。賢明な解決策があります。
クリーンアップの場合：VMを削除するだけです。 「元の」HD画像からもう一度再起動します。
あなたが発明しているホイールは以前に何度も発明されているので、あなたが直面する問題をどのように解決したかについてのアイデアについて、既存のソリューションを調べることをお勧めします。
権限のないコンテナ内からイメージを構築することもできます。これにより、ホストに対する他の脅威に対する保護も追加されます（たとえば、任意のコマンドの実行）。 カニコ は、まさにそれを行うためのツールの例です。