Sounds great, thanks for the clarification! Cheers,
Derek On Sat, Jun 3, 2023 at 12:48 AM Dinesh Joshi <djo...@apache.org> wrote: > 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 > -- +---------------------------------------------------------------+ | Derek Chen-Becker | | GPG Key available at https://keybase.io/dchenbecker and | | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org | | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7 7F42 AFC5 AFEE 96E4 6ACC | +---------------------------------------------------------------+
