docker image を定義する際に、サーバーのユーザーは分けるべき?


たとえば、サーバープログラムを、マシンにインストールする場合には、基本的に user を分けると思います。 mysql
をインストールしているならば、そのデータディレクトリは mysql:mysql の owner であるようにすると思っています。

これは、セキュリティであったり、運用的に、サーバーが触るファイルをきっちりと分割することで、もろもろのトラブルを回避できるからやるのだと理解しています。

docker でとあるサーバーのイメージを自分で作る場合を考えます。この場合でもそのサーバー専用に `adduser`
して、プログラム自体の実行はそのユーザーでやるし、また対応するデータディレクトリもその新しく定義したユーザーが所有者として動作するように設定を行うべきなのでしょうか?

というのも、 docker container
はその仕組み上、メインで動くプロセスはただそのサーバープログラムのみになる、と考えられます。ただそのプログラムのみが動くのであるならば、わざわざユーザーを分離するような設定は行うメリットはあるのだろうか、とふと疑問に思ったので質問しています。




利用するアプリケーションは、想定するユーザ／グループがありますが、想定通りユーザを作るのが良いです。Apacheのwww-
userやOracleのdbaグループです。  
セキュリティの観点と言うより、アプリケーションが前提としている条件（ユーザやグループ、ポート、パス）を合わせてあげることで、変更しなければならない設定を減らせるので管理対象を少なくできることが主な要因だと思います。

セキュリティの観点でユーザを分けることを検討するのであれば、docker 1.5から導入された、read-
onlyコンテナを考えた方が良いと思います。volume以外のパスへの書き込みは一切できなくなるので、意図しない修正がかなり絞り込まれます。

下記のように`--read-only`でvolume以外の書き込みはできません。

[code]

    $ docker run -it -v test:/mnt --rm --read-only alpine sh
    / # touch /mnt/aaa
    / # touch /tmp/bbb
    touch: /tmp/bbb: Read-only file system
    / # 
    
[/code]




利用するアプリケーションは、想定するユーザ／グループがありますが、想定通りユーザを作るのが良いです。Apacheのwww-
userやOracleのdbaグループです。  
セキュリティの観点と言うより、アプリケーションが前提としている条件（ユーザやグループ、ポート、パス）を合わせてあげることで、変更しなければならない設定を減らせるので管理対象を少なくできることが主な要因だと思います。

セキュリティの観点でユーザを分けることを検討するのであれば、docker 1.5から導入された、read-
onlyコンテナを考えた方が良いと思います。volume以外のパスへの書き込みは一切できなくなるので、意図しない修正がかなり絞り込まれます。

下記のように`--read-only`でvolume以外の書き込みはできません。

[code]

    $ docker run -it -v test:/mnt --rm --read-only alpine sh
    / # touch /mnt/aaa
    / # touch /tmp/bbb
    touch: /tmp/bbb: Read-only file system
    / # 
    
[/code]

