It is not often that one runs into situations that so purely fit a classic stereotype. Securing and monitoring Docker containers happens to be one of those conundrums that is a textbook example of a “damned if you do and damned if you don’t” setup. On the surface, securing and monitoring containers seems like a straightforward affair – treat containers like mini virtual machines, and run your security/monitoring agents in each container; or, treat them like processes running on the host OS, and run your security/monitoring agents on the host OS. Sounds simple enough. However, both options run into some surprisingly natty difficulties.
Running the agent in the container
Running security/monitoring/other agents in a container immediately runs into the problem that containers are designed to run a single process (which may spawn children processes). Once we employ our typical cleverness with shell scripts to circumvent the single-process-per-container limits, we realize why that constraint was created in the first place. Containers represent modular components, and many are sourced from third parties, and thus are effectively sealed; there is no way to modify their structure. Instantiating entire security/monitoring solutions to what amounts to securing and monitoring a single process invariably ends up consuming far more resources than the process being secured/monitored. It is easy to see that this is not a practicable solution.
So, just install on the host OS…right?
Installing a security/monitoring solution on the host OS that runs all the containers seems much more promising. After all, (and (Read more...)
