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
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!
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?
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..).