Access Levels

In the role-based access control model supported by the Okera Platform, roles are granted access to resources by means of access levels. The Okera Policy Engine (planner) supports the following access levels:

Note: Attribute-based access control (ABAC) policies only support the SELECT privilege level. See Attribute-Based Access Control (ABAC).

Access Levels	Available Scopes	Description
ADD_ATTRIBUTE	Database, Table, Attribute Namespace	Ability to either assign attributes on the specified data object, or to assign attributes from the specified attribute namespace.
ALL	Catalog, Database, Table, URI, Crawler, Attribute Namespace, Role	Full and unrestricted access to any data object and any descendants. This permission is a superset of all the privileges below. Adding the WITH GRANT OPTION flag when granting on CATALOG,, DATABASE or TABLE scope allows users to additionally grant permissions on the specified object to other roles.
ALTER	Catalog, Database, Table	Ability to edit metadata for specified object, such as alter the table/view definition, add/drop/rename columns, change datatypes, partitions, storage locations, table properties. When applied for the CATALOG scope, it grants the ability to view metadata for all objects.
CREATE	Catalog, Database, Attribute Namespace	Ability to create an object within another object, for instance, GRANT CREATE ON DATABASE grants the ability to create a table within the database.
CREATE_AS_OWNER	Catalog, Database	Ability to create an object (database, table or view) and automatically receive ALL privileges on the object you created e.g. GRANT CREATE_AS_OWNER ON CATALOG. 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.
CREATE_CRAWLER_AS_OWNER	Catalog	Ability to create crawlers. Users will automatically be granted ownership (ALL) on the CRAWLER objects they create.
CREATE_DATACONNECTION_AS_OWNER	Catalog	Ability to create connections. Users will automatically be granted ownership (ALL) on the DATACONNECTION objects they create.
CREATE_ROLE_AS_OWNER	Catalog	Ability to create roles. Users will automatically be granted ownership (ALL) on the ROLE objects they create.
DELETE	Catalog, Database, URI	Ability to delete the data of an object.
DROP	Catalog, Database, Table, Attribute Namespace, Role	Ability to remove specified objects.
INSERT	Database, Table, Column	Write access to the object. Does not include read access.
MANAGE_GROUPS	Catalog, Role	Ability to add or remove groups granted to a specified ROLE.
MANAGE_PERMISSIONS	Catalog, Role	Ability to grant permissions to the specified role. You will only be able to grant permissions on objects you have WITH GRANT OPTION on.
REMOVE_ATTRIBUTE	Database, Table	Ability to remove attributes on the specified data object. Must be combined with ADD_ATTRIBUTE to be functional.
SELECT	Catalog, Database, Table, Column	Read access to an object and any descendants.
SHOW	Catalog, Database, Table	Read access to object metadata only. Cannot be granted at a column level.
UPDATE	Catalog, Database, Table	Replace rows of data in the specified data object and to all data objects within it. Does not include read access.
USE	Catalog, Dataconnection	Ability to register data from the specified DATACONNECTION. You will also need CREATE_CRAWLER_AS_OWNER to be able to create crawlers from this connection.
VIEW_AUDIT	Catalog, Database, Table	Ability to see audit data only for the specified objects. The user also needs read access to the okera_system.reporting_audit_logs view to be able to use insights. Read more here.
VIEW_COMPLETE_METADATA	Catalog, Database, Table	Read access to an object's full metadata. The user will be able to see all metadata that an admin would see on this object.
WITH GRANT OPTION	Catalog, Database, Table	Ability to grant permissions on the specified data to roles. The user will only be able to grant to roles they have the ability to MANAGE_PERMISSIONS on. WITH GRANT OPTION is specified as an additional flag on a ALL or SELECT permission on data e.g. GRANT ALL ON DATABASE okera_sample TO ROLE steward_role WITH GRANT OPTION would enable users belonging to the role steward_role to issue a GRANT ALL ON DATABASE okera_sample TO ROLE other_role.

Object Types and Scope

All permissions are usually scoped at a specific object level.

Object Types

Here are the object types supported by Okera:

