6 ms·

Docker Storage: An Introduction

102 points by nslater 10y ago

andrewstuart2 10y ago
So I was going to be snarky about the author not having their linux user as a member of the "docker" group (thus requiring sudo every command) but that sparked a line of thought; so I'll ask: Is it better practice to leave yourself out of the docker group, thus forcing explicit use of sudo, since the daemon runs as root? Is there a better daemon auth model that's not in use so you can at least have longer-lived tokens, etc? Also, in case you do want to skip the sudo every time (careful with the potential security risk): sudo usermod -aG docker $(whoami)
- deleted 10y ago
  [deleted]
- atmosx 10y ago
  Only a developer could ask such a question!!!! I'm joking :-P From a sysadmin standpoint sudo is the right choice. Sudo is an established, well defined, (mostly) bug-free program, designed to specifically for that task. It's tool for the job. You can create specific policies[1] keep track of who, what, when, allow this and deny that. I reckon that this case is a bit tricky though and most people just use sudo to get 'root', so if you're going to do just that, then I guess it's the same. [1] http://linux.die.net/man/5/sudoers http://linux.die.net/man/5/sudoers
  - cyphar 10y ago
    > I reckon that this case is a bit tricky though and most people just use sudo to get 'root', so if you're going to do just that, then I guess it's the same. sudo is still better in that case, because sudo leaves an audit trail in your system log. Docker doesn't keep a detailed audit log for every request made by a user.
    - alrs 10y ago
      https://github.com/a2o/snoopy https://github.com/a2o/snoopy
- manacit 10y ago
  Handing an unprivileged user access to Docker is, functionally, the same as handing them access to sudo. Once you are allowed to run arbitrary Docker containers, you have limitless access to root on the running host. For this reason, I would vastly prefer requiring sudo to communicate with a local Docker daemon. Sudo was designed for this purpose, has the proper logging and fin(er) grained access control.
  - lojack 10y ago
    Everyone always says this, and I know security isn't a #1 priority and that it'd be a big mistake to assume Docker is secure -- but, are there any known security issues with Docker that could give sudo access to the host machine? Anything beyond the standard: "Don't trust it because its almost certainly not secure."
    - Titanous 10y ago
      Yes, you can run a privileged container that bind-mounts / on the host into the container. root.
      - emmelaich 10y ago
        I presume that the default selinux policy in redhat7 would stop this. But that would mean using the docker version in redhat7, which tends to trail behind a little.
    - manacit 10y ago
      The issue, as another poster pointed out, is not that there are vulnerabilities in the Docker daemon, but that access to the socket inherently gives you access to run arbitrary containers in privileged mode. This allows you access to the full host: https://docs.docker.com/engine/reference/run/#/runtime-privilege-and-linux-capabilities https://docs.docker.com/engine/reference/run/#/runtime-privi... and everything that a normal root user can do. At present, there is no great way to mitigate this if you're tracking the official Docker releases (at least, as far as I know).
- cyphar 10y ago
  > Is there a better daemon auth model that's not in use so you can at least have longer-lived tokens, etc? Docker does have authorization plugins[1], and there is work to get authentication working[2]. So the answer is "eventually being in the docker group will be safer", but not yet. Personally, I think the future of containers (at least for a lot of the cases I deal with) is going to be with rootless containers[3]. But that's another story. [1]: https://github.com/docker/docker/pull/15365 https://github.com/docker/docker/pull/15365 [2]: https://github.com/docker/docker/issues/14674 https://github.com/docker/docker/issues/14674 [3]: https://github.com/opencontainers/runc/pull/774 https://github.com/opencontainers/runc/pull/774
rburhum 10y ago
Glad to see more articles like this. I find tons of writings about stateless containers, but hardly any about best practices for stateful containers. Just yesterday I was going over the Django tutorial in the official Docker docs. Everything there made sense except that it completely ignores how to handle "media" folders (i.e. the Django folder that, among other things, contains user uploads). Yes, the database is in a volume so I am glad that survives creating/destroying the postgres container, but I kind of need the other files, too.
- atmosx 10y ago
  Well in today's world you'll handle the media folder by hosting files in the cloud (e.g. an S3 bucket). Most of the times if you use volumes, it's because of poor design[1] than anything else. [1] modern web-app design guidelines: http://12factor.net/ http://12factor.net/
  - ngrilly 10y ago
    Well, I keep reading this, but what if you design an app that relies on local storage, for example one that uses an embedded database like SQLite, LevelDB or BoltDB? 12 factors don't address this.
    - aleem 10y ago
      You would not get redundancy or scale and you would need to do offsite backups yourself which is why it's not recommended over cloud DBs. Building stateless containers is good practice. There will always be exceptions but it's good to know the tradeoffs before making those exceptions.
      - tokenizerrr 10y ago
        Right, and third party software is a thing. There are also plenty of reasons to prefer the simplicity of SQLite even if that means you have the task of managing your own backups.

