Jack, thank you for the link, but I'm not sure what you are referring to by Cassandra API security. If you mean TLS connection, Cassandra establishing to client and between nodes, than keystore and truststore do not seem to participate in it at all because Cassandra is using certs and keys, extracted from keystore during this connection, not those which are stored in it (that is what made me so surprised and prompted to start this discussion).
Now, TLS connection per say would be secure or not secure regardless of how you position you keys and certs. What would be important here is ciphers you use (and Cassandra is doing that) and ability to use CRL (I do not think Cassandra is doing that). Now if we are talking if positioning of certificates and keys matters for Cassandra as a system, than - of course it matters. Certificates and keys are credentials Cassandra presents during TLS, so harm is the same as leaving password in clear text. So, help me out here, what am I missing? Thanks, Oleg On Thu, Jan 14, 2016 at 6:10 PM, Jack Krupansky <jack.krupan...@gmail.com> wrote: > Cassandra is definitely assuming that you, the user, are separately > assuring that no intruder gets access to the box/root/login. The keystore > and truststore in Cassandra having nothing to do with system security, they > are solely for Cassandra API security. > > System security and Cassandra API security are two completely separate > issues. The Cassandra doc on (Cassandra, not system) security is here: > > https://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/secureIntro.html > > > > -- Jack Krupansky > > On Thu, Jan 14, 2016 at 5:49 PM, oleg yusim <olegyu...@gmail.com> wrote: > >> Jack, >> >> Thanks for your answer. I guess, I'm a little confused by general >> architecture choice. It doesn't seem to be consistent to me. I mean, if we >> are building the layer of database specific security (i.e. we are saying, >> let's assume intruder is on the box, and he is root, what we can do?), then >> it is perfectly logical to build keystore and truststore, hide our keys and >> certificates there, encrypt the file with passwords from these stores and >> keep the key of the box. That is great, and as a security architect I >> applaud this. >> >> Now, if we are saying - no, we are banking on the fact nobody will break >> into the box, and if root is lost - all bets are off, that is fine too. But >> in this case, what is the point to even have keystore and truststore? >> >> Thanks, >> >> Oleg >> >> On Thu, Jan 14, 2016 at 4:38 PM, Jack Krupansky <jack.krupan...@gmail.com >> > wrote: >> >>> The point of encryption in Cassandra is to protect data in flight >>> between the cluster and clients (or between nodes in the cluster.) The >>> presumption is that normal system network access control (e.g., remote >>> login, etc.) will preclude bad actors from directly accessing the file >>> system on a cluster node. >>> >>> -- Jack Krupansky >>> >>> On Thu, Jan 14, 2016 at 5:16 PM, oleg yusim <olegyu...@gmail.com> wrote: >>> >>>> Greetings, >>>> >>>> Guys, can you please help me to understand following: >>>> >>>> I'm reading through the way keystore and truststore are implemented, >>>> and it is all fine and great, but at the end Cassandra documentation >>>> instructing to extract all the keystore content and leave all certs and >>>> keys in a clear. >>>> >>>> Do I miss something here? Why are we doing it? What is the point to >>>> even have a keystore then? It doesn't look very secure to me... >>>> >>>> Another item - cassandra.yaml has passwords from keystore and >>>> truststore - clear text... what is the point to have these stores then, if >>>> passwords are out? >>>> >>>> Thanks, >>>> >>>> Oleg >>>> >>> >>> >> >
