Apache Cassandra Security Model

Infrastructure Operators / Administrators: Users with OS-level access to nodes running Cassandra. They have access to configuration files (cassandra.yaml, cassandra-env.sh), data directories, JMX interfaces, and can start/stop nodes. These users are fully trusted. It is the responsibility of the organization to restrict who holds this role guided by the principle of least privilege.

Database Administrators (Superusers): Users with Cassandra superuser roles. They can create/alter/drop roles, keyspaces, and tables, and grant/revoke permissions. They are trusted within the CQL authorization model but should not require OS-level access.

Application Developers: Users who write applications that connect to Cassandra. They are trusted to use the CQL API correctly, construct safe queries, and manage credentials securely within their applications.

Database Users (Non-superuser Roles): Authenticated users with limited, explicitly granted permissions. They are not trusted beyond the permissions assigned to their role. The authorization subsystem (CassandraAuthorizer) enforces their access boundaries.

Unauthenticated Network Actors: Any party with network access to Cassandra’s client or inter-node ports who has not authenticated. Under this threat model’s assumed configuration, all communication channels require authentication and TLS, and JMX is bound to localhost only, so unauthenticated connection attempts are rejected. These actors remain a threat only if they can exploit vulnerabilities in the TLS handshake, authentication protocol, or network stack itself.

External Clients and End Users: Users of applications that interact with Cassandra indirectly. Their input should never be trusted by the application layer and must be validated before being passed to CQL queries.

Configuration files (cassandra.yaml, cassandra-env.sh, cassandra-rackdc.properties, jmxremote.password): These control all security-critical behavior including encryption, authentication, and authorization settings. Deployers must ensure that untrusted parties do not have write access to these files and that they are transmitted only over confidential channels.

System keyspaces (system_auth, system_schema, system): These internal tables store authentication credentials, role definitions, permissions, and schema metadata. Cassandra trusts their contents. Deployers must ensure the system_auth keyspace has adequate replication (recommended: RF 3-5 per datacenter) and that direct manipulation via tools like sstableloader is restricted to trusted operators.

JMX interface: Operations performed through JMX are trusted to be legitimate administrative actions. JMX is bound to the local interface only, secured with Cassandra integrated authentication and authorization, and configured with fine-grained MBean permissions. Deployers must maintain these controls and audit JMX access.

Environment variables and JVM system properties: These configure security-critical behaviors such as SSL keystore paths, JMX settings, and JAAS configuration. Deployers must protect the execution environment.

SSL/TLS key material: Keystores, truststores, and PEM files used for client-to-node, node-to-node, and JMX encryption. Deployers must protect these files with appropriate filesystem permissions and manage certificate lifecycle (Cassandra supports hot reloading of SSL certificates).

Pluggable extension points, service provider interfaces (SPIs), and operator-supplied JARs: Cassandra exposes numerous extension points that operators select via cassandra.yaml or that are discovered from the classpath at startup. Examples include authentication and authorization plugins (IAuthenticator, IAuthorizer, INetworkAuthorizer, IRoleManager, IInternodeAuthenticator, ICIDRAuthorizer), topology, partitioning, and seed selection (IEndpointSnitch, IPartitioner, ISeedProvider), TLS material providers (ISslContextFactory), storage and data-path components (ICompressor, SSTableFormat.Factory), audit and startup hooks (IAuditLogger, StartupCheck), per-table triggers (ITrigger), CQL constraint providers (ConstraintProvider), and any other interface or java.util.ServiceLoader SPI that Cassandra resolves at runtime. User-defined functions and aggregates loaded as Java code, and any other JAR placed on the Cassandra classpath (including the triggers/ directory) fall in the same category. These implementations run in-process with the full privileges of the Cassandra JVM and can invoke any Cassandra internal, read or modify any data the process can access, and observe any in-memory state. The Apache Cassandra project does not control the security properties of third-party implementations and cannot make guarantees about them. Deployers are responsible for sourcing such components only from trusted vendors, reviewing or auditing their behavior, restricting who can publish JARs to a node’s classpath or trigger/UDF directories, and treating them with the same care as the Cassandra distribution itself.

