Leader (Vermilion controller)

[bluejekyll]

In the vermilion scheme this can be thought of as a General in the military sense. In that analogy is that the General can only issue orders, but is incapable of carrying any of them out.

Requirements:

• MUST issue commands via IPC.
• MUST cryptographically sign all messages sent
• SHOULD have a CLI tool for working with the Leader
• MUST authenticate any incoming requests (method to be determined for CLI)
• MUST support issuing: start, stop, restart, reconfigure? commands
• SHOULD support listing all current supervised processes and their status
• SHOULD run as an unprivileged process
• Will issue commands to the Supervisors and the Launcher and possibly the Logger

Questions:

• How do we authenticate CLI requests?
  • Should the CLI for the Leader be required to issue requests to the leader via the IPC?
  • If so, then users could just register their keys with vermilion and all Leader commands would be authenticated in the same way.
  • This would provide a nice way of handling remote requests (if supported)

Notes:

• IPC: event bus of vermilion
• Process: managed worker of a Supervisor
• Supervisor: manages a Process
• Logger: unprivileged log and even aggregator

[tarcieri]

MUST cryptographically sign all messages sent

As a huge fan of cryptography, and also endpoint security, but also careful threat modeling, what threats are you hoping to mitigate through the use of cryptography?

In general, "an encrypted connection to localhost" is something I believe generally fails to be helpful for mitigating threats.

[bluejekyll]

The primary thing is that I think the IPC/event bus channel will not be assumed to be trusted. If it is not, that makes it future proof to potentially supporting remote Leaders.

So the primary case I’m worried about is how do we answer this question; given an untrusted channel of communication, how would we ensure that the Leader sends messages that can be trusted by the Launcher or Supervisors that would allow them to take that action.

If we say that the IPC channel is responsible for that proof, then we should define what that proof is (is user privilege enough, how do we distinguish publishers on the event bus from one another?). And if it’s local only, then we must enforce that there can be no remote access (until that is well defined).

So the goal here for me (if you have other opinions I’m open) is that the system can be instantiated in a way where the consumers of events (Launcher/Supervisors) can verify the messages from the Leaders

Am I overthinking this?

[tarcieri]

The primary thing is that I think the IPC/event bus channel will not be assumed to be trusted. If it is not, that makes it future proof to potentially supporting remote Leaders.

If your IPC can't be trusted, I think you have the wrong IPC architecture. I had a concrete suggestion about that on the IPC thread:

https://github.com/bluejekyll/vermilion/issues/5#issuecomment-556796357