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

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

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

というのも、 docker container
はその仕組み上、メインで動くプロセスはただそのサーバープログラムのみになる、と考えられます。ただそのプログラムのみが動くのであるならば、わざわざユーザーを分離するような設定は行うメリットはあるのだろうか、とふと疑問に思ったので質問しています。
CC BY-SA 3.0
2018-01-31T03:41:45.957
41340
2018-04-19T14:42:29.693
754
question
docker
docker image を定義する際に、サーバーのユーザーは分けるべき?
他のコンテナやホストとボリュームを共有する場合、ユーザーを分けることについて心配する必要があります。
他のコンテナがデータを読み書きするためには、ボリュームを共有するすべてのコンテナによって共有されるユーザーと権限を設定する必要があります。
CC BY-SA 3.0
2018-02-01T16:39:50.540
41391
2018-02-01T16:39:50.540
27244
41340
answer
Dockerコンテナであっても不要または意図しないファイル変更を防ぐことができます．

誤ってファイルを削除してもDockerホストには影響ないかもしれませんが，プロセスの異常動作を防ぐことができるかもしれません．  
特に開発時には `docker
exec`コマンドで`bash`等を実行することがよくあります．このときもデフォルトでroot以外のユーザで実行すると操作ミスからデータを守ることができます．

また，1つのコンテナで1つのプロセスのみを実行することが理想ですが，実際にはそうでなく単一コンテナで複数プロセスを実行する例もいくつかあります．このときはプロセスの実行ユーザを分けることで，Dockerコンテナ以外のときと同様の利点を得ることができます．
CC BY-SA 3.0
2018-02-02T12:15:19.020
41414
2018-02-02T12:15:19.020
7770
41340
answer
利用するアプリケーションは、想定するユーザ／グループがありますが、想定通りユーザを作るのが良いです。Apacheのwww-
userやOracleのdbaグループです。  
セキュリティの観点と言うより、アプリケーションが前提としている条件（ユーザやグループ、ポート、パス）を合わせてあげることで、変更しなければならない設定を減らせるので管理対象を少なくできることが主な要因だと思います。

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

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

```

    $ docker run -it -v test:/mnt --rm --read-only alpine sh
    / # touch /mnt/aaa
    / # touch /tmp/bbb
    touch: /tmp/bbb: Read-only file system
    / # 
    
```
CC BY-SA 3.0
2018-04-19T14:42:29.693
43400
2018-04-19T14:42:29.693
5285
41340
answer