DynamoDB access governance — every PartiQL statement reviewed before it runs
Last updated
AccessFlow governs Amazon DynamoDB through the same submit, analyse, approve, execute pipeline as any other engine. PartiQL is SQL-shaped, so row-level security is a WHERE-clause splice — and because DynamoDB can filter on any attribute rather than only key columns, that splice is less restricted here than it is on Cassandra.
- Family
- Key-value
- Query language
- PartiQL
- Runs as
- Engine plugin (SHA-256 pinned)
- Default port
8000- Default SSL mode
REQUIRE- Install
- One-click from the connector catalog
How AccessFlow connects
It is an engine plugin rather than an in-process JDBC datasource: a standalone shaded JAR, pinned in the connector catalog by URL and SHA-256, downloaded on first use, hash-verified, and loaded into an isolated classloader. If the hash does not match, it does not load. In an air-gapped install the JAR can be pre-seeded into the driver cache and the runtime told never to reach the network. The AWS SDK is bundled with the URL-connection HTTP client rather than the default async stack, which keeps the JAR free of a second Netty and small.
DynamoDB has no host or port, so the datasource fields are remapped: the database name field holds the AWS region, which is required because the SDK needs it to sign requests even against a custom endpoint; the username is the access key id; the password is the secret access key, AES-256-GCM encrypted at rest and decrypted only when the client is constructed; and the URL override optionally points at DynamoDB Local or a VPC endpoint.
What AccessFlow understands
A submission is either a single PartiQL statement or a JSON table-management command, dispatched on the leading character. PartiQL SELECT, INSERT, UPDATE and DELETE classify as you would expect; the JSON form wraps a single create, delete or update table operation and classifies as DDL, mapping key schema, attribute definitions, billing mode and secondary indexes onto the typed control-plane request.
Grants target the table name, and an index access resolves to its base table so a policy cannot be sidestepped by querying through a secondary index.
What it refuses
Transaction and batch verbs — EXECUTE TRANSACTION and BEGIN — fail closed with HTTP 422. That is the DynamoDB counterpart of the SQL multi-statement ban: a transaction is a carrier for several operations that would have to be reviewed and audited as one, and the governance model is built around a single reviewable statement.
Multi-statement input is rejected, and anything the classifier does not recognise is refused rather than passed through.
Row-level security and masking
Unlike Cassandra, DynamoDB PartiQL can filter on any attribute — a non-key predicate simply becomes a server-side scan filter — so the splice is not restricted to key columns. Policies are ANDed into the WHERE clause with values bound as positional parameters in source order, supporting equality, inequality, the range operators, IN and NOT IN.
An empty value list is the deny-all signal, and the executor returns an empty result without calling DynamoDB at all — PartiQL has no safe constant-false predicate to splice, so short-circuiting is the correct implementation rather than a shortcut. An INSERT into a policied table is rejected, having no WHERE clause to filter.
Masking recurses by dot-path, so a rule on profile.ssn redacts that nested attribute while the rest of the map stays visible.
What the rewrite actually does
A policy restricting the Orders table to the caller's region is ANDed into the WHERE clause — and unlike Cassandra, it does not have to be a key attribute:
-- submitted SELECT id, email FROM "Orders" WHERE status = 'OPEN'; -- executed (row-security policy: Orders.region = the caller's region) SELECT id, email FROM "Orders" WHERE (status = 'OPEN') AND region = ?; -- ^ positional parameter
A non-key predicate becomes a server-side scan filter, which is why any attribute works here. A deny-all returns an empty result without calling DynamoDB at all — PartiQL has no safe constant-false predicate to splice, so short-circuiting is the correct implementation rather than a shortcut.
Introspection
The connection test lists a single table — the DynamoDB equivalent of a trivial read. Introspection lists tables, reads each key schema so the partition and sort keys are flagged as the primary key, and samples items to derive the remaining attribute names and types, since DynamoDB is schemaless beyond its keys. The schema is named for the region.