> 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. > 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. > 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. > 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!
