Hi Dinesh, 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? 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.
Cheers, Derek On Fri, Jun 2, 2023 at 12:57 PM Dinesh Joshi <djo...@apache.org> wrote: > > 1. Is there an expectation that this would be used alongside internode > and client TLS? Would the certificates be the same, different, or is that > an implementation detail for the specific deployment to determine? > > > I am not sure what you mean by this would be used alongside internode and > client TLS? The mutual TLS authentication allows the server to authenticate > the client's identity using a client TLS certificate. The authenticators > we're adding enable this functionality. There isn't an expectation that the > same certificates be used. In fact, clients should not use the same > certificates as the internode. > > > 1. For some reason I'm having trouble understanding the internode > authentication portion of this ticket (authenticating a client with a > certificate makes sense vs just authenticating the connection). Why is this > needed on top of the connection-level TLS we have now? > > > Current connection-level TLS only secures the TLS connection. It doesn't > authenticate the peer. This adds the ability to authenticate the peer in > addition to securing the TLS connection. > > > 1. When an operator or DBA is looking to add a new identity is that > just handled as part of the new CQL statement or is there some certificate > management required on the nodes? I assume it's just the CA that needs to > be placed on the nodes to establish trust in the certificate itself then > authz happening within C* after determining the certificate can be trusted, > but want to be certain. > > > Each deployment is different so certificate management isn't scope of the > database itself. However, the operator can rotate the certificates using an > external agent and Cassandra will pick them up through SSL hot reloading. > We don't just rely on a CA trusting the client certificate, we extract the > identity from the certificate (for example: SPIFFE) and ensure that it is > allowed to access the cluster. This means someone can't just obtain a > certificate signed by a CA that Cassandra cluster trusts and connect to it. > > > 1. As a minor nit, should we include static certificates in the test > data? I see they expire in 2033 which is a fair way off, but I wonder if it > would make sense to generate the certificates as part of the test setup. > > Thanks for the feedback! > -- +---------------------------------------------------------------+ | 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 | +---------------------------------------------------------------+
