Access Control

Role Management

Master roles, permissions, and user access control!

📖 The Story: Sarah's Intern DELETE Disaster

Sarah hired a summer intern to help with data analytics. Gave the intern the SAME superuser account she used. No role management. No permission restrictions. Day 3: Intern runs DELETE query on production table to "clean up test data." Deleted 2 MILLION customer records. GONE. No backups (another mistake). $5M in lost data. Lawsuits. Sarah fired. All because intern had DELETE permission.

😱 The Accidental DELETE

Monday - Intern's First Week:

👨‍💼 Sarah creates account: intern@company.com
💥 Gives superuser role (FULL access!)
📝 Intern told to "analyze customer data"
🤷 No training on production vs dev
🔓 No restrictions - can do ANYTHING

Wednesday 2:00 PM - The Fatal Query:

-- Intern thinks they're in test environment
-- Actually in PRODUCTION! 💥

-- Intern writes query to clean up "test data":
cqlsh> DELETE FROM customers 
       WHERE created_date < '2024-01-01';

/* Query executes...
   Deleting...
   Deleting...
   2,000,000 rows deleted! ✓
*/

-- Intern thinks: "Great! Cleaned up test data!"
-- Reality: DELETED 2M PRODUCTION CUSTOMERS! 💥💥💥
                

Wednesday 2:05 PM - The Discovery:

📞 Customer service: "Customers disappeared!"
😱 Team checks database: 2M records GONE
🔍 Audit logs show: intern@company.com
💀 Check backups: NONE (budget cuts)
😭 Data is PERMANENTLY LOST

The Damage:

💰 $5M: Lost customer data value
⚖️ $2M: Lawsuits from customers
😡 2 million: Angry customers
📉 30%: Revenue drop
💼 Sarah: Fired
👨‍💼 Intern: Fired (poor kid!)
🏢 Company: Reputation destroyed

✅ With Proper Role Management

What Should Have Happened:

-- Create READ-ONLY role for analysts/interns:
CREATE ROLE analyst_readonly;

-- Grant ONLY SELECT permission:
GRANT SELECT ON KEYSPACE production_db 
TO analyst_readonly;

-- NO DELETE, NO UPDATE, NO MODIFY!

-- Create intern account with restricted role:
CREATE ROLE intern 
WITH PASSWORD = 'secure_password' 
AND LOGIN = true;

GRANT analyst_readonly TO intern;

-- Now intern tries to delete:
cqlsh> DELETE FROM customers 
       WHERE created_date < '2024-01-01';

/* Cassandra responds:
Unauthorized: 
User intern has no DELETE permission on table customers

→ DELETE BLOCKED! ✅
→ Data SAFE! ✅
*/
                

The Better Outcome:

✅ $0: No data loss
✅ 0 customers: Affected
✅ Intern: Learns from blocked query
✅ Sarah: Keeps job, promoted for good security
✅ Company: Business continues normally
✅ Lesson: Intern gets proper training

Proper roles: The difference between $7M loss and $0! 🎯

👥 What Are Roles in Cassandra?

Understand the fundamentals!

Definition

Roles are identities in Cassandra that can:

Login: Connect to the database
Own permissions: Have specific access rights
Be granted to others: Create role hierarchies
Inherit permissions: From parent roles

Two types of roles:

Login roles: Users that can connect (WITH LOGIN = true)
Non-login roles: Groups for permission management (WITH LOGIN = false)

Roles vs Traditional Users

👤

Old Way: Users

Cassandra 2.x and earlier

Users and permissions separate
No role hierarchies
Permissions per user only
Hard to manage at scale
Deprecated in 3.0+

👥

New Way: Roles

Cassandra 3.0+ (current)

Unified identity system
Role hierarchies supported
Permission inheritance
Scalable management
Industry standard (RBAC)

Role-Based Access Control (RBAC)

The RBAC Model

Instead of assigning permissions directly to users:

Create roles: Define job functions (admin, developer, analyst)
Assign permissions to roles: What each role can do
Grant roles to users: Users inherit role permissions
Change once, apply everywhere: Update role, all users affected

Result: Easier management, fewer mistakes, better security! ✅

➕ Creating and Managing Roles

Complete guide!

Create Basic Role

-- Create a login role (user):
CREATE ROLE alice 
WITH PASSWORD = 'secure_password_123'
AND LOGIN = true;

-- Create a non-login role (group):
CREATE ROLE developers
WITH LOGIN = false;

-- Create with all options:
CREATE ROLE bob
WITH PASSWORD = 'another_password'
AND LOGIN = true
AND SUPERUSER = false  ← NOT a superuser!
AND OPTIONS = {'key': 'value'};
                

