Access Control Sync

Onehouse allows you to bi-directionally sync data privileges between your catalogs. This functionality is publicly known as OneSync Permissions.

How it Works

Typical Sync Flow

1. Add catalogs to your Onehouse project.
2. In the Onehouse console, open Catalogs, then navigate to the Access Control Sync tab.
3. Import permissions from a source catalog. These privileges are stored as a data role in Onehouse.
4. Optionally, grant and/or revoke privileges on the data role.
5. Sync the data role out to your target catalogs.

Onehouse translates privileges between catalogs using an internal representation, so you can sync permissions even when catalogs use different privilege models.

Supported Catalogs

Catalog	Principal Type	Notes
AWS Glue (via Lake Formation)	IAM User, IAM Group, IAM Role	Two-level hierarchy (database, table). One Data Catalog per AWS account.
Databricks Unity Catalog	User, Service Principal, Group	Three-level hierarchy (catalog, schema, table). No native role concept; roles are mapped to groups.
Snowflake Horizon Catalog	User, Role	Three-level hierarchy (database, schema, table). No native group concept. Permissions can only be granted to roles, not directly to users.
Microsoft OneLake	Entra User, Entra Group, OneLake Security Role	Three-level hierarchy (item, schema, table). See OneLake-specific notes below.

Let us know if you are interested in a catalog we do not yet support.

Object Hierarchy

Each catalog organizes data objects differently. Onehouse normalizes these into a common hierarchy for synchronization:

Level	Onehouse Internal	AWS Glue (Lake Formation)	Databricks Unity	Snowflake	Microsoft OneLake
Level 1 (Catalog)	Catalog	N/A (single Data Catalog per account)	Catalog	Database	Item (Lakehouse)
Level 2 (Database)	Database	Database	Schema	Schema	Schema
Level 3 (Table)	Table	Table	Table	Table	Table

note

Access Control Sync currently supports synchronization for a single catalog (or database/Lakehouse) per metastore. Multi-catalog synchronization is not supported at this time.

Privilege Mapping

Onehouse maps privileges across catalogs using a common internal representation. Because catalogs support different privilege types, there is not always a 1:1 mapping. The tables below show how each privilege translates.

Database / Schema Privileges

Onehouse Privilege	AWS Glue (Lake Formation)	Databricks Unity	Snowflake (Schema)	Microsoft OneLake
ALL	ALL	ALL_PRIVILEGES	ALL	ReadWrite
DESCRIBE	DESCRIBE	-	MONITOR	Read
CREATE	CREATE_TABLE	CREATE	CREATE TABLE	-
SELECT	DESCRIBE	SELECT	USAGE	Read
INSERT	CREATE_TABLE	MODIFY	CREATE TABLE	ReadWrite
UPDATE	UPDATE	MODIFY	MODIFY	ReadWrite
DELETE	DROP	MODIFY	-	ReadWrite
ALTER	ALTER	-	MODIFY	ReadWrite
DROP	DROP	MANAGE	-	ReadWrite

Table Privileges

Onehouse Privilege	AWS Glue (Lake Formation)	Databricks Unity	Snowflake	Microsoft OneLake
ALL	ALL	ALL_PRIVILEGES	ALL	ReadWrite
DESCRIBE	DESCRIBE	-	-	Read
CREATE	-	CREATE	-	-
SELECT	SELECT	SELECT	SELECT	Read
INSERT	INSERT	MODIFY	INSERT	ReadWrite
UPDATE	UPDATE	MODIFY	UPDATE	ReadWrite
DELETE	DELETE	MODIFY	DELETE	ReadWrite
ALTER	ALTER	-	-	ReadWrite
DROP	DROP	MANAGE	-	ReadWrite

A - indicates that the catalog does not have a corresponding privilege for that operation.

info

• Databricks Unity MODIFY is only granted when the source provides the full insert/update/delete stack. Otherwise, the privilege maps to SELECT.
• OneLake ReadWrite is only granted when the source provides the full create/read/update/delete stack. Otherwise, the privilege maps to Read.
• OWNERSHIP and data location permissions are not synchronized.
• Privileges that cannot be mapped to the internal model are skipped during import and noted in the sync results.

Catalog-Specific Notes

AWS Glue (Lake Formation)

