ScyllaDB access governance — every CQL statement reviewed before it runs

How AccessFlow connects

ScyllaDB and Cassandra share one plugin JAR, which registers two engine providers — the catalog matches the connector id against the engine id when it loads, so each connector resolves its own provider from the same verified binary. Both connector manifests pin that same JAR by URL and SHA-256.

One native session is cached per datasource. The contact point comes from host and port (9042 by default), a local datacenter is required by the driver's load-balancing policy, and the database name field selects the default keyspace. SSL defaults to disabled for in-cluster deployments.

What AccessFlow understands

A single CQL statement per submission. SELECT is a read; INSERT an insert, including lightweight transactions; UPDATE an update; DELETE a delete; and table, keyspace, index, type and materialized-view management plus TRUNCATE is DDL. Grants target every referenced table, bare or fully qualified.

What it refuses

BEGIN … BATCH is refused as the CQL multi-statement carrier, and creating or dropping a function or aggregate is refused as server-side code — the same two fail-closed constructs as Cassandra, for the same reasons.

Row-level security is key-aware, and fails closed

As on Cassandra, a policy is spliced into the WHERE clause only when its column is a real partition or clustering key column and its operator is one CQL can express — equality, IN, or a range comparison — with values bound as named parameters. The key columns are read from live cluster metadata rather than assumed.

Anything else is refused with HTTP 422 rather than executed unfiltered, because the alternative would be injecting ALLOW FILTERING and turning a targeted read into a full scan. An INSERT into a policied table is rejected, inserts being upserts.

What the rewrite actually does

As on Cassandra, a policy on a key column splices cleanly and anything else is refused rather than made to work with ALLOW FILTERING:

-- submitted
SELECT id, email FROM orders WHERE tenant_id = 'acme';

-- executed — region is a clustering key, so it splices
SELECT id, email FROM orders WHERE tenant_id = 'acme' AND region = :af_rls_1;

-- but a policy on a non-key column
HTTP 422 — row-level security cannot be expressed for this statement

Injecting ALLOW FILTERING would turn a targeted read into a full cluster scan, so AccessFlow refuses instead. The key columns are read from live cluster metadata, not assumed.

Introspection

The connection test runs a trivial read against the local system table, and introspection reads cluster metadata into schemas, tables and key columns — the same source the row-security applier uses, so the ER diagram shows exactly what policies can act on.

Why this is a separate connector at all

It is reasonable to ask why ScyllaDB is listed separately if it behaves identically. The answer is a catalog rule rather than a behavioural difference: the connector catalog allows one connector per dialect, and a datasource has to name the engine it is talking to. So ScyllaDB gets its own catalog entry, its own manifest and its own database type — all of which resolve to the same verified binary as Cassandra.

What is genuinely shared is everything that matters for governance: the CQL parser, the key-aware row-security applier, the field masker, introspection, and the refusals. There is no ScyllaDB-specific code path that could drift from the Cassandra one, because there is no ScyllaDB-specific code — only a second provider registration whose engine id the catalog matches when it loads the JAR.

The practical consequence is that everything documented on the Cassandra connector page is true here, including the limits. If a policy on a non-key column is refused on Cassandra, it is refused here, for the same reason and with the same message.