Getting Started

Tutorial: Building with CleaveDB

Security & Access Control — Overview

In traditional database architectures, security rules and access gates are often implemented in fragile external application middleware. CleaveDB moves access control directly into the database engine through native Data-Level Security (DLS)—also referred to as Document Security Level (DSL) Policies.

The DLS security triad

GBAC

Graph-Based Access Control: Determines permissions based on relationship topology—granting read or write rights only if an entity is connected by specific graph bonds (e.g., bonded as "owner").

RBAC

Role-Based Access Control: Compares active session roles and attributes (such as my role = "admin") against document properties.

Dynamic Masking

Field-Level Redaction: Instead of hiding entire documents, conditionally redacts sensitive fields (like salaries or SSNs) based on the caller's identity.

Security command suite

CommandPurposeCanonical example
ENFORCE SECURITYDeclarative read/write policy gateENFORCE SECURITY "adm" ON docs TO ALLOW all IF my role = "admin"
MASKConditionally redact sensitive JSON fieldsMASK "salary" ON staff IF my role != "admin"
LIMITRate limiting per role per minuteLIMIT 100 QUERIES PER MINUTE FOR "viewer"
SETInject session context variablesSET role = "viewer", tenant_id = "acme"
AUTHENTICATESet active caller identityAUTHENTICATE AS "david"
DROP SECURITYRevoke or delete an existing policy ruleDROP SECURITY "adm" ON docs

Explore the Security topics

Review each guide to implement end-to-end security in CleaveDB: