Chapter 26 · Security: Authentication, Authorization, Roles, TLS, and Secrets

Roles, LOGIN, Permissions, GRANT / REVOKE, Role Inheritance, and Least Privilege

Design inherited least-privilege roles and prove allowed/denied CQL.

Advanced110–150 minutesLeast-privilege roles labApache Cassandra 5.0.9 · Java 17 · cqlsh/nodetool · RF=3 · LOCAL_QUORUM · UCSLast reviewed: September 2026

Learning outcomes

AtlasMart's API, support users and platform automation need different capabilities. Granting broad ALL permissions because identities are “inside the private network” turns one credential compromise into a cluster-wide incident.

01

Separate LOGIN identities from LOGIN=false entitlement roles.

02

Grant SELECT/MODIFY at the narrowest useful Cassandra resource.

03

Use role inheritance and LIST ROLES/PERMISSIONS as evidence.

04

Prove GRANT/REVOKE behavior and understand authorization caches.

05

Explain permission-granularity boundaries plus network/CIDR authorization layers.

Chapter 26 lab baseline

The mandatory work uses a separate disposable security cluster so hardening experiments cannot lock the shared course cluster. Pin Apache Cassandra 5.0.9 with the official cassandra:5.0.9 image, Java 17 from that image, Docker network atlasmart-cassandra-security, cluster atlasmart-security, nodes atlasmart-sec-1..3, datacenter dc1, racks rack1..rack3, 16 virtual nodes (vnodes) per node, NetworkTopologyStrategy, replication factor (RF) 3, and LOCAL_QUORUM for application-style verification. Tables use UnifiedCompactionStrategy (UCS), default_time_to_live=0, and gc_grace_seconds=864000.

The lab intentionally starts with Cassandra's compatible security defaults so the migration is observable: AllowAllAuthenticator, AllowAllAuthorizer, client TLS disabled, internode encryption none, and JMX local-only. No Cassandra/JMX/storage ports are published to the host. This is a local learning boundary, not a production posture. Never place a real password, token, private key, keystore password, backup key, or break-glass credential into Git, lesson HTML, screenshots, chat, shell history, or process arguments.

Execution and safety note

Run commands only against the disposable Apache Cassandra course lab or another explicitly approved non-production environment. Confirm node, keyspace, table, container, volume, path, and datacenter targets before destructive, failure-injection, cleanup, repair, restore, security, or topology operations. Capture current state and expected rollback/recovery evidence first; output and timings can differ by host, operating system, Java runtime, Docker/runtime, driver, and Cassandra configuration.

Terms before the security mechanisms

CQL is Cassandra Query Language. A coordinator is the node accepting a client request; replicas store copies of the target partition. A partition is the row group located by a partition key; its hash maps to a token. vnodes are multiple token ranges assigned per node. A keyspace defines replication. RF is replication factor and CL is consistency level. An SSTable is Cassandra's immutable on-disk table file set; compaction merges SSTables; repair compares replica ranges and streams differences. SAI is Storage-Attached Indexing. A driver is the client library speaking Cassandra's native protocol.

Authentication proves an identity; Cassandra's authenticator implements that decision. Authorization decides what an authenticated identity may do; the authorizer checks permissions on Cassandra resources. A role is Cassandra's principal/inheritance object; LOGIN=true makes it directly authenticatable. A superuser bypasses normal authorization and therefore belongs only in tightly controlled administration or break-glass recovery. Least privilege grants only the permissions needed.

TLS (Transport Layer Security) protects network traffic and authenticates endpoints with certificates. Client TLS protects application/cqlsh ↔ Cassandra native protocol; internode TLS protects Cassandra node ↔ node gossip/replication/streaming. mTLS (mutual TLS) means both sides present certificates. A keystore holds private key/certificate material and a truststore holds trust anchors. JMX (Java Management Extensions) is Cassandra's management interface used by nodetool. Defense in depth layers identity, permissions, encryption, network isolation, secrets, backups, audit, patching and recovery instead of trusting one control.

1. Role inheritance is a permission graph

Role LOGIN Permission Purpose
atlasmart_order_reader false SELECT table reusable entitlement
atlasmart_order_writer false MODIFY table reusable entitlement
atlasmart_api true reader + writer application identity
atlasmart_support true reader only human support
atlasmart_breakglass true SUPERUSER emergency administration

Role inheritance is transitive and Cassandra prevents cyclic role membership. Keeping permission bundles as non-login roles makes reviews clearer and separates credential lifecycle from entitlement lifecycle. Cassandra permissions remain resource-oriented, not arbitrary row/column business logic; table MODIFY is broader than “update status only.”

2. Create least-privilege roles

CQL · entitlement roles and grants
CREATE ROLE IF NOT EXISTS atlasmart_order_reader WITH LOGIN=false AND SUPERUSER=false;CREATE ROLE IF NOT EXISTS atlasmart_order_writer WITH LOGIN=false AND SUPERUSER=false;GRANT SELECT ON TABLE atlasmart_secure.orders_by_customer TO atlasmart_order_reader;GRANT MODIFY ON TABLE atlasmart_secure.orders_by_customer TO atlasmart_order_writer;-- Create login roles with hashes generated by hash_password; do not use these placeholders literally.CREATE ROLE IF NOT EXISTS atlasmart_apiWITH LOGIN=true AND SUPERUSER=false AND HASHED PASSWORD='<GENERATED_HASH>';CREATE ROLE IF NOT EXISTS atlasmart_supportWITH LOGIN=true AND SUPERUSER=false AND HASHED PASSWORD='<GENERATED_HASH>';GRANT atlasmart_order_reader TO atlasmart_api;GRANT atlasmart_order_writer TO atlasmart_api;GRANT atlasmart_order_reader TO atlasmart_support;LIST ROLES;LIST ALL PERMISSIONS OF atlasmart_api;LIST ALL PERMISSIONS OF atlasmart_support;