• Permissions are managed through AWS Lake Formation and support all principal types: IAM users, IAM groups, and IAM roles.
• AWS Glue uses a two-level hierarchy (database and table). There is typically one Data Catalog per AWS account.
• Users also need the appropriate Glue and S3 IAM permissions to query data. Onehouse synchronizes Lake Formation permissions only -- IAM policies for Glue and S3 access are the customer's responsibility.

Databricks Unity Catalog

• Unity Catalog supports users, service principals, and groups as principals, but does not have a native role concept. When syncing roles from other catalogs (such as Lake Formation or Snowflake), Onehouse maps them to Unity Catalog groups.
• Unity Catalog uses a three-level hierarchy (catalog, schema, table).
• Unity does not have distinct privilege types for DESCRIBE, ALTER, INSERT, UPDATE, or DROP at the same granularity as other catalogs. These are represented through SELECT, MODIFY, and MANAGE.

Snowflake Horizon Catalog

• Snowflake supports users and roles, but does not have a native group concept. Permissions can only be granted to roles, which are then assigned to users or other roles.
• Snowflake uses a three-level hierarchy (database, schema, table).

Microsoft OneLake

• OneLake access control is managed through OneLake Security, which must be enabled on your Lakehouse for Access Control Sync to function.
• Lakehouse only -- OneLake Security is supported for Lakehouses but not Warehouses. Access Control Sync can only target a Lakehouse.
• OneLake Security governs data-plane access only (read/write on schemas and tables). Control-plane operations such as CREATE TABLE, CREATE SCHEMA, and DROP are managed separately through item permissions and are not synchronized.
• Lakehouses can be schema-enabled or schema-disabled. Access Control Sync requires a schema-enabled Lakehouse that follows the standard three-part hierarchy (lakehouse.schema.table).
• OneLake Security supports only two permission levels: Read and ReadWrite. Finer-grained privilege distinctions from other catalogs are mapped to these two levels.

Quickstart: Sync from Unity Catalog to OneLake

This walkthrough imports table privileges from Databricks Unity Catalog into Onehouse, then syncs them to Microsoft OneLake Security.

Prerequisites

• A Databricks Unity Catalog and a Microsoft OneLake Lakehouse (schema-enabled) added to your Onehouse project.
• A Service Principal in Databricks Unity Catalog that you want to manage permissions for.
• OneLake Security enabled on your Lakehouse.

1. Set up permissions in Unity Catalog

In your Databricks workspace, create a schema and table, then grant privileges to your Service Principal:

CREATE SCHEMA bronze;

CREATE TABLE bronze.customers (
  id BIGINT,
  name STRING,
  email STRING
);

GRANT MODIFY, SELECT ON TABLE bronze.customers TO `<service-principal-name>`;

The Service Principal now has SELECT (read) and MODIFY (insert, update, delete) on the customers table.

2. Import permissions into Onehouse

1. Open the Onehouse console.
2. Click Catalogs, then open the Access Control Sync tab.
3. Click Import and choose the Unity Catalog you have added to Onehouse.

Onehouse detects the privileges granted to the Service Principal and imports them as a data role. Only the differences since the last import are synced in.

3. (Optional) Grant or revoke privileges in Onehouse

You can adjust the role's privileges directly in the Onehouse console using SQL statements before syncing to your target catalog:

GRANT SELECT
ON DATABASE bronze
TO ROLE <role_name>;

REVOKE DELETE
ON TABLE bronze.customers
FROM ROLE <role_name>;

4. Sync to OneLake

1. Click the Sync button in the Access Control Sync tab.
2. Choose the OneLake catalog you have added to Onehouse.

Onehouse syncs the data role to OneLake Security. The role is created or updated in OneLake with the translated privileges.

5. Verify in OneLake

Open the OneLake console and you will see the privileges applied to the role. Because OneLake uses a simplified permission model, the Unity Catalog privileges are mapped as follows (see Privilege Mapping for full details):

Unity Catalog Privilege	Onehouse Internal	OneLake Security
SELECT	SELECT	Read
MODIFY	INSERT, UPDATE, DELETE	ReadWrite

Since MODIFY provides the full insert/update/delete stack, the role receives ReadWrite access in OneLake, which includes read access.

Current Limitations

• Access Control Sync supports database-level and table-level privileges. Column-level, row-level, view-level, and other object-level permissions are not supported.
• Only one catalog (or database/Lakehouse/Warehouse) can be used per metastore for importing and syncing permissions.
• Syncing is scoped to roles (or their catalog-equivalent). Direct user-level or group-level permission sync is not yet supported, except for Unity Catalog groups (since Unity has no role concept).