3 ms·

There's definitely use cases for Docker with Go that mostly revolve around running untrusted code or wanting to be able to set tight restrictions on CPU usage,

by d4l3k 8y ago

There's definitely use cases for Docker with Go that mostly revolve around running untrusted code or wanting to be able to set tight restrictions on CPU usage, memory etc. Though you could also just do the latter via cgroups. Another use case might be if you have extra files that need to be deployed with the binary as well. I wrote up some documentation about this for my use case just in case I ever have to go back and change it. You can see it here: https://fn.lc/post/docker-scratch/ https://fn.lc/post/docker-scratch/

dijit 8y ago
>There's definitely use cases for Docker with Go that mostly revolve around running untrusted code. Please don't run untrusted code in Docker, it's not designed for security. https://security.stackexchange.com/questions/107850/docker-as-a-sandbox-for-untrusted-code/108013 https://security.stackexchange.com/questions/107850/docker-a...
- Zekio 8y ago
  Docker containers can run in other places where they are secure, IIRC then Joyent has way to do this in their cloud
  - dijit 8y ago
    You havent refuted my point. People take a stance that docker can run untrusted code without actually looking at what they have to do for that to be true.
    - d4l3k 8y ago
      I haven't taken the stance that all docker containers can run untrusted code, but I've certainly done my best to harden my docker containers as much as possible. If you took a look at that write up I cover it. I run with the flags: --net=none --cap-drop=all --cpus=1 --read-only --tmpfs=/tmp:rw,size=1g,mode=1777,noexec This gives it no way to communicate with the outside world and drops all capabilities so it's not allowed to interact with the kernel at all. Setting CPU limit to be 1 also prevents DOS attacks internally. I also run the process under the nobody user which entirely avoids the "container root is system root" issue. I'm also only sort of running "untrusted" code. I'm running tensorflow models which can do arbitrary computation but are more secure than just running raw code.

by d4l3k 8y ago

dijit 8y ago

>There's definitely use cases for Docker with Go that mostly revolve around running untrusted code. Please don't run untrusted code in Docker, it's not designed for security. https://security.stackexchange.com/questions/107850/docker-as-a-sandbox-for-untrusted-code/108013 https://security.stackexchange.com/questions/107850/docker-a...

Zekio 8y ago
Docker containers can run in other places where they are secure, IIRC then Joyent has way to do this in their cloud
- dijit 8y ago
  You havent refuted my point. People take a stance that docker can run untrusted code without actually looking at what they have to do for that to be true.
  - d4l3k 8y ago
    I haven't taken the stance that all docker containers can run untrusted code, but I've certainly done my best to harden my docker containers as much as possible. If you took a look at that write up I cover it. I run with the flags: --net=none --cap-drop=all --cpus=1 --read-only --tmpfs=/tmp:rw,size=1g,mode=1777,noexec This gives it no way to communicate with the outside world and drops all capabilities so it's not allowed to interact with the kernel at all. Setting CPU limit to be 1 also prevents DOS attacks internally. I also run the process under the nobody user which entirely avoids the "container root is system root" issue. I'm also only sort of running "untrusted" code. I'm running tensorflow models which can do arbitrary computation but are more secure than just running raw code.