> On Jun 2, 2023, at 9:06 PM, Derek Chen-Becker <de...@chen-becker.org> wrote: > > This certainly looks like a nice addition to the operator's tools for > securing cluster access. Out of curiosity, is there anything in this work > that would *preclude* a different authentication scheme for internode at some > point in the future? Has there ever been discussion of pluggability similar > to the client protocol?
This is a pluggable implementation so it's not mandatory to use it and doesn't preclude one from using a different mechanism in the future. We haven't explicitly discussed pluggability i.e. part of protocol negotiation in the past for internode connections. However, this work also does not preclude us from implementing such changes. If we do add negotiation this could be one of the authentication mechanisms. So it would be complimentary. > Also, am I correct in understanding that this would allow for multiple > certificates for the same identity (e.g. distinct cert per node)? I certainly > understand the decision to keep things simple and have all nodes share > identity from the perspective of operational simplicity, but I also don't > want to get in a situation where a single compromised node would require an > invalidation and redeployment on all nodes in the cluster. I don't recommend all nodes share the same certificate. Each node in the cluster should obtain a unique certificate with the same SPIFFE. In the event a node is compromised, the operator can revoke that node's certificate without having to redeploy to all nodes in the cluster. thanks, Dinesh