Modify Existing Role

-- Change password:
ALTER ROLE alice 
WITH PASSWORD = 'new_secure_password';

-- Disable login (lock account):
ALTER ROLE bob
WITH LOGIN = false;

-- Make superuser (dangerous!):
ALTER ROLE admin_user
WITH SUPERUSER = true;

-- Remove superuser:
ALTER ROLE admin_user
WITH SUPERUSER = false;
                

Delete Role

-- Drop a role:
DROP ROLE alice;

-- Drop only if exists (no error):
DROP ROLE IF EXISTS bob;

-- IMPORTANT: Remove all permissions first!
-- IMPORTANT: Revoke from users first!
REVOKE developers FROM alice;
DROP ROLE developers;
                

List and View Roles

-- List all roles:
LIST ROLES;

/* Output:
 role         | super | login | options
--------------+-------+-------+---------
 alice        | False | True  | {}
 bob          | False | True  | {}
 cassandra    | True  | True  | {}
 developers   | False | False | {}
*/

-- List roles of specific user:
LIST ROLES OF alice;

-- Show who has a specific role:
SELECT * FROM system_auth.role_members 
WHERE role = 'developers';
                

🔐 Managing Permissions

Control what roles can do!

Available Permissions

Permission	Description	Example
CREATE	Create keyspaces or tables	CREATE KEYSPACE, CREATE TABLE
ALTER	Modify keyspaces or tables	ALTER TABLE, ALTER KEYSPACE
DROP	Delete keyspaces or tables	DROP TABLE, DROP KEYSPACE
SELECT	Read data	SELECT * FROM table
MODIFY	Write data (INSERT/UPDATE/DELETE)	INSERT, UPDATE, DELETE
AUTHORIZE	Grant/revoke permissions	GRANT SELECT TO role
DESCRIBE	View schema metadata	DESCRIBE TABLE
EXECUTE	Use functions	Call UDF/UDA

Granting Permissions

Keyspace-Level Permissions

-- Grant ALL permissions on keyspace:
GRANT ALL PERMISSIONS ON KEYSPACE production_db 
TO admin_role;

-- Grant specific permissions:
GRANT SELECT ON KEYSPACE production_db 
TO analyst_readonly;

GRANT CREATE, ALTER ON KEYSPACE production_db
TO developer_role;

-- Grant multiple permissions at once:
GRANT SELECT, MODIFY ON KEYSPACE production_db
TO application_role;
                

Table-Level Permissions

-- Grant on specific table:
GRANT SELECT ON TABLE production_db.users 
TO analyst_role;

-- Read-only access:
GRANT SELECT ON TABLE production_db.orders
TO reporting_role;

-- Full access to table:
GRANT ALL PERMISSIONS ON TABLE production_db.products
TO product_admin;

-- Write access only (no read!):
GRANT MODIFY ON TABLE production_db.logs
TO log_writer;
                

All Tables/Keyspaces

-- Grant on ALL keyspaces:
GRANT CREATE ON ALL KEYSPACES 
TO dba_role;

-- Grant on ALL tables in keyspace:
GRANT SELECT ON ALL TABLES IN KEYSPACE production_db
TO read_all_role;
                

Role Management Permissions

-- Grant role to user (role inheritance):
GRANT developer_role TO alice;

-- Grant multiple roles:
GRANT developer_role, analyst_role TO bob;

-- Grant permission to manage roles:
GRANT AUTHORIZE ON ALL KEYSPACES 
TO security_admin;
                

Revoking Permissions

-- Revoke specific permission:
REVOKE SELECT ON KEYSPACE production_db 
FROM analyst_role;

-- Revoke all permissions:
REVOKE ALL PERMISSIONS ON KEYSPACE production_db
FROM developer_role;

-- Revoke role from user:
REVOKE developer_role FROM alice;

-- Revoke table permission:
REVOKE MODIFY ON TABLE production_db.users
FROM application_role;
    

Viewing Permissions

-- List permissions for a role:
LIST ALL PERMISSIONS OF developer_role;

/* Output:
 role           | resource                    | permission
----------------+-----------------------------+------------
 developer_role |    | SELECT
 developer_role |    | MODIFY
 developer_role |    | CREATE
*/

-- List permissions on specific resource:
LIST ALL PERMISSIONS ON KEYSPACE production_db;

-- List all permissions (superuser only):
LIST ALL PERMISSIONS;
    

📊 Role Hierarchy & Inheritance

Organize roles efficiently!

How Inheritance Works

Roles can be granted to other roles, creating hierarchies:

✅ Child role inherits: All permissions from parent roles
✅ Multiple inheritance: Role can have multiple parents
✅ Transitive: Grandchild inherits from grandparent
✅ Efficient: Change parent, affects all children

