Apache Cassandra - Hardened NoSQL Wide-Column Database

What is Apache Cassandra

Apache Cassandra is an open-source, distributed NoSQL wide-column database built for high availability and linear scalability with no single point of failure. It runs as a JVM service on Eclipse Temurin 17 and is queried with CQL (Cassandra Query Language) over a native binary protocol on port 9042. Cassandra offers tunable consistency, a masterless peer-to-peer architecture, a partitioned wide-column data model with clustering keys, secondary indexes, materialized views, lightweight transactions, and TTL-driven compaction. Data is durably persisted to local disk as SSTables with a commit log, hints, and saved caches. CQL drivers exist for Java, Python, Node.js, Go, C# and many more. This image ships a single-node deployment, ready to scale into a cluster.

Why self-host Apache Cassandra

Running Cassandra on a VM you control keeps every row - which often carries user records, event streams, time-series telemetry and infrastructure state - inside your own tenant rather than a managed database service. Self-hosting suits teams with data residency requirements, organisations operating under GDPR or ISO 27001, and any architecture where a high-write, low-latency datastore must sit next to the workloads it serves. Cassandra is Apache-2.0, fully auditable, with no vendor lock-in - the vendor-neutral upstream distribution.

What this VM image adds

Security hardening:

• Default superuser password rotated at first boot - the upstream cassandra/cassandra superuser is replaced with a strong random password, stored in /root/cassandra-credentials.txt
• Authentication and authorization enabled - PasswordAuthenticator and CassandraAuthorizer are turned on; no anonymous access
• Native TLS required on port 9042 - client encryption is mandatory; a self-signed certificate is generated per instance at first boot
• CQL (9042) and JMX (7199) bind to localhost only - never exposed to the network by default
• UFW firewall - SSH on 22 only; 9042 is blocked externally; Azure IMDS and WireServer egress pre-configured
• fail2ban - SSH brute-force protection
• AppArmor - mandatory access control
• CVE scan - every image is scanned with Trivy before release

OS hardening (CIS Level 1):

• CIS Ubuntu 24.04 LTS Level 1 Benchmark via ansible-lockdown
• auditd for system call auditing of critical paths
• SSH hardening - PasswordAuthentication disabled, key-only access, PermitRootLogin no, LoginGraceTime 60
• Kernel hardening - SYN cookies, ASLR, rp_filter, kexec disabled, IPv6 off
• /tmp as tmpfs with nosuid, nodev, noexec

Compliance artifacts (inside the VM):

• SBOM - CycloneDX 1.6 at /etc/lynxroute/sbom.json with Cassandra pinned by version, PURL, Apache-2.0 license, supplier, and SHA-256 hash
• CIS Conformance Report at /etc/lynxroute/cis-report.html (OpenSCAP, Azure tailoring profile, 0 FAIL rules)
• Tailored CIS profile at /usr/share/doc/lynxroute/CIS_TAILORED_PROFILE.md
• Superuser credentials file at /root/cassandra-credentials.txt with the rotated password and cqlsh TLS connection steps

Quick Start

1. Deploy VM from Azure Marketplace (Standard_D2s_v3 recommended)
2. SSH: ssh -i key.pem azureuser@<PUBLIC_IP>, then sudo cat /root/cassandra-credentials.txt for the rotated superuser password
3. Connect over TLS with cqlsh: SSL_CERTFILE=/opt/cassandra/conf/cassandra-cert.pem SSL_VALIDATE=false cqlsh --ssl -u cassandra -p '<password>' 127.0.0.1 9042
4. Run CQL, e.g. CREATE KEYSPACE demo WITH replication = {'class':'SimpleStrategy','replication_factor':1};
5. Cluster admin: nodetool status

CQL (9042) and JMX (7199) bind to 127.0.0.1 only and require native TLS plus password authentication. To allow remote clients, set rpc_address/broadcast_rpc_address in /opt/cassandra/conf/cassandra.yaml, open TCP 9042 in the NSG to your client CIDR, replace the self-signed keystore with your own CA-signed certificate, and restart the service.