Skip to main content
BonData enforces authorization at the API tier on every request. Each request carries a Descope-issued JWT; the API validates the JWT, resolves it to a user record and the tenant the user belongs to, and then checks the user’s role against the action being requested.

​
Tenancy

Every request is scoped to a single tenant. Tenant isolation is enforced at the application layer: queries against the operational database and the data lake are filtered by tenant; object-storage keys are namespaced by tenant; integration credentials are stored per-tenant. A user can only ever see data belonging to the tenant they are signed in to. In Cloud-Prem, the entire deployment serves a single tenant and lives in the customer’s own AWS account, so this isolation is reinforced by physical separation.

​
Roles

Users belong to one of several roles within a tenant. Roles control which actions the user can take in the user-facing application, managing integrations, building and running agents, viewing data, inviting users, and so on. Administrative actions, provisioning tenants, managing subscriptions, viewing platform-level diagnostics, are performed in the separate management application, which uses a different Descope project. A user with management access in one application does not automatically have access in the other; access has to be granted explicitly.

​
Admin separation

The split between the user-facing application and the management application is operationally important: it means a compromised end-user account, even an administrator within a tenant, cannot reach the platform-management surface that BonData operators use. The two applications run as separate Kubernetes Deployments, behind separate Descope projects, with separate session tokens.

​
API tokens

Programmatic access uses tenant-scoped API tokens. A token carries the role of the user or service account it was issued for; the same authorization checks run on every API request whether it originated from a browser session or a token.

​
Principle of least privilege

Inside the cluster, services authenticate to AWS through IRSA-bound IAM roles. Each service has its own role, scoped to only the AWS actions and resources it needs, the API does not have the same AWS permissions as the data-refinery runner, for example. The same principle applies to integration credentials: each integration’s credentials are scoped to the OAuth permissions or database privileges the integration actually requires.