CQL queries from client connections: All client requests are subject to authentication and authorization checks. Either PasswordAuthenticator, MutualTlsWithPasswordFallbackAuthenticator, or MutualTlsAuthenticator is active alongside CassandraAuthorizer, and all connections require TLS. Applications should use parameterized queries and never interpolate untrusted input directly into CQL strings.

Data content written by clients: Cassandra does not validate or sanitize the content of data written to user tables. It is the application’s responsibility to validate data before writing.

Inter-node messages from unauthorized sources: With inter-node encryption (internode_encryption: all) and mutual TLS active, unauthorized nodes cannot join the cluster or inject traffic. The residual threat is exploitation of vulnerabilities in the TLS implementation or certificate validation logic.

Compromised or weak credentials allowing an attacker to authenticate as a legitimate user

Exploiting overly permissive role grants that expose data beyond intended scope

Direct access to SSTable files on disk, bypassing CQL-level access controls

Exploiting vulnerabilities in the authentication or authorization subsystem to bypass access checks

Compromised JMX credentials exposing data through MBean operations

Authentication: PasswordAuthenticator, MutualTlsWithPasswordFallbackAuthenticator, or MutualTlsAuthenticator is active; the default cassandra superuser account has been disabled and replaced with a dedicated superuser. All client connections must authenticate via credentials or mutual TLS client certificates.

Authorization: CassandraAuthorizer enforces role-based access control with keyspace and table-level permissions via GRANT/REVOKE. Permissions follow an allowlist model (no access unless explicitly granted).

File System Permissions: OS-level access to data directories, commit logs, and saved caches is restricted to the Cassandra process user. Where the Apache Cassandra Sidecar (control plane) is deployed alongside a node, it shares filesystem access with the Cassandra process for operations such as bulk import/export (data directories), CDC consumption (commit log directory), and live data migration. The Sidecar process is treated as a co-located trusted component subject to the same operator-level protections as the Cassandra process itself.

JMX Authentication: JMX is bound to the local interface only (LOCAL_JMX=yes), eliminating remote JMX attack surface. Cassandra integrated auth (CassandraLogin JAAS config) provides authentication even for local access.

Inter-node Encryption: server_encryption_options with internode_encryption: all and mutual TLS prevents unauthorized cluster participants.

Credential theft or brute-force attacks against authenticated accounts

Privilege creep through accumulated role grants over time

Compromise of an infrastructure operator who has OS-level access to data files

Exploiting vulnerabilities in the TLS implementation or cipher suite negotiation

Compromised or weak certificates enabling man-in-the-middle attacks

Exploiting certificate validation flaws during SSL hot reloading

Attacks against the certificate authority or key material

Client-to-Node Encryption: client_encryption_options is configured with enabled: true and optional: false, requiring TLS for all client connections.

Node-to-Node Encryption: server_encryption_options is configured with internode_encryption: all and mutual TLS certificate validation.

JMX Localhost Binding: JMX is bound to the local interface only (LOCAL_JMX=yes), so JMX traffic does not traverse the network. This eliminates the risk of JMX data-in-transit interception without requiring JMX SSL.

Certificate Management: CA-signed certificates are used with properly configured truststores for mutual authentication. Cassandra’s SSL certificate hot reloading (polling every 10 minutes, or triggered via nodetool reloadssl) supports certificate rotation without downtime.

FIPS Compliance: Where required, FIPS-compliant settings are configured at the JVM level.

Compromise of private key material or certificate authority

Vulnerabilities in JVM TLS implementation (e.g., protocol downgrade attacks)

Brief window during certificate rotation where old/new certificates coexist

Authenticated users exploiting overly broad MODIFY permissions to alter data outside their intended scope

Direct manipulation of SSTable files on disk by a compromised OS-level account

Use of offline tools (sstableloader, sstablescrub) by a compromised operator to overwrite system or user tables

Exploiting vulnerabilities in the authorization subsystem to bypass write restrictions

Fine-grained Authorization: MODIFY permissions are granted only to roles that require write access, scoped to specific keyspaces and tables.

Audit Logging: Audit logging is enabled for security-relevant categories that strike a balance between compliance and scalability on large systems. The recommended categories to include are AUTH, DCL, DDL, ERROR, OTHER, which captures authentication events, data control language (GRANT/REVOKE), data definition language (schema changes), errors, and other administrative operations. Capturing every DML (data modification) statement is generally not tenable at scale; deployers may opt in to DML auditing for specific keyspaces or roles where regulatory requirements demand it.

