cockroachdb / cockroachdb/cockroach
enforce least privilege access for shared secondary tenants
- Dominant language
- Go
- Stars
- 32.5k
- Forks
- 4.1k
- PR merge metrics
- PR metrics pending
Description
CockroachDB allow creating multiple virtual clusters, also know as "tenants". The default tenant is referred to as "system" tenant and any other user created tenants are referred to as "secondary" (or application) tenants.
Each virtual cluster can run in one of two ways:
- Shared (in-process) mode: The tenant’s SQL server runs inside the same process space as the CockroachDB node.
- External (out-of-process) mode: The tenant’s SQL server runs in its own separate process.
Regardless of mode, virtual clusters only provide the SQL layer and never store data themselves.
To create and start a virtual cluster in shared mode, run the following SQL statements from "system" tenant:
```
CREATE VIRTUAL CLUSTER test;
ALTER VIRTUAL CLUSTER test START SERVICE SHARED;
```
By default, secondary tenants can only access their own data and metadata. To view any non-tenant-specific metadata, they must be granted additional capabilities. For example, `can_view_node_info` capability allows a secondary tenant to read "node" metadata. External tenants are created without these capabilities, whereas internal tenants are created with all of them by default. This ticket proposes to revisit that decision and create shared secondary tenants also without any additional privileges by default and to provide a mechanism with which privileges users can grant those additional privileges to virtual clusters.
Jira issue: CRDB-50430
Contributor guide
Assessment
This issue has not been assessed yet.