Cassandra Authorization

Authorization in Cassandra controls what authenticated users and roles are allowed to do. After confirming who you are (authentication), Cassandra checks whether you have permission to perform the requested action on the requested resource. Fine-grained authorization lets you separate read-only users, write-only services, and administrative accounts clearly.

Enabling Authorization

# cassandra.yaml
authorizer: CassandraAuthorizer

Restart Cassandra after changing this setting. The default AllowAllAuthorizer grants every authenticated user full access to everything — replace it in production.

Resources That Can Be Secured

Resource Type     Examples
──────────────────────────────────────────────────────────────
All keyspaces     ALL KEYSPACES
Keyspace          KEYSPACE ecommerce
Table             TABLE ecommerce.orders
Role              ROLE alice
Functions         FUNCTION ecommerce.my_func
Aggregates        AGGREGATE ecommerce.my_agg
MBeans            ALL MBEANS (JMX monitoring)

Permission Types

Permission    Allows
──────────────────────────────────────────────────────────────
SELECT        Read rows from tables
MODIFY        INSERT, UPDATE, DELETE, TRUNCATE on tables
ALTER         ALTER TABLE, ALTER KEYSPACE
DROP          DROP TABLE, DROP KEYSPACE
CREATE        CREATE TABLE, CREATE KEYSPACE
AUTHORIZE     GRANT/REVOKE permissions to others
DESCRIBE      View schema definitions
EXECUTE       Call user-defined functions
ALL           All permissions on the resource

GRANT — Giving Permissions

-- Allow a user to read from a specific table:
GRANT SELECT ON TABLE ecommerce.orders TO alice;

-- Allow a user to read and write to an entire keyspace:
GRANT SELECT, MODIFY ON KEYSPACE ecommerce TO app_service;

-- Grant all permissions on one table:
GRANT ALL ON TABLE ecommerce.products TO admin_user;

-- Grant all permissions on all keyspaces (superuser equivalent):
GRANT ALL ON ALL KEYSPACES TO super_admin;

-- Allow a role to grant permissions to others:
GRANT AUTHORIZE ON KEYSPACE ecommerce TO team_lead;

REVOKE — Removing Permissions

-- Remove read access:
REVOKE SELECT ON TABLE ecommerce.orders FROM alice;

-- Remove all permissions from a role on a keyspace:
REVOKE ALL ON KEYSPACE ecommerce FROM old_service;

LIST PERMISSIONS

-- View all permissions for a specific user:
LIST ALL PERMISSIONS OF alice;

 role  | username | resource          | permission
───────────────────────────────────────────────────────────
 alice | alice    | ecommerce.orders  | SELECT
 alice | alice    | ecommerce.products| SELECT

-- View all permissions on a table:
LIST ALL PERMISSIONS ON TABLE ecommerce.orders;

-- View all permissions in the cluster:
LIST ALL PERMISSIONS;

Role Hierarchy for Permission Grouping

Roles can be granted to other roles, creating permission groups similar to user groups in an operating system. Grant permissions to a role, then assign that role to many users.

-- Create permission group roles:
CREATE ROLE readonly_ecommerce;
GRANT SELECT ON KEYSPACE ecommerce TO readonly_ecommerce;

CREATE ROLE readwrite_ecommerce;
GRANT SELECT, MODIFY ON KEYSPACE ecommerce TO readwrite_ecommerce;

-- Assign roles to users (roles login-capable users):
CREATE ROLE analyst1 WITH PASSWORD = 'An@lyst1!' AND LOGIN = true;
CREATE ROLE analyst2 WITH PASSWORD = 'An@lyst2!' AND LOGIN = true;
GRANT readonly_ecommerce TO analyst1;
GRANT readonly_ecommerce TO analyst2;

CREATE ROLE data_loader WITH PASSWORD = 'L0@der!' AND LOGIN = true;
GRANT readwrite_ecommerce TO data_loader;

Permission inheritance diagram:

readwrite_ecommerce  (role: SELECT + MODIFY on ecommerce)
  └── data_loader   (inherits all ecommerce permissions) ✓

readonly_ecommerce   (role: SELECT on ecommerce)
  ├── analyst1      (inherits SELECT only) ✓
  └── analyst2      (inherits SELECT only) ✓

Granting Roles to Roles

-- Give the admin role all permissions that readonly has plus more:
GRANT readonly_ecommerce TO admin_role;
GRANT readwrite_ecommerce TO admin_role;

-- Viewing role membership:
LIST ROLES OF admin_role;

Practical Permission Design Patterns

Role Name              Permissions Granted
──────────────────────────────────────────────────────────────
app_reader             SELECT on app keyspace tables only
app_writer             SELECT + MODIFY on app keyspace tables
app_admin              ALL on app keyspace
monitoring_user        SELECT on system.* tables only
schema_admin           CREATE + ALTER + DROP on all keyspaces
superadmin             ALL on ALL KEYSPACES + AUTHORIZE

Object-Level Permissions (Table Granularity)

-- Tightly scoped: only specific tables
GRANT SELECT ON TABLE ecommerce.products TO catalog_service;
GRANT MODIFY ON TABLE ecommerce.orders   TO order_service;

-- Catalog service cannot write orders; order service cannot read products.
-- Principle of least privilege ✓

Authorization Storage and Replication

Permissions are stored in the system_auth keyspace. The same replication factor advice applies: increase it to 3 in production, and run repair after changing it.

SELECT role, resource, permissions
FROM system_auth.role_permissions;

Common Authorization Mistakes

Mistake                           Fix
──────────────────────────────────────────────────────────────
Using AllowAllAuthorizer in prod   Enable CassandraAuthorizer
Granting ALL to every service      Apply principle of least privilege
Not setting system_auth RF to 3    Node failure locks everyone out
Sharing one account across services Create one role per service
Never reviewing permissions         Audit permissions quarterly

Summary

Authorization in Cassandra controls what authenticated roles can do on which resources. Enable CassandraAuthorizer in cassandra.yaml and replace AllowAllAuthorizer in production. Use GRANT and REVOKE to assign fine-grained permissions. Build role hierarchies to group permissions cleanly and apply the principle of least privilege — each service and user should have only the access they need. Increase the system_auth replication factor and run repair to ensure permissions are available even when nodes fail.