Data Security

An overview of data access controls.

Data does not leave your deployment. A DBNL Deployment is self contained and does not "call home" or send your data back to a hosted cloud service keeping your data safe, secure, and always under your control.

Location of Data

Data is split between Databases (e.g. postgres, redis, clickhouse) and an Object Store (e.g. S3, GCS).

• Databases contian:

  • Metadata (e.g. name, schema)

  • Aggregate data (e.g. summary statistics, histograms).

  • Raw traces (e.g. for OTEL Trace Ingestion)

• Object Store contains:

  • Raw data (e.g. enriched logs)

All data accesses are mediated by the API ensuring the enforcement of access controls. For more details on permissions, see Administration.

Database

Database access is always done through the API with the API enforcing access controls to ensure users only access data for which they have permission.

Object Store

Direct object store access is required to upload or download raw Run data using the SDK. Pre-signed URLs are used to provide limited direct access. This access is limited in both time and scope, ensuring only data for a specific Run is accessible and that it is only accessible for a limited time.

When uploading or downloading data for a Run, the SDK first sends a request for a pre-signed upload or download URL to the API. The API enforces access controls, returning an error if the user is missing the necessary permissions. Otherwise, it returns a pre-signed URL which the SDK then uses to upload or download the data.

Data upload

Uploading data to a Run in a given namespace requires write permission to Runs in that namespace. Downloading data from a Run in a given namespace requires read permission to Runs in that namespace.