What are people doing that use monitoring tools that require an agent to be installed? Since there is no package management in RancherOS, i’m not sure how this would work (or if it’s even intended to work).
Phillip
Run them as containers! You can use rancher to schedule the provisioning of them, then you don’t need to be messing with the OS. For example, i’ve used this to schedule Prometheus Node Exporter’s across some hosts for monitoring, you could do the same with nagios agents etc. I’d expect the agent to have some level of escalated privileges.
Just so I understand what you are saying, you are suggesting that i set up containers just for the monitoring agents? Those would have to be some OS besides RancherOS due to the aforementioned issues, and AFAIK, new relic, signal fx, app d, etc. don’t have an option for the installed agent to gather metrics form a “different” source, hence, the local installation of the agent.
And, if i need to set up containers just for monitoring, why wouldn’t i then just change my host OS to something that is supported by the previously mentioned monitoring agents?
A container is fundamentally just a (group of) process(es). There’s no reason it has to know about a “different” source, it’s just a process running in a container with net:host, privileged, bind mounts, or whatever else it needs access to. For example, the Rancher agent runs cAdvisor and provides use with stats for the host.
And you’re not “running” another OS, you just use the package management tools of Debian or whatever to get the files you need into the docker image.
I haven’t looked but would be surprised if many of those tools didn’t already have official or unofficial docker images…
This fundamentally breaks all of the security within a container if the container has access to the host and if it has access to that it will have access to the docker socket and will be allowed to affect other containers. If you can docker exec into a container because of the fact that things run as root you have now made your monitoring system the perfect target for an attacker as it has built in C&C.
Security is not magically worse because you take a hypothetical monitoring agent that requires elevated access and wrap it in a container instead of running it directly on the host. It’s the same processes. If you are in a position to exec into the container you are also in a position to just launch your own arbitrary privileged container.
I agree it is not magic, it comes from the fact that a monitoring agent would not need privileged access at all during runtime. The only reason you need privileged access at runtime as opposed to install time is because rancher does not offer a compiler or a package manager meaning you must install it into a container with privileged access. Containers are meant to isolate processes and resources. Forcing installing of software needing access to the host and by isolating host data from it you now inject a new dependency of being able to break isolation (privileged containers) which is where the security model is flawed. Not everything should be run in a container.
Again, the question was for a hypothetical abstract monitoring agent, and the only reason I even mentioned privileged is maybe the tool you’re looking at requires it. If yours just e.g. watches processes running on the host, all you need is --pid=host. If you don’t like agents that run as root, don’t run them. Putting it in a container changes nothing.
The goal of the default console in RancherOS is to be a minimal way to get Docker running on a host, and not much else. Primarily so it can be used as a Rancher host. The userspace is all busybox, little is customizable, (mostly) only container-related storage is persistent across reboots, and the expected way to run anything additional is through containers.
If you want a traditional OS, you should probably use one. Or for something in between, the alternate consoles (debian, centos, etc) provide the standard userspace tools of those distros, including their package managers.