Example Hierarchy

-- 1. Create base permission roles:
CREATE ROLE read_only WITH LOGIN = false;
GRANT SELECT ON ALL KEYSPACES TO read_only;

CREATE ROLE read_write WITH LOGIN = false;
GRANT SELECT, MODIFY ON ALL KEYSPACES TO read_write;

-- 2. Create department roles:
CREATE ROLE analysts WITH LOGIN = false;
GRANT read_only TO analysts;

CREATE ROLE developers WITH LOGIN = false;
GRANT read_write TO developers;
GRANT CREATE, ALTER ON ALL KEYSPACES TO developers;

CREATE ROLE dbas WITH LOGIN = false;
GRANT developers TO dbas;
GRANT DROP, AUTHORIZE ON ALL KEYSPACES TO dbas;

-- 3. Create user accounts and assign roles:
CREATE ROLE alice WITH PASSWORD = 'pass1' AND LOGIN = true;
GRANT analysts TO alice;
→ Alice inherits: SELECT on all keyspaces

CREATE ROLE bob WITH PASSWORD = 'pass2' AND LOGIN = true;
GRANT developers TO bob;
→ Bob inherits: SELECT, MODIFY, CREATE, ALTER

CREATE ROLE charlie WITH PASSWORD = 'pass3' AND LOGIN = true;
GRANT dbas TO charlie;
→ Charlie inherits: Everything from developers + DROP, AUTHORIZE

-- Result: Clear hierarchy, easy to manage!
    

Role Hierarchy Diagram

                    ┌──────────────┐
                    │   Superuser  │
                    └──────┬───────┘
                           │
            ┌──────────────┼──────────────┐
            │              │              │
       ┌────▼────┐    ┌────▼────┐   ┌────▼────┐
       │  DBAs   │    │  Devs   │   │ Analysts│
       └────┬────┘    └────┬────┘   └────┬────┘
            │              │              │
         Charlie          Bob          Alice
            │              │              │
   (All permissions) (Read/Write    (Read-only
                      + Schema)      access)

💡 Role Management Best Practices

Do it right!

✅

DO

Use principle of least privilege
Create role hierarchies
Use descriptive role names
Document role purposes
Regular access reviews
Disable unused accounts
Use non-login roles for groups
Test permissions before granting

❌

DON'T

Give everyone superuser
Share login credentials
Grant permissions directly to users
Use default cassandra account
Forget to revoke on departure
Mix dev and prod access
Grant more than needed
Skip audit logging

Principle of Least Privilege

Grant Minimum Necessary Access

Always ask: What's the MINIMUM permission needed?

