Security Considerations

Authentication and Authorization

What do these terms mean?

  • Authentication controls who can access the cluster
  • Authentication controls what they can do on the cluster

Authentication

Cassandra supports authentication via credentials

  • By default, authentication is disabled
  • When enabled, client programs must supply a username and password

    • Example: cqlsh -u cassandra -p cassandra
    • Driver also supports authentication

Enable authentication in cassandra.yaml

  • Change the authenticator

    • The default is AllowAllAuthenticator
    • Change to PasswordAuthenticator

  • Also change the authorizer

    • The default is AllowAllAuthorizer
    • Change to CassandraAuthorizer

Example of changes

#authenticator: AllowAllAuthenticator
authenticator: PasswordAuthenticator

#authorizer: AllowAllAuthorizer
authorizer: CassandraAuthorizer

Then what do I do?

  • Restart the node(s)
  • Login as cassandra with a password of cassandra
  • The cassandra user is a superuser - has all permissions

    • Change the default cassandra password
    • ALTER USER cassandra WITH PASSWORD 'newpassword';

  • Cassadra stores the credentials in the sys_auth keyspace

    • Losing data in this keyspace could be disastrous!
    • ALTER KEYSPACE "system_auth" WITH REPLICATION = {'class' : 'NetworkTopologyStrategy', 'dc1' : 2};

Cassandra users

  • Cassandra represents users as ROLES
CREATE TABLE system_auth.roles (
    role text PRIMARY KEY,
    can_login boolean,
    is_superuser boolean,
    member_of set<text>,
    salted_hash text
)

Cassandra users

  • Note the fields in the roles table:

    • role - the role name
    • can_login - this is what separates a user from a true role
    • is_superuser - full permissions
    • member_of - roles this role has been granted
    • salted_hash - password hash

Role operations

CREATE ROLE fred WITH PASSWORD = 'Yabadabado' AND LOGIN = true;
LIST ROLES;
DROP ROLE fred;

Authentication Best Practices

  • Change the default cassandra password
  • Create a second superuser role as a back-up
  • Be sure to replicate the system_auth keyspace

Authorization

Grant permissions to roles

GRANT SELECT ON killr_video.user_by_email TO fred;

This allows user fred to perform SELECT queries on killr_video.user_by_email

Permissions

  • ALTER - ALTER KEYSPACE, ALTER TABLE, CREATE INDEX, DROP INDEX
  • AUTHORIZE - GRANT, REVOKE
  • CREATE - CREATE KEYSPACE, CREATE TABLE
  • DROP - DROP KEYSPACE, DROP TABLE
  • MODIFY - INSERT, DELETE, UPDATE, TRUNCATE
  • SELECT - SELECT

Grant roles to roles

CREATE ROLE db_accessors;
GRANT SELECT ON killr_video.user_by_email TO db_accessors;
GRANT db_accessors TO fred;

db_accessors becomes a true role that may have complex permissions

Revoke permissions

REVOKE SELECT FROM db_accessors;

This will revoke this permission from the role and all those who are granted this role

SSL

Using SSL, Cassandra encrypts cluster communication

  • Between nodes in the cluster
  • Also between clients (like cqlsh) and nodes in the cluster

How does SSL work?

ssl\SSL communicaitons

  • 1 - the client requests the certificate
  • 2 - the server sends the certificate
  • 3 - the client verifies the certificate. Normally, the client verifies using a certificate authority, but since this is self-signed, the client looks in his truststore. This is why the certificate of every node must be stored in the truststore of all the other nodes.
  • 4 - the client generates a symmetric key, encrypts the key using the servers public key (from the certificate) and sends the symmetric key to the server
  • 5 - Now, both machines share the symmetric key so they can use it to communicate securely

8 Steps for SSL set-up (node-to-node)

ssl\SSL setup

The purpose of this process is to create two artifacts that Cassandra needs; A keystore containing a signed keypair, and a truststore containing a root certificate authority (CA). Cassandra nodes present the nodes' signed certificate from the keystore to prove they are part of the cluster, and nodes will use the truststore to authenticate the presented signed certificates from other nodes.

  • 1 - Create a root certificate authority. The root authority is the head of the trust chain. We will sign all nodes' certs with this root authority and we will authorize all incoming connections using the root certificate.
  • 2 - On the same machine where you created the CA, for each node, create a keystore with a keypair. Once signed, the node will present the certificate to other nodes for authentication and will use the key to decrypt communications to other nodes.
  • 3 - We need to get the nodes' certificates signed, so (still on the same machine that has the CA) create a signing request for the nodes' certificates.
  • 4 - Sign all the nodes' certificates using the root CA key (Still on the machine with the CA).
  • 5 - For each node, import the root CA into the keystore so that the nodes' signed certificates can be imported into the each node’s keystore.
  • 6 - Now import each node’s signed certificate into the its keystore. As mentioned, we can now use this signed certificate for authenticating communications.
  • 7 - Finally, create a truststore containing the root CA cert.
  • 8 - Copy the truststore and each node’s keystore to the node’s machine. Notice that we did all the previous work on a single machine so we would not have to transfer the CA’s private key to any other machine.

SSL best practices

  • Secure the keystore - since this contains your private key
  • Set up the firewall so that only nodes can talk to each other on the listen_port
  • Protect the root CA private key - this should NOT be distributed to the nodes
  • Enable require_client_auth, otherwise programs could spoof being a node