Object	Syntax	Description
Catalog	CATALOG*	Global scope for all objects in the Catalog.
Database	DATABASE <db_name>	Scope on a single database and all included objects
Table	TABLE <table_name>	Permissions for a specific table or view, with all its columns
Column	(col1, coln) TABLE <table_name>	As before, but for a subset of columns only
URI	URI <uri>	Specific to a file-based resource.
Crawler	CRAWLER <crawler_name>	Scope on a single crawler and all unregistered datasets inside it.
Attribute Namespace	ATTRIBUTE NAMESPACE <attribute_namespace>	Refers to a specific namespace of attributes (i.e. tags)
Role	ROLE <role_name>	Scope on a single role.

^* If you see the term SERVER, it refers to the old syntax for CATALOG.

Scope Hierarchy

Scope is the selection of an object at some point in the hierarchy, and knowing that all child objects are included. For example, if you allow read access to a specific database for a certain role, all user groups that are associated with that role will be able to read all datasets (that is, all tables and views) in the database.

Note: You cannot revoke permissions on a scope that were granted on a higher scope. If you grant access for a database to a specific role, you cannot revoke access to some of the datasets included in that database.

Assigning permissions for child objects are commonly issued at the next higher scope. For instance, you need to permit create permissions for a role on the database level, allowing the role owners to create new tables and views inside that database.

Views are handled using the same scope as tables. In other words, when addressing views as part of the authorization commands, refer to the table documentation.

URI Objects

URIs are a special kind of object, registering paths or specific resource files (such as Java JARs) that are accessible for non-administrative users. There are a handful types of actions that require file system permissions:

• Creating databases
• Creating external tables
• Creating functions
• Altering an external table's location
• Altering a table's set of partitions

In general, any action that requires the LOCATION or ROW FORMAT SERDE keywords is checked for file system permissions before it is allowed by the platform. Some of the above operations are only allowed at the catalog level scope, implicitly making anyone allowed at that level a global administrator. And since global administrators are unrestricted, it is assumed they have unrestricted access to the underlying file systems.

Note: The file system checks for global administrators fall back to Okera having access to the file resources. In practice, every Okera setup will run with an authenticated technical user account, which needs to have access to all resources that are referenced by any of the location dependent SQL statements.

The following table shows each affected action with the scope and privilege they require, and what that means for the file system checks:

Action Type	Scope	Privilege	File System Check
Create Database	Catalog	All	Not needed
Create Function	Catalog	All	Not needed
Create External Table	Database	All	Yes1
Alter External Table Location	Database	All	Yes1
Alter Table Partitions	Database	All	Yes1

Legend: ¹ Applies to non-administrative users only

Note: URIs only are supported in combination with the All privilege, as shown in the table.

For non-specific URIs, that is those which are not referencing a specific resource file (see Extending Okera for an example), access is checked for the given file system path. Any file or directory inside that location is automatically included. That allows, for example, an administrator to permit access to a specific root path for a given role. Any user that is associated with that role is allowed the same level of access inside that root path.

Finally, any SQL statement that uses one of those resources implicitly, like a SELECT statement using a UDF, does not require a file system permission check again. This makes sense as first a table or function must be created before it can be used. In other words, an administrator or elevated user (with "All" privileges on the catalog or database level respectively) creates the object or function using the explicit location URI. Any other user with, for example, a read-only role is allowed to access the object or function without requiring explicit access to the underlying resources.

Here are examples showing the difference:

Example: SQL statements that require explicit access to the specified resources

CREATE EXTERNAL TABLE transactions_schemaed(
  txnid BIGINT,
  dt_time STRING,
  sku STRING,
  userid INT,
  price FLOAT,
  creditcard STRING,
  ip STRING)
ROW FORMAT DELIMITED
FIELDS TERMINATED BY ','
LOCATION 's3://acme-sales-data/transactions';

ALTER TABLE sales.transactions_schemaed RECOVER PARTITIONS;

CREATE FUNCTION sales.mask(STRING) RETURNS STRING
LOCATION 's3://acme-udfs-public/udfs/mask-udf.jar'
SYMBOL='com.acme.hiveudf.MaskUDF';

Example: SQL statements that do not require explicit access to the underlying resources

SELECT count(txnid) FROM sales.transactions_schemaed;

CREATE VIEW sales.transactions AS
SELECT
  txnid,
  dt_time,
  sku
FROM sales.transactions_schemaed;

How this is used in practice is explained in Best Practices.