File System Permissions: SSTable files, commit logs, and hints are protected with restrictive OS-level permissions. Access to sstableloader and other offline tools is restricted to trusted operators or the control plane process (i.e. Cassandra Sidecar).

Inter-node Authentication: Mutual TLS on inter-node channels prevents unauthorized nodes from joining the cluster and injecting data.

A compromised infrastructure operator can bypass all CQL-level access controls via direct file manipulation

Application-level logic errors that allow authenticated users to write unintended data within their granted permissions

Application-level Integrity (developer responsibility): Implement checksums or application-level signatures where data integrity guarantees beyond Cassandra’s internal mechanisms are required

Authenticated users executing resource-exhaustive queries (full table scans, unbounded reads, excessive tombstone reads)

Authenticated users opening excessive connections to exhaust connection pools

Compromised JMX credentials used to trigger disruptive operations (e.g., compaction, repair on overloaded nodes) — requires local access to the node since JMX is localhost-bound

TLS handshake abuse to exhaust CPU resources on client or inter-node ports

Network-level flooding against gossip or native transport ports (infrastructure-layer attack)

Authentication Barrier: All client connections must authenticate, preventing anonymous abuse. TLS is required, raising the cost of connection flooding.

Rate Limiting: Client connection limits and native transport request throttling are configured.

Resource Limits: Read/write request timeouts, query result size limits, and tombstone thresholds are set in cassandra.yaml.

JMX Security: JMX is bound to the local interface only, eliminating remote JMX attack surface. Local JMX access is secured with Cassandra integrated auth.

Network Security: Firewalls and network segmentation are in place. All non-essential ports are closed.

Monitoring and Alerting: Unusual traffic patterns, query latency spikes, and resource exhaustion conditions are monitored.

Authenticated users with legitimate credentials can still craft expensive queries within their permissions

TLS handshake cost amplification from unauthenticated network actors

Query Best Practices (developer responsibility): Use prepared statements, avoid ALLOW FILTERING in production, set appropriate page sizes, and ensure queries are partition-aware

Exploiting overly permissive role grants that accumulate over time (privilege creep)

Credential theft targeting superuser or DBA accounts

Exploiting vulnerabilities in the CassandraAuthorizer, PasswordAuthenticator, MutualTlsWithPasswordFallbackAuthenticator or MutualTlsAuthenticator to bypass access checks

Exploiting inconsistencies between CQL authorization and JMX authorization scopes

Exploiting role hierarchy (GRANT role TO role) to gain unintended transitive permissions

Default Superuser Disabled: The default cassandra role has been removed or disabled (ALTER ROLE cassandra WITH SUPERUSER = false AND LOGIN = false) and replaced with a dedicated superuser. When PasswordAuthenticator (or the password fallback path of MutualTlsWithPasswordFallbackAuthenticator) is in use, the dedicated superuser is protected by a strong password. When MutualTlsAuthenticator is in use, the dedicated superuser is a passwordless role bound to a specific administrative mTLS identity (client certificate) via the configured certificate-to-role mapping; password-based login is not required and is not the only acceptable hardening for the superuser role.

Principle of Least Privilege: Permissions are granted at the minimum necessary scope using GRANT statements scoped to specific keyspaces, tables, or MBeans.

Role Separation: Administrative (superuser), operational (JMX), and application roles are separated. Cassandra’s role hierarchy (GRANT role TO role) is used to manage permissions cleanly.

Unified JMX Authorization: Cassandra integrated JMX auth (CassandraLogin JAAS config
AuthorizationProxy) unifies CQL and JMX access control with fine-grained MBean permissions.

Inter-node Encryption: Mutual TLS prevents unauthorized manipulation of system_auth tables via crafted inter-node messages.

Privilege creep if role grants are not periodically audited (LIST ALL PERMISSIONS)

Compromise of a superuser account grants full cluster control

Complex role hierarchies may create unintended transitive permission paths

Authenticated users with overly broad permissions reading system_auth tables (role definitions, hashed credentials, permission grants) or other deployment-restricted resources

Compromised JMX credentials exposing configuration details, memory state, and operational metrics beyond intended scope — requires local access to the node since JMX is localhost-bound