102 points by nslater 10y ago

So I was going to be snarky about the author not having their linux user as a member of the "docker" group (thus requiring sudo every command) but that sparked a line of thought; so I'll ask: Is it better practice to leave yourself out of the docker group, thus forcing explicit use of sudo, since the daemon runs as root? Is there a better daemon auth model that's not in use so you can at least have longer-lived tokens, etc? Also, in case you do want to skip the sudo every time (careful with the potential security risk): sudo usermod -aG docker $(whoami)

deleted 10y ago
[deleted]
atmosx 10y ago
Only a developer could ask such a question!!!! I'm joking :-P From a sysadmin standpoint sudo is the right choice. Sudo is an established, well defined, (mostly) bug-free program, designed to specifically for that task. It's tool for the job. You can create specific policies[1] keep track of who, what, when, allow this and deny that. I reckon that this case is a bit tricky though and most people just use sudo to get 'root', so if you're going to do just that, then I guess it's the same. [1] http://linux.die.net/man/5/sudoers http://linux.die.net/man/5/sudoers
- cyphar 10y ago
  > I reckon that this case is a bit tricky though and most people just use sudo to get 'root', so if you're going to do just that, then I guess it's the same. sudo is still better in that case, because sudo leaves an audit trail in your system log. Docker doesn't keep a detailed audit log for every request made by a user.
  - alrs 10y ago
    https://github.com/a2o/snoopy https://github.com/a2o/snoopy
manacit 10y ago
Handing an unprivileged user access to Docker is, functionally, the same as handing them access to sudo. Once you are allowed to run arbitrary Docker containers, you have limitless access to root on the running host. For this reason, I would vastly prefer requiring sudo to communicate with a local Docker daemon. Sudo was designed for this purpose, has the proper logging and fin(er) grained access control.
- lojack 10y ago
  Everyone always says this, and I know security isn't a #1 priority and that it'd be a big mistake to assume Docker is secure -- but, are there any known security issues with Docker that could give sudo access to the host machine? Anything beyond the standard: "Don't trust it because its almost certainly not secure."
  - Titanous 10y ago
    Yes, you can run a privileged container that bind-mounts / on the host into the container. root.
    - emmelaich 10y ago
      I presume that the default selinux policy in redhat7 would stop this. But that would mean using the docker version in redhat7, which tends to trail behind a little.
  - manacit 10y ago
    The issue, as another poster pointed out, is not that there are vulnerabilities in the Docker daemon, but that access to the socket inherently gives you access to run arbitrary containers in privileged mode. This allows you access to the full host: https://docs.docker.com/engine/reference/run/#/runtime-privilege-and-linux-capabilities https://docs.docker.com/engine/reference/run/#/runtime-privi... and everything that a normal root user can do. At present, there is no great way to mitigate this if you're tracking the official Docker releases (at least, as far as I know).
cyphar 10y ago
> Is there a better daemon auth model that's not in use so you can at least have longer-lived tokens, etc? Docker does have authorization plugins[1], and there is work to get authentication working[2]. So the answer is "eventually being in the docker group will be safer", but not yet. Personally, I think the future of containers (at least for a lot of the cases I deal with) is going to be with rootless containers[3]. But that's another story. [1]: https://github.com/docker/docker/pull/15365 https://github.com/docker/docker/pull/15365 [2]: https://github.com/docker/docker/issues/14674 https://github.com/docker/docker/issues/14674 [3]: https://github.com/opencontainers/runc/pull/774 https://github.com/opencontainers/runc/pull/774

rburhum 10y ago

Glad to see more articles like this. I find tons of writings about stateless containers, but hardly any about best practices for stateful containers. Just yesterday I was going over the Django tutorial in the official Docker docs. Everything there made sense except that it completely ignores how to handle "media" folders (i.e. the Django folder that, among other things, contains user uploads). Yes, the database is in a volume so I am glad that survives creating/destroying the postgres container, but I kind of need the other files, too.

atmosx 10y ago
Well in today's world you'll handle the media folder by hosting files in the cloud (e.g. an S3 bucket). Most of the times if you use volumes, it's because of poor design[1] than anything else. [1] modern web-app design guidelines: http://12factor.net/ http://12factor.net/
- ngrilly 10y ago
  Well, I keep reading this, but what if you design an app that relies on local storage, for example one that uses an embedded database like SQLite, LevelDB or BoltDB? 12 factors don't address this.
  - aleem 10y ago
    You would not get redundancy or scale and you would need to do offsite backups yourself which is why it's not recommended over cloud DBs. Building stateless containers is good practice. There will always be exceptions but it's good to know the tradeoffs before making those exceptions.
    - tokenizerrr 10y ago
      Right, and third party software is a thing. There are also plenty of reasons to prefer the simplicity of SQLite even if that means you have the task of managing your own backups.