Access Control
Authorization
Control what users can do - Implement fine-grained permissions!
🔍 What is Authorization?
Authorization controls WHAT you can do - like having different keys for different doors!
Remember the Difference:
# AUTHENTICATION: "WHO are you?"
$ cqlsh -u alice -p "password"
Connected! ← Identity verified ✅
# AUTHORIZATION: "WHAT can you do?"
cqlsh> SELECT * FROM users;
Unauthorized: User alice has no SELECT permission ← Access denied ❌
The Problem Without Authorization:
# With authentication but NO authorization:
# Every user can do EVERYTHING!
# Junior developer alice logs in
$ cqlsh -u alice -p "password"
Connected!
# Can drop production keyspace! 😱
cqlsh> DROP KEYSPACE production;
Applied ← DISASTER!
# Can read sensitive data!
cqlsh> SELECT * FROM credit_cards;
← Security breach!
With Authorization Enabled:
# alice has limited permissions
$ cqlsh -u alice -p "password"
# Can only SELECT from allowed tables
cqlsh> SELECT * FROM analytics.reports;
← Allowed! ✅
# Cannot drop anything
cqlsh> DROP KEYSPACE production;
Unauthorized: User alice has no DROP permission
← Blocked! ✅
# Cannot read sensitive data
cqlsh> SELECT * FROM credit_cards;
Unauthorized: User alice has no SELECT permission on
← Protected! ✅
| Permission | What It Allows | Example |
|---|---|---|
SELECT |
Read data from tables | SELECT * FROM users; |
MODIFY |
Insert, update, delete data | INSERT INTO users ...; UPDATE users ...; DELETE FROM users ...; |
Schema Permissions
| Permission | What It Allows | Example |
|---|---|---|
CREATE |
Create keyspaces, tables, indexes | CREATE KEYSPACE ...; CREATE TABLE ...; |
ALTER |
Modify keyspaces, tables | ALTER TABLE users ADD email text; |
DROP |
Delete keyspaces, tables | DROP TABLE users; |
Execution Permissions
| Permission | What It Allows | Example |
|---|---|---|
EXECUTE |
Execute user-defined functions | SELECT my_udf(col) FROM table; |
Role Management Permissions
| Permission | What It Allows | Example |
|---|---|---|
AUTHORIZE |
Grant/revoke permissions | GRANT SELECT ON users TO alice; |
DESCRIBE |
View permissions | LIST ALL PERMISSIONS; |
Special Permission
ALL PERMISSIONS grants all of the above permissions at once!
# Grant everything at keyspace level
GRANT ALL PERMISSIONS ON KEYSPACE my_keyspace TO alice;
# Equivalent to granting:
GRANT SELECT, MODIFY, CREATE, ALTER, DROP, AUTHORIZE
ON KEYSPACE my_keyspace TO alice;
⚡ GRANT & REVOKE Commands
Complete permission management!
Granting Permissions
# ===== KEYSPACE-LEVEL PERMISSIONS =====
# Grant SELECT on entire keyspace
GRANT SELECT ON KEYSPACE analytics TO alice;
← alice can read ALL tables in analytics keyspace
# Grant multiple permissions
GRANT SELECT, MODIFY ON KEYSPACE analytics TO bob;
← bob can read and write to analytics
# Grant all permissions on keyspace
GRANT ALL PERMISSIONS ON KEYSPACE analytics TO admin_user;
← admin_user has full control over analytics
# ===== TABLE-LEVEL PERMISSIONS =====
# Grant SELECT on specific table
GRANT SELECT ON analytics.reports TO alice;
← alice can only read reports table
# Grant MODIFY on specific table
GRANT MODIFY ON analytics.logs TO logger_app;
← logger_app can insert/update/delete in logs
# Grant CREATE (for creating tables in keyspace)
GRANT CREATE ON KEYSPACE dev_space TO developer;
← developer can create new tables in dev_space
# ===== ALL KEYSPACES =====
# Grant permission across ALL keyspaces
GRANT SELECT ON ALL KEYSPACES TO readonly_admin;
← readonly_admin can read from any keyspace
# ===== ROLE MANAGEMENT =====
# Grant permission to manage roles
GRANT AUTHORIZE ON KEYSPACE analytics TO team_lead;
← team_lead can grant/revoke permissions on analytics
# Grant permission on specific role
GRANT data_writer TO alice;
← alice inherits all permissions from data_writer role
Revoking Permissions
# ===== REVOKE PERMISSIONS =====
# Revoke SELECT from keyspace
REVOKE SELECT ON KEYSPACE analytics FROM alice;
← alice can no longer read from analytics
# Revoke multiple permissions
REVOKE SELECT, MODIFY ON KEYSPACE analytics FROM bob;
# Revoke all permissions
REVOKE ALL PERMISSIONS ON KEYSPACE analytics FROM old_user;
# Revoke from specific table
REVOKE MODIFY ON analytics.logs FROM logger_app;
# Revoke role membership
REVOKE data_writer FROM alice;
← alice loses permissions inherited from data_writer
Viewing Permissions
# List all permissions in the system
LIST ALL PERMISSIONS;
# Output:
role | username | resource | permission
-------+----------+---------------------+------------
alice | alice | | SELECT
bob | bob | | SELECT
bob | bob | | MODIFY
# List permissions for specific user
LIST ALL PERMISSIONS OF alice;
# List permissions on specific resource
LIST ALL PERMISSIONS ON KEYSPACE analytics;
# List permissions on specific table
LIST ALL PERMISSIONS ON analytics.reports;
# Check if user has specific permission
LIST ALL PERMISSIONS OF alice NORECURSIVE;
← Shows only direct permissions (not inherited from roles)
👥 Role-Based Access Control (RBAC)
Create role hierarchies for easier management!
Why Use Roles?
Instead of granting permissions to each user individually, create roles with permissions and assign users to roles!
- ✅ Easier management: Grant permissions once to role, add users to role
- ✅ Consistency: All users in role have same permissions
- ✅ Scalability: Add new users easily by assigning role
- ✅ Role hierarchies: Roles can inherit from other roles
Creating Role Hierarchy
# ===== STEP 1: CREATE BASE ROLES =====
# Read-only role (can only SELECT)
CREATE ROLE readonly WITH LOGIN = false;
GRANT SELECT ON KEYSPACE analytics TO readonly;
# Data writer role (can SELECT and MODIFY)
CREATE ROLE data_writer WITH LOGIN = false;
GRANT SELECT, MODIFY ON KEYSPACE analytics TO data_writer;
# Admin role (full control)
CREATE ROLE admin_role WITH LOGIN = false;
GRANT ALL PERMISSIONS ON KEYSPACE analytics TO admin_role;
# ===== STEP 2: CREATE USERS =====
# Junior analyst (read-only)
CREATE ROLE alice WITH PASSWORD = 'alice_pass' AND LOGIN = true;
# Senior engineer (can write data)
CREATE ROLE bob WITH PASSWORD = 'bob_pass' AND LOGIN = true;
# Team lead (admin access)
CREATE ROLE charlie WITH PASSWORD = 'charlie_pass' AND LOGIN = true;
# ===== STEP 3: ASSIGN ROLES TO USERS =====
GRANT readonly TO alice;
← alice inherits SELECT permission from readonly role
GRANT data_writer TO bob;
← bob inherits SELECT + MODIFY from data_writer role
GRANT admin_role TO charlie;
← charlie inherits ALL PERMISSIONS from admin_role
# ===== RESULT: Easy Permission Management! =====
# Want to add new junior analyst?
CREATE ROLE diana WITH PASSWORD = 'diana_pass' AND LOGIN = true;
GRANT readonly TO diana;
← Done! Diana automatically gets readonly permissions
# Promote alice to data writer?
REVOKE readonly FROM alice;
GRANT data_writer TO alice;
← Alice now has write access!
Advanced: Nested Roles
# Roles can inherit from other roles!
# Base role: Can read users table
CREATE ROLE user_reader WITH LOGIN = false;
GRANT SELECT ON app.users TO user_reader;
# Extended role: Can read AND write users
CREATE ROLE user_manager WITH LOGIN = false;
GRANT user_reader TO user_manager; ← Inherit SELECT from user_reader
GRANT MODIFY ON app.users TO user_manager; ← Add MODIFY
# Top role: Full control
CREATE ROLE user_admin WITH LOGIN = false;
GRANT user_manager TO user_admin; ← Inherit SELECT + MODIFY
GRANT DROP, ALTER ON app.users TO user_admin; ← Add DROP + ALTER
# Assign to users
CREATE ROLE eve WITH PASSWORD = 'eve_pass' AND LOGIN = true;
GRANT user_admin TO eve;
# eve now has: SELECT, MODIFY, DROP, ALTER on app.users!
# (Inherited through role hierarchy)
Viewing Role Hierarchy
# List all roles
LIST ROLES;
# See what roles a user has
LIST ROLES OF alice;
# Output:
role | super | login | options
----------+-------+-------+---------
alice | False | True | {}
readonly | False | False | {}
← alice has readonly role
# See all permissions (including inherited)
LIST ALL PERMISSIONS OF alice;
← Shows permissions from alice AND from readonly role
💼 Real-World Authorization Scenarios
Complete permission setups!
Scenario 1: E-Commerce Application
# Context: E-commerce with different services
# Services: web_frontend, order_service, inventory_service, analytics
# ===== STEP 1: CREATE KEYSPACES =====
CREATE KEYSPACE ecommerce WITH replication = {
'class': 'NetworkTopologyStrategy', 'dc1': '3'
};
USE ecommerce;
CREATE TABLE users (...);
CREATE TABLE orders (...);
CREATE TABLE inventory (...);
CREATE TABLE analytics_events (...);
# ===== STEP 2: CREATE SERVICE ROLES =====
# Web frontend: Read users, create orders
CREATE ROLE web_frontend
WITH PASSWORD = 'web_secret_key' AND LOGIN = true;
GRANT SELECT ON ecommerce.users TO web_frontend;
GRANT SELECT, MODIFY ON ecommerce.orders TO web_frontend;
GRANT SELECT ON ecommerce.inventory TO web_frontend;
# Order service: Full access to orders
CREATE ROLE order_service
WITH PASSWORD = 'order_secret_key' AND LOGIN = true;
GRANT SELECT, MODIFY ON ecommerce.orders TO order_service;
GRANT SELECT, MODIFY ON ecommerce.inventory TO order_service;
# Inventory service: Manage inventory
CREATE ROLE inventory_service
WITH PASSWORD = 'inventory_secret_key' AND LOGIN = true;
GRANT SELECT, MODIFY ON ecommerce.inventory TO inventory_service;
# Analytics: Read-only access to everything
CREATE ROLE analytics_service
WITH PASSWORD = 'analytics_secret_key' AND LOGIN = true;
GRANT SELECT ON KEYSPACE ecommerce TO analytics_service;
GRANT MODIFY ON ecommerce.analytics_events TO analytics_service;
# ===== STEP 3: VERIFY PERMISSIONS =====
LIST ALL PERMISSIONS;
# Result: Each service has exactly what it needs!
# - web_frontend: Can't modify inventory directly
# - order_service: Can't access users
# - inventory_service: Can't access orders
# - analytics: Read-only, except can write events
Scenario 2: Data Team Hierarchy
# Context: Data team with different seniority levels
# Team: Interns, Junior Analysts, Senior Analysts, Data Engineers, Team Lead
# ===== CREATE KEYSPACE =====
CREATE KEYSPACE data_warehouse WITH replication = {
'class': 'NetworkTopologyStrategy', 'dc1': '3'
};
USE data_warehouse;
CREATE TABLE raw_data (...);
CREATE TABLE processed_data (...);
CREATE TABLE reports (...);
# ===== CREATE ROLE HIERARCHY =====
# Level 1: Interns (read reports only)
CREATE ROLE intern_role WITH LOGIN = false;
GRANT SELECT ON data_warehouse.reports TO intern_role;
# Level 2: Junior Analyst (read all, write reports)
CREATE ROLE junior_analyst WITH LOGIN = false;
GRANT intern_role TO junior_analyst; ← Inherit intern permissions
GRANT SELECT ON data_warehouse.raw_data TO junior_analyst;
GRANT SELECT ON data_warehouse.processed_data TO junior_analyst;
GRANT MODIFY ON data_warehouse.reports TO junior_analyst;
# Level 3: Senior Analyst (read all, write processed + reports)
CREATE ROLE senior_analyst WITH LOGIN = false;
GRANT junior_analyst TO senior_analyst; ← Inherit junior permissions
GRANT MODIFY ON data_warehouse.processed_data TO senior_analyst;
# Level 4: Data Engineer (full data access)
CREATE ROLE data_engineer WITH LOGIN = false;
GRANT senior_analyst TO data_engineer; ← Inherit senior permissions
GRANT MODIFY ON data_warehouse.raw_data TO data_engineer;
GRANT CREATE, ALTER ON KEYSPACE data_warehouse TO data_engineer;
# Level 5: Team Lead (full control)
CREATE ROLE team_lead WITH LOGIN = false;
GRANT data_engineer TO team_lead; ← Inherit engineer permissions
GRANT ALL PERMISSIONS ON KEYSPACE data_warehouse TO team_lead;
# ===== ASSIGN USERS TO ROLES =====
# Interns
CREATE ROLE intern_alice WITH PASSWORD = 'pass1' AND LOGIN = true;
GRANT intern_role TO intern_alice;
# Junior Analysts
CREATE ROLE analyst_bob WITH PASSWORD = 'pass2' AND LOGIN = true;
GRANT junior_analyst TO analyst_bob;
# Senior Analysts
CREATE ROLE senior_carol WITH PASSWORD = 'pass3' AND LOGIN = true;
GRANT senior_analyst TO senior_carol;
# Data Engineers
CREATE ROLE engineer_dave WITH PASSWORD = 'pass4' AND LOGIN = true;
GRANT data_engineer TO engineer_dave;
# Team Lead
CREATE ROLE lead_eve WITH PASSWORD = 'pass5' AND LOGIN = true;
GRANT team_lead TO lead_eve;
# ===== PROMOTION EXAMPLE =====
# Bob gets promoted from Junior to Senior Analyst
REVOKE junior_analyst FROM analyst_bob;
GRANT senior_analyst TO analyst_bob;
← Bob now has senior permissions! Easy!
Scenario 3: Emergency - Revoking Compromised User
# EMERGENCY: User 'alice' credentials compromised!
# Need to immediately revoke all access
# STEP 1: Disable login immediately
$ cqlsh -u cassandra -p "admin_password"
cqlsh> ALTER ROLE alice WITH LOGIN = false;
← alice can no longer connect!
# Test: alice tries to connect
$ cqlsh -u alice -p "password"
Authentication failed ← Blocked! ✅
# STEP 2: Check what permissions alice had
cqlsh> LIST ALL PERMISSIONS OF alice;
# Output:
role | resource | permission
-------+---------------------+------------
alice | | SELECT
alice | | MODIFY
# STEP 3: Revoke all permissions
cqlsh> REVOKE ALL PERMISSIONS ON KEYSPACE analytics FROM alice;
# STEP 4: Create new user with same role
cqlsh> CREATE ROLE alice_new
WITH PASSWORD = 'new_secure_password_xyz'
AND LOGIN = true;
GRANT SELECT, MODIFY ON KEYSPACE analytics TO alice_new;
# STEP 5: Update applications
# Update app configs to use alice_new instead of alice
# STEP 6: Delete old compromised user
cqlsh> DROP ROLE alice;
# RESULT: Attacker locked out, new secure credentials in place!
🔧 Troubleshooting Authorization Issues
Fix permission problems!
❌ "Unauthorized: User has no permission"
# ERROR:
cqlsh> SELECT * FROM users;
Unauthorized: User alice has no SELECT permission on
# DIAGNOSIS: Check user's permissions
cqlsh> LIST ALL PERMISSIONS OF alice;
# Empty result → No permissions!
# FIX: Grant appropriate permission
cqlsh> GRANT SELECT ON my_keyspace.users TO alice;
# Or grant at keyspace level:
cqlsh> GRANT SELECT ON KEYSPACE my_keyspace TO alice;
# Test:
cqlsh> SELECT * FROM users;
← Works! ✅