Database Reference
In-Depth Information
INFO 16:34:20,797 Completed flushing c:\var\lib\cassandra\data\system\LocationI
fo-2-Data.db
INFO 16:34:58,159 Node /192.168.1.5 has restarted, now UP again
INFO 16:34:58,159
Node /192.168.1.5 state jump to normal
The state jump to normal for the 1.5 node indicates that it's part of the cluster again:
eben@morpheus$
bin/nodetool -host 192.168.1.5 ring
Address Status Load Range Ring
41654880048427970483049687892424207188
192.168.1.5 Up 1.71 KB 20846671262289044293293447172905883342 |<--|
192.168.1.7 Up 2 KB 41654880048427970483049687892424207188 |-->|
Security
By default, Cassandra allows any client on your network to connect to your cluster. This does not
mean that no security is set up out of the box, but rather that Cassandra is configured to use an
authentication mechanism that allows all clients, without requiring that they provide credentials.
The security mechanism is pluggable, which means that you can easily swap out one authentica-
tion method for another, or write your own.
The authenticator that's plugged in by default is the
org.apache.cassandra.auth.AllowAllAuthenticator
. If you want to force clients to
provide credentials, another alternative ships with Cassandra, the
org.apache.cassandra.auth.SimpleAuthenticator
. In this section, we see how to use this
second authenticator.
Using SimpleAuthenticator
There are two files included in the conigdirectory: access.propertiesand passwd.properties. The
access file uses a key/value pair to specify which users are allowed access to which keyspaces,
specified by a comma-separated list. The example provided looks like this:
Keyspace1=jsmith,Elvis Presley,dilbert
This indicates that there are three users allowed to access
Keyspace1
, and spaces are allowed in
the usernames.
The file passwd.propertiesmust contain a list of these users and specify the password for each of
them. Here is the example passwd.propertiesile:
jsmith=havebadpass
Elvis\ Presley=graceland4evar
dilbert=nomoovertime
