Access control, or authorization, decides what an authenticated database identity is allowed to do. In ScyllaDB, permissions are attached to roles: an administrator may manage database objects, while an application role may be limited to reading and changing data in one keyspace. Authentication establishes identity; authorization permits or denies requested actions. section 9.1.5 section 10.6.2
ScyllaDB has three authorization modes. AllowAllAuthorizer, the default, permits every action. TransitionalAuthorizer supports a no-downtime migration: it enforces permissions where they exist while allowing other access. CassandraAuthorizer fully enforces permissions assigned to users and roles. Move from AllowAllAuthorizer to TransitionalAuthorizer, then to CassandraAuthorizer after permissions are configured. section 9.1.5
# Authorization backend, implementing IAuthorizer; used to limit
# access/provide permissions
# Out of the box, Scylla provides org.apache.cassandra.auth.{
# AllowAllAuthorizer,CassandraAuthorizer}.
#
# - AllowAllAuthorizer allows any action to any user - set it to
# disable authorization.
# - CassandraAuthorizer stores permissions in system_auth.permissions
# table. Please increase system_auth keyspace replication factor if
# you use this authorizer.
# - com.scylladb.auth.TransitionalAuthorizer wraps around the
# CassandraAuthorizer, using it for authorizing permission
# management. Otherwise, it allows all. Use for upgrading clusters'
# auth.
# authorizer: AllowAllAuthorizer
The authorizer setting selects whether access is unrestricted, transitional, or enforced through stored permissions. CassandraAuthorizer stores permission data in the system_auth keyspace. section 9.1.5
Enforcement must be enabled alongside authentication. Set PasswordAuthenticator and CassandraAuthorizer in scylla.yaml, copy the configuration into the running container, drain connections, and restart ScyllaDB. When using CassandraAuthorizer, set the system_auth keyspace replication factor to the cluster’s node count so authorization remains available during partial outages. section 10.6.1 section 9.1.5
Role-based access control separates an application’s needs from superuser power:
- Create a non-superuser role for a shared permission set; it has no permissions or login ability by default. section 10.6.2
- Grant narrowly scoped permissions such as SELECT or MODIFY on a keyspace. Other available actions include CREATE, ALTER, DROP, AUTHORIZE, and DESCRIBE. section 10.6.2
- Create a login-enabled role with a password for a client, then grant it the application role so it inherits those permissions. section 10.6.2
- Inspect effective grants with LIST ALL OF role to verify the permissions a role receives. section 10.6.2
Reviews API role
A reviews API needs to query and update the reviews keyspace, not administer the cluster. Create an application role, grant SELECT and MODIFY on KEYSPACE reviews, then create a login-enabled reviews_api role and grant application to it. The API can connect with its own credentials and inherits only the required data permissions. section 10.6.2 section 10.6
After access control is enabled, existing unauthenticated connections fail. Connect administrative tools as a superuser with a username and password, change the default superuser password for production use, and give applications separate credentials rather than superuser access. section 10.6.2
