Hacker News new | comments | show | ask | jobs | submit login

disclaimer: Security Engineer at Docker

It is VERY hard to do runtime detection of mining apps for two reasons:

1) it's mostly CPU usage intensive work and only if you know what's the average amount of computer power needed by your application upfront will you be able to make a policy decision on which image to stop and how to adjust Cgroups resources. If you don't, you'll have to build a reference profile of a trusted image anyway to be sure of what's the expected behavior.

2) There is no other "malicious" activity that might be reported by runtime security tools (it generally doesn't trigger anything blocked by your seccomp/LSM/filesystem-integrity profiles).

------- How to protect against this -------

The best protection is at the build chain level. There are tools out there to "bless" and/or verify an image's content/creator. Notary and Docker Trust (higher-level abstraction based on Notary inside Docker) are two tools that allow you to do:

  - key management

  - signer management

  - trust management
over Docker images.

It is crucial for people out there to make sure they only deploy trusted images and make decisions on what to run (CI or Prod) based on signature integrity of trusted images.

For a quick tutorial on Docker Trust and Notary, check this out: https://github.com/dockersamples/dcus-2018-hol/tree/master/s...

Stay safe and do not run unsigned/untrusted images!






Isn’t the real problem mentioned in this article that people are running their docker daemon unauthenticated on public endpoints? That’s not the default behavior right? So people have actually gone out of their way to make themselves insecure.

Look at the names of the containers in the article. Nobody is pulling these themselves. The problem is attackers compromising docker hosts and pulling arbitrary containers.

What safeguards does docker provide against exposing the daemon publicly, accidentally or otherwise?


The daemon is listening by default on a non-networked unix socket so if you're exposing listening on the network, you're already out of the default behavior (which is totally normal but that means that you've started regarding the instructions/doc on how to do so, and our doc page on this matter also includes security guidelines to enforce TLS verification/whitelisting daemon-side).

There is currently no "superduper-safe-mode" that enforces `--tls-verify` at the daemon-level to prevent lack of client verification/whitelisting. This can be discussed, the issue obviously being the UX (that means getting proper certs, specifying them in the config etc..).




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: