LogoLogo
Start Trial
  • Overview
    • What is DeltaStream?
    • Core Concepts
      • Access Control
      • Region
      • SQL
      • Store
      • Database
      • Query
      • Visualizing Data Lineage
      • Function
  • Getting Started
    • Free Trial Quick Start
    • Starting with the Web App
    • Starting with the CLI
  • Tutorials
    • Managing Users and User Roles
      • Inviting Users to an Organization
      • Administering Users in your Organization
      • Using the CLI to Manage User Roles
      • Example: Setting Up Custom Roles for Production and Stage
    • Creating Stores for Streaming Data
    • Using Multiple Stores in Queries
    • Creating Relations to Structure Raw Data
    • Namespacing with Database and Schema
    • Creating and Querying Materialized Views
    • Creating a Function
    • Securing Your Connections to Data Stores
      • Introducing DeltaStream Private Links
      • Creating an AWS Private Link from DeltaStream to your Confluent Kafka Dedicated Cluster
      • Enabling Private Link Connectivity to Confluent Enterprise Cluster and Schema Registry
      • Creating a Private Link from DeltaStream to Amazon MSK
      • Creating a Private Link for RDS Databases
      • Deleting a Private Link
    • Integrations
      • Connecting to Confluent Cloud
      • Databricks
      • PostgreSQL
      • Snowflake
      • WarpStream
    • Serialization
      • Working with ProtoBuf Serialized Data and DeltaStream Descriptors
      • Working with Avro Serialized Data and Schema Registries
      • Configuring Deserialization Error Handling
  • Reference
    • Enterprise Security Integrations
      • Okta SAML Integration
      • Okta SCIM Integration
    • Metrics
      • Prometheus Integration
      • Built-In Metrics
      • Custom Metrics in Functions
    • SQL Syntax
      • Data Formats (Serialization)
        • Serializing with JSON
        • Serializing with Primitive Data Types
        • Serializing with Protobuf
      • Data Types
      • Identifiers and Keywords
      • Command
        • ACCEPT INVITATION
        • CAN I
        • COPY DESCRIPTOR_SOURCE
        • COPY FUNCTION_SOURCE
        • DESCRIBE ENTITY
        • DESCRIBE QUERY
        • DESCRIBE QUERY METRICS
        • DESCRIBE QUERY EVENTS
        • DESCRIBE QUERY STATE
        • DESCRIBE RELATION
        • DESCRIBE RELATION COLUMNS
        • DESCRIBE ROLE
        • DESCRIBE SECURITY INTEGRATION
        • DESCRIBE <statement>
        • DESCRIBE STORE
        • DESCRIBE USER
        • GENERATE COLUMNS
        • GENERATE TEMPLATE
        • GRANT OWNERSHIP
        • GRANT PRIVILEGES
        • GRANT ROLE
        • INVITE USER
        • LIST API_TOKENS
        • LIST DATABASES
        • LIST DESCRIPTORS
        • LIST DESCRIPTOR_SOURCES
        • LIST ENTITIES
        • LIST FUNCTIONS
        • LIST FUNCTION_SOURCES
        • LIST INVITATIONS
        • LIST METRICS INTEGRATIONS
        • LIST ORGANIZATIONS
        • LIST QUERIES
        • LIST REGIONS
        • LIST RELATIONS
        • LIST ROLES
        • LIST SCHEMAS
        • LIST SCHEMA_REGISTRIES
        • LIST SECRETS
        • LIST SECURITY INTEGRATIONS
        • LIST STORES
        • LIST USERS
        • PRINT ENTITY
        • REJECT INVITATION
        • REVOKE INVITATION
        • REVOKE PRIVILEGES
        • REVOKE ROLE
        • SET DEFAULT
        • USE
      • DDL
        • ALTER API_TOKEN
        • ALTER SECURITY INTEGRATION
        • CREATE API_TOKEN
        • CREATE CHANGELOG
        • CREATE DATABASE
        • CREATE DESCRIPTOR_SOURCE
        • CREATE ENTITY
        • CREATE FUNCTION_SOURCE
        • CREATE FUNCTION
        • CREATE INDEX
        • CREATE METRICS INTEGRATION
        • CREATE ORGANIZATION
        • CREATE ROLE
        • CREATE SCHEMA_REGISTRY
        • CREATE SCHEMA
        • CREATE SECRET
        • CREATE SECURITY INTEGRATION
        • CREATE STORE
        • CREATE STREAM
        • CREATE TABLE
        • DROP API_TOKEN
        • DROP CHANGELOG
        • DROP DATABASE
        • DROP DESCRIPTOR_SOURCE
        • DROP ENTITY
        • DROP FUNCTION_SOURCE
        • DROP FUNCTION
        • DROP METRICS INTEGRATION
        • DROP RELATION
        • DROP ROLE
        • DROP SCHEMA
        • DROP SCHEMA_REGISTRY
        • DROP SECRET
        • DROP SECURITY INTEGRATION
        • DROP STORE
        • DROP STREAM
        • DROP USER
        • UPDATE ENTITY
        • UPDATE SCHEMA_REGISTRY
        • UPDATE SECRET
        • UPDATE STORE
      • Query
        • APPLICATION
        • Change Data Capture (CDC)
        • CREATE CHANGELOG AS SELECT
        • CREATE STREAM AS SELECT
        • CREATE TABLE AS SELECT
        • Function
          • Built-in Functions
          • Row Metadata Functions
        • INSERT INTO
        • Materialized View
          • CREATE MATERIALIZED VIEW AS
          • SELECT (FROM MATERIALIZED VIEW)
        • Query Name and Version
        • Resume Query
        • RESTART QUERY
        • SELECT
          • FROM
          • JOIN
          • MATCH_RECOGNIZE
          • WITH (Common Table Expression)
        • TERMINATE QUERY
      • Sandbox
        • START SANDBOX
        • DESCRIBE SANDBOX
        • STOP SANDBOX
      • Row Key Definition
    • Rest API
