Zero Trust

A developer's own access is to your Kubernetes cluster — ordinary namespace-scoped RBAC, the same kind your platform team already manages, nothing 00DB-specific to learn. The RBAC this product actually needs is narrow on purpose: a Role scoped to one namespace, granting only create, get, list, watch, and delete on Pods — no other resource type. A sandbox itself is a pod running inside that cluster, and it's that pod — not a developer's laptop, not a CI runner — that opens the network connection to your production database. See Kubernetes Install Guide for exactly what this RBAC looks like.

This is a claim about network path, not about credentials: whoever configures a data source still has to know and enter the real production database username and password, the same as SQL Simulator. 00DB doesn't remove that requirement — it removes the developer's own machine from the set of things that can reach production directly.

Configured entirely by your DBA, directly on your own source database — never through this site or through 00DB's own UI. Two DBA-owned tables, checked before every sensitive value is pulled:

• DOUBLEZERODB_CONSTRAINTS — two kinds of rule. A quota on a flagged column: how many distinct values one run can pull, and a separate cap on how many distinct values your whole team can pull per day. And a named-value block: a specific record (a public figure's row, for example) that only approved users can ever retrieve.
• DOUBLEZERODB_MASKING — per-column masking your DBA sets independently of the quotas above (redact, or randomize a numeric/text value), applied automatically when a sandbox is built.

Neither table is required — a source database without them just builds sandboxes unmasked and unaudited, same as before this feature existed. But when they're present, 00DB always checks them; this isn't something you can turn off from a tier or a setting.

Every governed pull is logged to a third table on your own database, DOUBLEZERODB_AUDIT (created automatically the first time it's needed) — constraint type, value, user, timestamp, and database name. That's what the daily team-wide cap above actually checks against, and it's a real, queryable record of who pulled what and when, on your own infrastructure.

SQL Simulator (the Docker version) structurally never reads or writes any of the three tables above, regardless of what its target database contains — it's built for non-production test data, where an unexplained quota or an unexpected audit table would be a confusing surprise, not a safeguard. If you need this governance story, that's specifically what 00DB is for; see SQL Simulator for the simpler, ungoverned alternative.