Authorization is the process by where users are granted permissions, which entitle them to access or change data on specific keyspaces, tables, or an entire datacenter. Authorization for Scylla is done internally within Scylla and is not done with a third party such as LDAP or OAuth. Granting permissions to users requires the use of a role such as Database Administrator and requires a user who has been authenticated.
Authorization is enabled using the authorizer setting in scylla.yaml. Scylla has two authorizers available:
AllowAllAuthorizer(default setting) - which performs no checking and so effectively grants all permissions to all roles. This must be used if AllowAllAuthenticator is the configured authenticator.
CassandraAuthorizer- which implements permission management functionality and stores its data in Scylla system tables.
Once Authorization is enabled, all users must:
Permissions are modeled as a whitelist, and as such, a given role has no access to any database resource, unless specified. The implication of this is that once authorization is enabled on a node, all requests will be rejected until the required permissions have been granted. For this reason, it is strongly recommended to perform the initial setup on a node that is not processing client requests.
The following assumes that Authentication has already been enabled via the process outlined in Enable Authentication. Perform these steps to enable internal authorization across the cluster:
Configure the authorizer as CassandraAuthorizer
Set your credentials as the superuser
Login to cqlsh as the superuser and set roles and privileges for your users
Confirm users can access the client with their new credentials.
Remove Cassandra default user / passwords
It is highly recommended to perform this action on a node that is not processing client requests.
On the selected node, edit scylla.yaml to change the authorizer option to CassandraAuthorizer:
Restart the node. This will set the authorization.
CentOS 7, Ubuntu 16.04/18.04, Debian 8/9
Ubuntu 14.04, Debian 7
By default, the superuser credentials are username cassandra, password cassandra. This is not secure. It is highly advised to change this to a unique username and password combination.
Start cqlsh with the default superuser settings.
cqlsh -u cassandra -p cassandra
The cassandra user is special. When you try to login with this username, it is required to usen EACH_QUORUM consistency level(CL) for replies. On the other hand, your own user requires LOCAL_ONE consistency level. This can be a problematic in certain situations, such as adding or removing DCs. In such cases the cassandra user won’t be able to login. Creating a superuser role and assigning yourself to the role is definitely the best way forward. Refer to RBAC for an example of how to create roles and refer to Grant Authorization for information on using the grant clause.
Create a role for the superuser which has all privileges
CREATE ROLE <role-name> WITH SUPERUSER = true;
CREATE ROLE DBA WITH SUPERUSER = true;
This role already has complete read and write permissions on all tables and keyspaces and does not need to be granted anything else. The superuser permission setting is by default, disabled. Only for the administrator does it need to be enabled.
Assign that role to yourself and grant login privileges
CREATE ROLE <user> WITH PASSWORD = 'password' AND SUPERUSER = true AND LOGIN = true;
It is highly recommended to set a password when creating a role with login privileges. If you are using password authentication and you create a role with
LOGIN privileges and a blank
PASSWORD or no password, the user assigned to this role will not be able to login to the database.
For example (John is the DBA)
CREATE ROLE john WITH PASSWORD = '39fksah!' AND LOGIN = true; GRANT DBA TO john;
Exit cqlsh and login again with the new credentials
cqlsh> exit cqlsh -u new-username -p new-password
cqlsh> exit cqlsh -u john -p 39fksah!
In order for the users on your system to be able to login and perform actions, you as the DBA will have to create roles and privileges.
Before you Begin Validate you have set the authenticator as described in Authentication. Validate you have the credentials for the superuser for your system for yourself.
Open a new cqlsh session using the credentials of a role with superuser credentials. For example:
cqlsh -u dba -p 39fksah!
In this example, you are creating a user (
db_user) who can access with password (
password). You are also granting
db_user with the role named
client who has SELECT permissions on the ks.t1 table.
CREATE ROLE db_user WITH PASSWORD = 'password' AND LOGIN = true; CREATE ROLE client; GRANT SELECT ON ks.t1 TO client; GRANT client TO db_user;
Continue in this manner to grant permissions for all users.
Restart Scylla. As each node restarts and clients reconnect, the enforcement of the granted permissions will begin.
CentOS 7, Ubuntu 16.04/18.04, Debian 8/9
Ubuntu 14.04, Debian 7
The following should be noted:
Clients are not able to connect until you setup roles as users with passwords using GRANT PERMISSION statements (using the superuser). Refer to the example in Role Based Access Control (RBAC) for details.
When initiating a connection, clients will need to use the user name and password that you assign
Confirm all clients can connect before removing the Cassandra default password and user.
To remove permission from any role or user, see REVOKE PERMISSION.
To prevent others from entering with the old superuser password, you can and should delete it.
DROP ROLE [ IF EXISTS ] 'old-username';
DROP ROLE [ IF EXISTS ] 'cassandra';
- Getting Started
- Scylla for Administrators
- Administration Guide
- Scylla Security Checklist
- Enable Authentication
- Enable and Disable Authentication Without Downtime
- Generate a cqlshrc File
- Reset Authenticator Password
- Enable Authorization
- Grant Authorization CQL Reference
- Role Based Access Control (RBAC)
- Scylla Auditing Guide
- Encryption: Data in Transit Client to Node
- Encryption: Data in Transit Node to Node
- Generating a self-signed Certificate Chain Using openssl
- Encryption at Rest
- LDAP Authentication
- LDAP Authorization (Role Management)
- Admin Tools
- Scylla Manager
- Scylla Monitoring Stack
- Scylla Operator
- Upgrade Procedures
- System Configuration
- Benchmarking Scylla
- Scylla for Developers
- Scylla Cloud
- Scylla Architecture
- Troubleshooting Scylla
- Knowledge Base
- Scylla University
- Scylla FAQ
- Contribute to Scylla