Cassandra native transport: PasswordAuthenticator versus network-only isolation
0 reputation · 28 Apr 2024, 10:17 UTC
Goal: prevent accidental public access to the Apache Cassandra native transport port 9042 in a self-managed cluster running Cassandra 4.x.
By default, AllowAllAuthenticator is active and the transport can bind to 0.0.0.0, so an exposed interface allows unauthenticated CQL access. Two documented controls address this: enabling PasswordAuthenticator in cassandra.yaml, or relying on network-level isolation through private IP binding, firewalls, or security groups.
The trade-off is operational. Authentication requires creating a superuser role, restarting every node, and managing credentials, while older drivers without SASL support may fail. Network-only isolation avoids credential overhead but depends entirely on infrastructure rules; a single misconfigured security group can reopen the port.
It is unresolved which control should be primary when both are available and the team wants to minimize ongoing credential management without accepting exposure risk.
Should PasswordAuthenticator be mandatory even when the native transport binds only to private IP addresses? Is network isolation alone acceptable if security-group changes are reviewed before deployment?