search

George3d6 / Inquisitor

An easily extensible, minimal footprint monitoring tool. (Still in the testing phase)
BSD 2-Clause "Simplified" License
30 stars 4 forks source link

Pushing agent configuration updates #57

Open Deedasmi opened 6 years ago

Deedasmi commented 6 years ago

Would be neat to update agent configurations remotely. Blocked on #7

George3d6 commented 6 years ago

What is the usecase for this ? How would this be implemented ?

I can see why this feature might look appealing at a glance but I think it goes against one of the main security and decoupling features of the tool (namely that agent -> receptor communication is un-directional, the receptor can't in any way influence the state of the host machine).

Deedasmi commented 6 years ago

The usecase is scaling. When I decide I want to add another check to a plugin I don't have to go touch every agent. I'm also looking at use cases where Inquisitor could be used to check for security faults, such as monitor for certain registry keys or check if a machine has available updates. There are other inherently scary use cases such as a remote task scheduler, or even a mini-ansible style system.

In theory it would be pretty easy to hide behind a feature flag, so the agent could be compiled without the ability to update.

To the security comment, this is definitely blocked until we have a proper authentication scheme set up. The obvious choice is authenticated TLS both ways, but there are PKI-style issues involved that will need to be addressed first.

George3d6 commented 6 years ago

Hmh, I think that would be over extending the project.

One of the main reasons why I wanted to start this was exactly this kind of "do 1001 things wrong instead of 1 thing right" approach for most monitoring tools. Possibly because monitoring itself isn't that hard to a task.

I wouldn't really want this tool to be used in void of other tools. So for example:

When I decide I want to add another check to a plugin I don't have to go touch every agent.

Sounds like the situation where you should use your:

a) Configuration storage & updating system (w.e it is) b) A script that rsyncs the new configs on the machine c) A script that modifies the existing configs

Again, stuff like remote task scheduling are doable, but not within the scope. There are other tools which handle deployments, job queuing, running remote scripts ... etc, the purpose of this is to integrate with them, not try to replace them.

So for example, a workflow like:

Agent ends message -> Receptor stores it -> It's content trigger a plugin (e.g. ansible plugin) that deploys stuff on a machine or makes changes to a machine ... Is perfectly valid

Stuff like:

Agent ends message -> Receptor processes message -> Receptor sends message back to agent -> Agent acts on the machine (e.g. deploys some new software)

is kind of overstepping the boundaries of monitoring.