Skip to main content

Tutorial: Just-in-Time Database Access

Bytebase sits between users and databases and checks every statement against fine-grained database permissions — directly in SQL Editor, and through the change workflow for statements the user cannot run directly. There are two permission models, and one workflow built on top of them:
  1. Roles — standing access. A role bundles permissions (bb.sql.select, bb.sql.ddl, …) and is bound to a user or group, scoped to databases and environments, optionally expiring. Two ways to get one: granted or requested.
  2. Access grants — temporary elevated access. An access grant authorizes a single read-only statement on specific databases — optionally unmasked or exported — for a limited time, after approval.
  3. Just-in-Time access — the workflow that uses either model to keep standing privileges at zero: request access when needed, have it approved, let it expire. See Just-in-Time Access.
The Bytebase access model: two permission models — roles and access grants — enforced per statement, with Just-in-Time access as the workflow on top

​
Permissions

SQL Editor classifies each statement you run and checks the matching permission: For DDL and DML, the environment scope is part of the permission itself: when granting a role that carries bb.sql.ddl / bb.sql.dml, the granter selects the environments where those statements may run directly. On databases outside those environments, SQL Editor directs the user to create a database change plan and follow the change workflow instead.

​
Roles

The built-in roles carry these database permissions: Read covers bb.sql.select, bb.sql.explain, and bb.sql.info. *1 In the environments selected when granting the role. It’s still recommended to make schema and data changes through the change workflow for better traceability. Project Developer and Project Viewer carry no SQL Editor permissions — they hold bb.issues.create and make changes through the change workflow. A role reaches a member as a project-level binding that carries a scope — all databases in the project, or specific databases, schemas, and tables, plus the environments where DDL/DML run directly — and an optional expiration. A member gets a role either granted by an admin or by requesting it; role definitions and workspace IAM are covered in Roles and Permissions, where you can also build custom roles from individual permissions — e.g. a role that grants only bb.sql.explain.

​
Access grants

An access grant is the second model: a temporary, elevated privilege bound to specific resources rather than a standing capability. It authorizes exactly one read-only statement on selected databases, optionally with Unmask (see masked data in clear) or Export (download the result), and expires on its own — the clock starts at approval. Access grants exist only through approval: a member requests one from SQL Editor, an approver reviews, and every use is audited.

​
Just-in-Time access

To avoid standing privileges altogether, run access as a just-in-time workflow: members hold no default access and request it when needed — a time-boxed role for a broad range of permissions, or an access grant for a limited, elevated privilege. Both expire on their own and leave an audit trail. See Just-in-Time Access.