Skip to content

How do I delegate access in Okera?

Okera has many access levels that can be used to delegate various data management tasks down to other users. This doc contains some example scenarios on how to delegate data management permissions as per a "distributed stewardship" model. In this model distributed data stewards have as much autonomy as possible in managing access to data in their domain, but do not have access to manage data in other domains.

You can choose to customize these delegated permissions however you want, depending on the personas within your organization.

The examples below show the permissions programatically, however you create all these permissions using the policy builder on the roles page.

Who can delegate permissions?

Only System Admins can delegate CATALOG level permissions to other roles.

Okera access levels in policy builder

What is ownership? (AS_OWNER)

You will note the AS_OWNER post-fix on some of the object access levels. This enables users to create those objects in the catalog and automatically be granted ownership (i.e. ALL) permission on the new object they have created.

Only the specific user that created that object will get ALL on the object, not all users with the role. You can view the ownership permissions a particular user has by searching for their username on the Roles page.

Okera user roles Example of a user anna who has ownership on the role marketing_analyst and on the dataconnection marketing_snowflake_connection.

This is denoted internally by an internal user-role, with the naming convention _okera_internal_role_<username>. For example, for the user anna the internal user role is named _okera_internal_role_anna.

Note

CREATE_AS_OWNER on Catalog scope does not cascade to all databases. You will not be able to create datasets inside databases you have not created. Depending on the scope (CATALOG or DATABASE) the user will only ever have ownership privileges on the databases or tables that they have created, and not on objects created by other users.

Example: Domain level data steward

For this example we are creating a marketing_steward_role who can:

  • ✅ Create databases in the catalog and become the owner of them
  • ✅ Create new connections to underlying sources and be able to register datasets from those sources
  • ✅ Register data from source connections they are allowed to register from
  • ✅ Create new roles and be the owner of them
  • ✅ Manage the marketingdb database
  • ✅ Grant permissions on the marketingdb database to the roles they own
  • ✅ Create and assign tags only within the marketing attribute namespace
  • ✅ View reports for databases they own

The marketing_steward_role is granted to the AD group marketing_steward_group. You could also grant this steward role directly to individual users, instead of a group.

-- create marketing steward role
CREATE ROLE marketing_steward_role;

-- grant marketing steward role to relevant users or groups
GRANT ROLE marketing_steward_role to group marketing_steward_group;

-- Marketing steward can create databases and be the owner of databases they create
GRANT CREATE_AS_OWNER on CATALOG TO ROLE marketing_steward_role;

-- Marketing steward can create roles and be the owner of roles they create
GRANT CREATE_ROLE_AS_OWNER on CATALOG to role marketing_steward_role;

-- Marketing steward can create dataconnections and be the owner of databases they create
GRANT CREATE_DATACONNECTION_AS_OWNER on CATALOG to role marketing_steward_role;

-- Marketing steward can create crawlers on from certain connections
-- and be the owner of crawlers they create
GRANT CREATE_CRAWLER_AS_OWNER on CATALOG to role marketing_steward_role;

-- In order to register tables from object storage, steward needs to be granted access to the URI
-- In this example steward will only be able to create tables under the specified path
GRANT ALL ON URI 's3://acme-data/department/marketing' TO ROLE marketing_steward_role;

-- Marketing steward can manage the marketingdb database
-- WITH GRANT OPTION flag enables management of policies as well
GRANT ALL ON DATABASE marketingdb TO ROLE marketing_steward_role WITH GRANT OPTION;

-- Grant access to the marketing attribute namespace
-- This means the steward can create and assign tags only from this namespace
GRANT ALL on ATTRIBUTE NAMESPACE marketing TO ROLE marketing_steward_role;

-- Grant access to the audit logs view to properly enable Reports page in UI
GRANT SELECT ON TABLE okera_system.reporting_audit_logs to ROLE marketing_steward_role;

Example: Compliance Officer

For this example we are creating a compliance_officer_role who can:

  • ✅ View audit logs across the Catalog
  • ✅ Create tags inside the pii Attribute Namespace
  • ✅ Assign tags from pii Attribute Namespace on all data objects (Databases, Tables, Cols) in the Catalog

The compliance_officer_role role is granted to the AD group compliance_group. You could also grant this compliance_officer_role role directly to individual users, instead of a group.

-- create role
CREATE ROLE compliance_officer_role;

-- grant role to relevant users or groups
GRANT ROLE compliance_officer_role to group compliance_group;

-- grant ability to see audit logs for all catalog objects
GRANT VIEW_AUDIT on CATALOG to role compliance_officer_role;

-- Grant access to the audit logs view to properly enable Reports page in UI
GRANT SELECT ON TABLE okera_system.reporting_audit_logs to ROLE compliance_officer_role;

-- Grant access to create tags and attribute namespaces
GRANT ALL on ATTRIBUTE NAMESPACE pii to role compliance_officer_role;

-- Grant access to assign tags across all data objects
GRANT ADD_ATTRIBUTE on CATALOG to role compliance_officer_role;
GRANT REMOVE_ATTRIBUTE on CATALOG to role compliance_officer_role;