Log files containing sensitive information (credentials, query data, stack traces) accessible to unauthorized parties

CQL error messages revealing internal system details to authenticated non-superuser clients

Timing or error-based information leakage through CQL query responses

System Table Permissions: Access to system_auth (which stores role definitions, hashed credentials, and permission grants) is restricted — non-superusers must be explicitly granted SELECT to read it. DDL against local and replicated system keyspaces is blocked by the authorization layer regardless of grants (only replication parameters of replicated system keyspaces may be altered by sufficiently privileged users).

Schema and Topology Metadata (intentionally exposed): system_schema (schema metadata) and the topology-bearing tables in the system keyspace (local, peers_v2, size/table estimates) are readable by every authenticated user by design. Drivers and CQL tooling depend on this — for example, DESCRIBE schema; and routine driver bootstrap require it. Schema and cluster topology are therefore not treated as confidential under this model; the deployment relies on the trust placed in authenticated clients (see the Client Driver Trust Model above).

JMX Access Control: JMX is bound to the local interface only, restricting access to users with local access to the node. Fine-grained MBean permissions limit what authenticated JMX users can observe. Monitoring roles are granted only SELECT and DESCRIBE.

Log Management: Access to log files is restricted at the OS level. Production log levels are configured to avoid logging sensitive data.

Schema, keyspace/table/column names, and cluster topology are readable by every authenticated user by design; deployers must not encode sensitive information into schema identifiers and should treat that metadata as non-confidential

Authenticated users may infer data distribution through permitted query patterns

Log files may inadvertently contain sensitive data if log levels are changed during debugging

Log Hygiene (developer responsibility): Do not log credentials, authentication tokens, or sensitive user data. Document which log levels may contain sensitive information.

Error Handling (framework responsibility): Cassandra should avoid exposing internal stack traces or system details in CQL error responses to non-superuser clients.

Compromised third-party libraries included in the Cassandra distribution

Tampered distribution packages obtained from unofficial sources

Vulnerable dependencies with known CVEs

Compromised build infrastructure or release process

Verified Distribution: Cassandra is obtained from official Apache distribution channels with release signatures verified against the Apache Cassandra PMC KEYS file. Artifacts without valid signatures are not used.

Dependency Management (framework): The Apache Cassandra project checks the quality of its dependencies and monitors for known vulnerabilities.

Security Patches: Security updates are applied promptly. The Cassandra security mailing list is monitored for vulnerability announcements.

JVM Updates: The underlying JVM is kept up-to-date with security patches, as Cassandra inherits the JVM’s cryptographic and network security properties.

Zero-day vulnerabilities in dependencies that have not yet been disclosed or patched

Compromise of the Apache release infrastructure itself

Crafted CQL query strings or data values that inject log control characters

Manipulated client connection metadata (e.g., role names) appearing in log output

Exploitation of structured log format parsing through specially crafted values

Authentication Barrier: Only authenticated users can submit queries, limiting the attack surface to known identities and providing an audit trail.

Authenticated users can still inject log content through legitimate CQL operations

Structured Logging (framework responsibility): Where possible, use structured log formats (JSON, etc.) that properly escape special characters.

Log Validation (deployer responsibility): Use log aggregation systems that are resilient to injection attacks.

Input Awareness (developer responsibility): Be aware that client-supplied values may appear in Cassandra logs. Do not rely on unstructured log output for security-critical decisions.

CQL injection through string concatenation of untrusted input into queries within client applications

Exploitation of application-level query construction flaws to escalate operations within the permissions of the application’s database role

Authorization Boundary: Even if CQL injection succeeds, the injected operations are limited to the permissions of the authenticated application role. Fine-grained authorization limits the blast radius.

Audit Logging: Injected queries that fall within audited categories (e.g., authentication, DCL, DDL, errors) are captured in audit logs, supporting detection and forensic analysis. Detection of injection within DML statements requires opting in to DML auditing for the targeted scope.

Within the application role’s permissions, an attacker can read, modify, or delete any data the role has access to

Parameterized Queries (developer responsibility): Always use prepared statements with bound parameters. Never concatenate untrusted input into CQL query strings.

Input Validation (developer responsibility): Validate and sanitize all user input at the application boundary before constructing CQL queries.