SQL Editor Data Access Control
Background
Traditional local SQL clients like DBeaver and Navicat carries security limitations that Bytebase’s centralized approach solves:
| Traditional SQL Clients | Bytebase Solution |
|---|---|
| Distributed Credentials: Stored locally in plain text, manual revocation, multiple copies | Centralized Credentials: Never leave platform, SSO authentication, directory sync, instant revocation |
| No Fine-Grained Access: All-or-nothing database access, no table/column restrictions | Granular Control: Database, schema, table-level restrictions with column masking |
| Missing Audit Trails: Zero visibility, no centralized logging, compliance violations | Complete Auditing: Every query, change, and admin action logged with full context |
| Time-Based Access Gaps: No temporary access, permanent until revoked | Just-in-Time Access: Request-based temporary access with approval workflows |
Test vs Production Setup
Below we demonstrate a two environment setup, one for test and one for production. The principle is to provide maximum security for production while keeping developer productivity for test.
DDL and DML Execution
Statement execution mode controls whether users can run DDL and DML directly in the SQL Editor at the environment level.
| Test | Prod | |
|---|---|---|
| Allow running DDL | ✅ | ❌ |
| Allow running data-modifying DML | ✅ | ❌ |
For the production environment, we disable both DDL and DML execution and require all changes to go through the approval workflow.
Fine-Grained Query
Users need to be granted explicit permissions to query the data from SQL Editor. The most straightforward way is to grant the SQL Editor User role to the user inside
the project.
- Specify
SQL Editor Useras the role. - Specify a reason.
- Grant the access to all databases in the project or fine-grained to specific databases, schemas, and tables.
- Specify an expiration date.
SQL Editor User is a built-in role that allows users to run EXPLAIN and SELECT. If you want to allow users
to run EXPLAIN only, you can create a custom role with bb.sql.explain permission.
Fine-Grained Export
Export is a special case of query access. You need to grant the Project Exporter role to the user inside the project.
Just-In-Time Access
You may disallow any production access by default and only allow temporary access on-demand. Users can this request temporary access via the SQL Editor. You will configure the custom approval policy to designate the approvers.
Audit Logging
For data privacy reasons, Bytebase does not log the actual data in the query result.
Every query is audit logged. From the audit logging view, you can see the actor, the database, the SQL statement, and the result. and the returned columns.
Summary
Below is a summary of the access control settings for the test and production environments.
| Test | Prod | |
|---|---|---|
| Allow running DDL | ✅ | ❌ |
| Allow running data-modifying DML | ✅ | ❌ |
| Fine-grained EXPLAIN, Query, Export | ✅ | ✅ |
| Just-in-Time Access | ✅ | ✅ |
| Audit Logging | ✅ | ✅ |
You can extend the solution by exploring the following features:
- Create user groups and enable directory sync to automate the role assignment.
- Configure data masking to mask sensitive data.
- Use Terraform to codify all the settings.