Powered by GitBook
On this page
  • Organization
  • User
  • Object
  • Privilege
  • Role
  • Built-in roles
  • Custom roles
  • Best Practices
  1. Overview
  2. Core Concepts

Access Control

How DeltaStream handles user access

PreviousCore ConceptsNextRegion

Last updated 1 month ago

Organization

An organization is the unit of tenant isolation in DeltaStream. All objects (, , , and so on) are set up under the organization.

User

A user represents an authenticated identity within DeltaStream. A user may be a member of multiple organizations. Within each organization, a user can hold one or more .

Object

Within DeltaStream, objects are entities you can protect with access controls. Access to an object is denied by default; it must be explicitly granted privileges to a role. Each object resides within a hierarchy, with the as the root. Organizations contain , , , , , and . Databases contain , which in turn contain .

Privilege

Use of these commands is restricted to:

  • The role that owns an object (that is, the role with OWNERSHIP privilege on the object)

  • Any roles that have the MANAGE_GRANTS global privilege for the object

    • By default, this is SECURITYADMIN.

Note A role that holds the global MANAGE_GRANTS privilege can grant additional privileges to the current (grantor) role.

Available privileges

Privilege
Applicable object
Description

CREATE_DATABASE

Allows databases to be created

CREATE_STORE

Allows stores to be created

CREATE_SCHEMA_REGISTRY

Allows schema registries to be created

CREATE_DESCRIPTOR_SOURCE

Allows descriptor sources to be created

CREATE_FUNCTION_SOURCE

Allows function sources to be created

CREATE_FUNCTION

Allows functions to be created

CREATE_QUERY

Allows queries to be run

MANAGE_MEMBERS

Allows management of users and roles

MANAGE_GRANTS

Allows management of privileges

USAGE

Allows viewing and basic usage of the object. Additional privileges may be required for some actions

