[解決済み] gosuとUSERを使ったDockerの比較

質問

Docker のようなものは、常に USER コマンドで特定のユーザーとしてプロセスを実行することができますが、一般的には多くのものがROOTとして実行されなければなりませんでした。

私はこれまで、多くの画像で ENTRYPOINT と gosu を使って、実行するプロセスの昇格を解除します。

の必要性について、まだ少し混乱しています。 gosu . USERで十分ではないでしょうか？

Docker 1.10でセキュリティの面でかなり変わったのは知っていますが、Dockerコンテナでプロセスを実行する推奨方法については、まだはっきりしません。

どなたか、どのような場合に gosu vs. USER ?

ありがとうございます。

EDIT

Dockerは ベストプラクティスガイド はあまり明確ではありません: プロセスが特権なしで実行される場合、そのプロセスは USER を、sudo が必要な場合は gosu . でROOTとしていろいろなものをインストールすることができるので、これは混乱します。 Dockerfile としてインストールし、ユーザーを作成して適切な権限を与え、最後にそのユーザーに切り替えて CMD をそのユーザで実行します。 では、なぜ sudo や gosu が必要なのでしょうか？

どのように解決するのですか？

Dockerfileはイメージを作成するためのものです。Dockerfileの実行コマンドの間でユーザを変更できなくなったときに、コンテナの初期化の一部としてgosuがより有用であると私は考えています。

イメージを作成した後、gosuのようなものを使えば、コンテナ内のエントリポイントの最後にroot権限を落とすことができます。いくつかの初期化ステップ (uid の修正、ホスト マウントされたボリュームのパーミッションなど) を行うために、最初は root アクセスが必要な場合があります。その後、初期化されたら、最終的なサービスをルート権限なしで、シグナルをきれいに処理するために pid 1 として実行します。

編集します。 dockerとjenkins用のイメージでgosuを使用する簡単な例です。 https://github.com/bmitch3020/jenkins-docker

entrypoint.sh は /var/lib/docker.sock ファイルの gid を調べ、コンテナ内の docker ユーザーの gid を一致させるように更新します。これにより、ホスト上の gid が異なる可能性のある他の docker ホストにイメージを移植することができます。グループを変更するには、コンテナ内の root アクセスが必要です。もし私が USER jenkins を使用していた場合、イメージで定義されたドッカーグループの gid を使用することになり、実行するドッカーホストの gid と一致しない場合は動作しないことになります。しかし、アプリを実行する際にルートアクセスを落とすことができますので、そこでgosuの出番となります。

スクリプトの最後で、execコールはシェルがgosuをフォークするのを防ぎ、代わりにpid 1をそのプロセスで置き換えます。Gosu も同様に、uid を切り替えてから jenkins プロセスを exec して、pid 1 として引き継ぎます。これにより、pid 1 としてシェルによって無視されるシグナルが正しく処理されるようになります。