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.
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.
Example of a user
anna who has ownership on the role
marketing_analyst and on the dataconnection
This is denoted internally by an internal user-role, with the naming convention
For example, for the user
anna the internal user role is named
Catalogscope does not cascade to all databases. You will not be able to create datasets inside databases you have not created. Depending on the scope (
DATABASE) users 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
- ✅ Grant permissions on the
marketingdbdatabase to the roles they own
- ✅ Create and assign tags only within the
- ✅ View insights for databases they own
marketing_steward_role is granted to the AD 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 Insights 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
- ✅ Assign tags from
piiAttribute Namespace on all data objects (Databases, Tables, Cols) in the Catalog
compliance_officer_role role is granted to the AD 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 Insights 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;