CREATE

For databases, allows new schemas to be created with in the database. For schemas, allows defining new relations within the schema.

SELECT

Allows select queries to use to the relation

INSERT

Allows queries to inserting data into the relation

Role

Users can have multiple roles. This enables them to switch roles to perform actions with a different set of privileges.

Roles also can be granted to other roles. This creates a hierarchy of roles wherein the privileges associated with one role are inherited by any role that's higher in the hierarchy.

Here's an example: In the diagram below, the SysAdmin role automatically inherits any privilege assigned to a custom role.

Built-in roles

The following are built into DeltaStream and are available "out of the box:"

  • ORGADMIN — Root of the the role hierarchy. This role manages operations at the organization level.

  • SYSADMIN — Has privileges to create, manage, and drop objects.

  • USERADMIN — Has privileges to manage users and roles within the organization.

  • SECURITYADMIN — Manages any object grants globally. This role inherits privileges from the USERADMIN role.

  • PUBLIC — A pseudo role granted to all roles within the organization. This role can be granted privileges on objects that are inherited by all other roles.

Custom roles

Custom roles can be created in two ways:

  • by someone with the USERADMIN (or a higher) role

  • by any other role to which the MANAGE_MEMBERS privilege has been granted.

When you create a new role it is not assigned to any user, nor granted to any other role. For roles you intend to be owners of objects, we recommend you use a custom role hierarchy wherein the top-most custom role in the hierarchy is assigned to the SYSADMIN system role. This enables system administrators to manage all the objects in the organization, while still restricting management of users and roles to the USERADMIN role.

If you do not assign SYSADMIN through a role hierarchy to a custom role, the system administrator cannot manage objects owned by the custom role. This means that only roles that have been granted the MANAGE_GRANTS privilege (the SECURITYADMIN role by default) can view the objects and modify their access grants.

Best Practices

We recommend the following best practices for access control:

  • Reserve the ORGADMIN role for administrative tasks only. It must not be used for day-to-day access.

  • Administrators should have 2 separate logins:

    • a login with the ORGADMIN role for administrative tasks

    • a separate role for day-to-day access.

  • ORGADMIN must not own any objects and it must never be granted to any other roles.

  • SECURITYADMIN is also a very powerful role with the MANAGE_GRANTS privilege. Only use this role in limited cases.

  • USERADMIN should be the default role for managing users and role grants. This role typically is the owner of all other custom roles.

  • SYSADMIN should be the default role for managing objects and should always be the eventual owner of all other objects. You can grant custom roles to SYSADMIN. But you must never grant it ownership of other roles. This maintains the separation of responsibility between SYSADMIN and USERADMIN.

  • When you build a custom role hierarchy, define functional roles and access roles. You can grant privileges on objects to access roles, and you can grant access roles to functional roles.

Every object is owned solely by the role used when the object was created. The owner role has all on the object and can grant or revoke privileges to other . Object ownership can be transferred from one role to another.

In DeltaStream, privileges determine which role can access and perform operations on a given object. Every object has a set of privileges that can be granted on it. Privileges are managed using the and commands.

, , , , , , , , , ,

,

A role is an entity to which privileges can be granted. You assign roles to to allow them to perform actions against an .

Note DeltaStream includes a set of under every organization. Built-in roles cannot be dropped and the assigned to these roles cannot be revoked.

For instructions to create custom roles, see .

Use -based automation to manage grants of functional roles to users.

GRANT
REVOKE
CREATE ROLE
SCIM
privileges
roles
users
object
built-in roles
privileges
Organization
Organization
Organization
Organization
Organization
Organization
Organization
Organization
Organization
databases
stores
queries
stores
databases
function sources
queries
roles
organization
Database
Store
Function Source
Function
Query
Organization
Role
Database
Schema
Relation
Relation
Schema Registry
Schema
Relation
Descriptor Source
schema registries
schemas
relations
descriptors
Securable object container hierarchy
Role hierarchy