Generate distinct secrets/hashes using Lesson 1's temporary-file workflow. Capture only role/resource/permission fields needed for audit evidence; do not publish hashes unnecessarily and never publish the plaintext credentials.

3. Prove allowed and denied operations

text · expected test matrix
identity             SELECT orders    UPDATE orders    schema administrationatlasmart_api         ALLOW            ALLOW            DENYatlasmart_support     ALLOW            DENY             DENYbreak-glass           ALLOW            ALLOW            emergency-only ALLOW
bash · support-role verification without password arguments
docker exec -it atlasmart-sec-1 cqlsh -u atlasmart_support --disable-history# Inside cqlsh:# CONSISTENCY LOCAL_QUORUM;# SELECT status,total FROM atlasmart_secure.orders_by_customer# WHERE customer_id='cust-42' AND order_month='2026-09-01';# Then try the following mutation; it should return Unauthorized:# UPDATE atlasmart_secure.orders_by_customer SET status='CANCELLED'# WHERE customer_id='cust-42' AND order_month='2026-09-01'# AND order_time='2026-09-08T10:00:00Z'# AND order_id=00000000-0000-0000-0000-000000000261;
Unsafe approach: grant ALL permissions on all keyspaces to the API.

The credential can then cross unrelated data and administrative boundaries. Repair by granting only required resource/action combinations and adding negative tests to deployment/security reviews. Network privacy cannot compensate for excessive authorization.

4. Revoke, observe, and restore

CQL · controlled membership revoke
REVOKE atlasmart_order_writer FROM atlasmart_api;LIST ALL PERMISSIONS OF atlasmart_api;-- Verify mutation denial in a fresh session and observe an existing session as well.GRANT atlasmart_order_writer TO atlasmart_api;LIST ALL PERMISSIONS OF atlasmart_api;

Roles and permissions are cached. The authoritative revoke can be observed on a schedule influenced by roles_validity and permissions_validity. Security incident runbooks must test fresh and existing sessions rather than promise instant revocation without evidence.

5. Network/DC/CIDR authorization adds, not replaces, layers

Cassandra 5.0 also provides CassandraNetworkAuthorizer for datacenter access restrictions and CassandraCIDRAuthorizer for CIDR-group restrictions. When enabled, their state also depends on system_auth. The mandatory one-DC Docker lab leaves them disabled because it cannot reproduce a real enterprise perimeter; use infrastructure firewall/service-mesh/security-group controls plus Cassandra resource permissions and, where suitable, network/CIDR authorization.

Check your understanding

  1. Why use LOGIN=false group roles?
  2. Why is table MODIFY not a full business-policy boundary?
  3. What does LIST ALL PERMISSIONS prove?
  4. Why test existing sessions after revoke?
  5. What do network/CIDR authorizers add?
Review the answers

1. They separate reusable entitlements from credentials.

2. It cannot express arbitrary row/field/workflow invariants.

3. The Cassandra permission graph for that role, not TLS/network/secret controls.

4. Authorization caching can affect when the changed decision is observed.

5. DC/CIDR restrictions that complement resource authorization and infrastructure policy.

Production judgment

Security controls affect latency, availability and operator skill. Record Cassandra/JVM/driver versions, DC/racks/RF/CL, auth/TLS/JMX/network state, role inheritance, credential/certificate expiry, audit retention, backup encryption/access, patch status, repair/restore credentials and the application routing/retry/idempotency model. Re-run p50/p95/p99 latency and replica-failure tests after encryption/authorization changes. Data modeling still matters: partition/cardinality/TTL/tombstone/compaction/repair/SAI/vector choices can change sensitive-data exposure and resource-denial risk.

Do not treat a private subnet, one superuser password, client TLS or one audit stream as sufficient. Managed Cassandra may operate some server certificates, JMX, upgrades or backups, but application identities, permissions, client trust, data classification, secret use and incident response still have explicit owners. Migration/rollback must retain a tested administrative path and prevent coordinator-dependent security drift. Lesson 3 protects network confidentiality/integrity and proves client TLS and internode TLS are separate mechanisms.

Summary and next step

This lesson’s concepts, evidence path, failure boundaries, and production judgment should now be explicit enough to verify rather than assume. Re-run the check-your-understanding prompts and preserve any lab evidence you need before changing or cleaning up the environment.

Next, continue to Internode Encryption vs Client TLS: Certificates, Trust, Rotation, and Failure Modes.

Authoritative references

Security defaults, algorithms, tooling and deprecations are version-sensitive. Re-check the target Cassandra/JVM/driver distribution and organizational cryptographic policy before production rollout.

Keep knowledge open

Help the academy stay free and grow.

If these tutorials save you time, a small donation supports new lessons, technical review, diagrams, examples, and long-term maintenance.

ETHEthereum / ERC-20 only
0x716c4Ab160C4B66F31a28AE2448BfF68fc3a2ef0

Send only Ethereum or ERC-20 compatible assets to this address.