Role	❌ Too Much	✅ Just Right
Analyst	MODIFY (can change data)	SELECT only (read-only)
App	ALL PERMISSIONS	SELECT + MODIFY on specific tables
Developer	SUPERUSER	CREATE, ALTER on dev keyspace only
Intern	MODIFY (Sarah's mistake!)	SELECT only + supervised

Naming Conventions

-- Use clear, descriptive names:

-- ✅ GOOD:
CREATE ROLE analyst_readonly;
CREATE ROLE app_production_readwrite;
CREATE ROLE dba_staging_full;
CREATE ROLE dev_team_schema_modify;

-- ❌ BAD:
CREATE ROLE role1;
CREATE ROLE temp;
CREATE ROLE test123;
CREATE ROLE x;

-- Naming pattern: [department]_[environment]_[access_level]
-- Examples:
#   analytics_prod_readonly
#   backend_prod_readwrite
#   devops_all_full
    

Access Review Process

Quarterly Review

List all roles and permissions
Review with team leads
Verify users still need access
Remove departed employees
Revoke unused permissions

Onboarding Process

Create account with descriptive name
Grant appropriate role (not superuser!)
Document reason for access
Set expiration for temporary access
Provide security training

Offboarding Process

-- When employee leaves:

-- 1. Disable login immediately:
ALTER ROLE departing_employee
WITH LOGIN = false;

-- 2. Revoke all roles:
REVOKE developer_role FROM departing_employee;

-- 3. After retention period, delete:
DROP ROLE departing_employee;

-- 4. Audit log for review:
SELECT * FROM system_auth.role_permissions
WHERE role = 'departing_employee';
                

🎯 Common Role Patterns

Real-world examples!

Application Roles

Service accounts for applications

-- Create app-specific role:
CREATE ROLE app_backend WITH LOGIN = false;

-- Grant only what app needs:
GRANT SELECT, MODIFY ON TABLE production.users TO app_backend;
GRANT SELECT, MODIFY ON TABLE production.orders TO app_backend;
GRANT SELECT ON TABLE production.products TO app_backend;
-- No DROP, no schema changes!

-- Create service account:
CREATE ROLE backend_service_prod
WITH PASSWORD = 'strong_generated_password'
AND LOGIN = true;

GRANT app_backend TO backend_service_prod;
            

Read-Only Analyst Role

For data analysts and BI tools

-- Create analyst role:
CREATE ROLE analyst_readonly WITH LOGIN = false;

-- Grant SELECT on all production data:
GRANT SELECT ON ALL TABLES IN KEYSPACE production
TO analyst_readonly;

-- Grant DESCRIBE (see schema):
GRANT DESCRIBE ON ALL KEYSPACES TO analyst_readonly;

-- Create individual analyst accounts:
CREATE ROLE alice_analyst
WITH PASSWORD = 'password' AND LOGIN = true;
GRANT analyst_readonly TO alice_analyst;

-- Result: Can read data, cannot modify! ✅
            

Developer Role (Non-Production)

For developers in dev/staging

-- Create developer role for dev environment:
CREATE ROLE developer_dev WITH LOGIN = false;

-- Grant full access to dev keyspaces:
GRANT ALL PERMISSIONS ON KEYSPACE dev_db 
TO developer_dev;

GRANT ALL PERMISSIONS ON KEYSPACE staging_db
TO developer_dev;

-- NO access to production!

-- Assign to developers:
CREATE ROLE bob_dev
WITH PASSWORD = 'password' AND LOGIN = true;
GRANT developer_dev TO bob_dev;
            

DBA Role

For database administrators

-- Create DBA role:
CREATE ROLE dba_role WITH LOGIN = false;

-- Grant all permissions:
GRANT ALL PERMISSIONS ON ALL KEYSPACES TO dba_role;

-- Grant role management:
GRANT AUTHORIZE ON ALL KEYSPACES TO dba_role;

-- Create DBA accounts:
CREATE ROLE dba_charlie
WITH PASSWORD = 'strong_password' 
AND LOGIN = true
AND SUPERUSER = false;  ← NOT superuser!

GRANT dba_role TO dba_charlie;

-- Note: Avoid SUPERUSER unless absolutely necessary
            

Monitoring Role

For monitoring tools (Prometheus, Grafana)

-- Create monitoring role:
CREATE ROLE monitoring WITH LOGIN = false;

-- Grant read-only to system tables:
GRANT SELECT ON ALL TABLES IN KEYSPACE system
TO monitoring;

GRANT SELECT ON ALL TABLES IN KEYSPACE system_schema
TO monitoring;

-- Create monitoring service account:
CREATE ROLE prometheus_exporter
WITH PASSWORD = 'generated_password'
AND LOGIN = true;

GRANT monitoring TO prometheus_exporter;
            

🎉 Master Role Management!

You now know how to implement proper access control!

🎓 What You Learned:

📖 Sarah's disaster: $7M loss from giving intern DELETE access
👥 What are roles: RBAC model for access control
➕ Creating roles: CREATE, ALTER, DROP, LIST commands
🔐 Permissions: GRANT/REVOKE 8 permission types
📊 Hierarchies: Role inheritance and organization
💡 Best practices: Least privilege, naming, reviews
🎯 Common patterns: 5 real-world role examples

💡 Key Takeaways:

Least privilege - Grant only minimum needed access
Use role hierarchies - Organize with parent/child roles
Never share credentials - Individual accounts for everyone
Regular reviews - Quarterly access audits
Document everything - Why each role exists
Test before granting - Verify permissions work correctly

📋 Quick Setup (Read-Only Role):

# 1. Create role
CREATE ROLE analyst_readonly WITH LOGIN = false;

# 2. Grant SELECT only
GRANT SELECT ON ALL KEYSPACES TO analyst_readonly;

# 3. Create user
CREATE ROLE intern 
WITH PASSWORD = 'secure' AND LOGIN = true;

# 4. Assign role
GRANT analyst_readonly TO intern;

# Done! Intern can read, NOT delete! ✅
        

🎯 8 Permission Types:

CREATE: Make keyspaces/tables
ALTER: Modify schema
DROP: Delete objects
SELECT: Read data

MODIFY: Insert/Update/Delete
AUTHORIZE: Grant permissions
DESCRIBE: View schema
EXECUTE: Use functions

⚠️ Sarah's Lesson:

Scenario	❌ Without Roles	✅ With Roles
Intern Access	DELETE permission	SELECT only
Result	2M records deleted	DELETE blocked
Cost	$7M loss	$0 loss
Sarah	Fired	Promoted

👥 Remember Sarah: Proper roles = $7M saved! 🎯
Implement RBAC NOW!

Responsive Ad