tree 5c11fb1f25eae37790ef870b1b937bfe6302674b
parent ec19b60842e905a4400e5f8b46b783a54d0a025a
author Serge Bazanski <serge@monogon.tech> 1646854416 +0100
committer Sergiusz Bazanski <serge@monogon.tech> 1646998850 +0000

m/n/core: remove local listener from curator

While working on a client library to access a cluster reliably, a
thought popped into my head:

Do we even need to run the local (UNIX domain socket) listener in the
Curator?

And, after checking all code paths, to my surprise... no, not really.
Why did we ever do it? Perhaps because we started differently structured
cluster bootstrap codebase that caused it to be a hard requirement. Or
maybe it was just a momentary lapse of reason. Regardless, with the
current codebase, it makes no sense: we always have Node credentials
available, and we run the Curator on all network interfaces. So why not
just connect over loopback and use TLS?

Here are some of the benefits of removing the local listener:

It removes a whole bunch of code, and pulling at a few more threads in
the Curator and RPC codebases will probably let us remove quite a bit
more now unused abstractions.

It leads to a more secure product, as we have one less privilege domain
socket to worry about (although we still have the etcd one... but that's
a whole different can of worms).

And most importantly, it paves the way for a vastly simplified cluster
client - one in which the transport is the same regardless of whether we
connect to a local or remote curator. This should let us use bog
standard gRPC load balancing / resolving extensions to reach the Curator
in an idiomatic and robust way.

Change-Id: I1fe9b04ba3b5f4e001050c25aec61a761077492f
Reviewed-on: https://review.monogon.dev/c/monogon/+/624
Reviewed-by: Mateusz Zalega <mateusz@monogon.tech>