Skip to content

Administration Basics

This document is for administrators who are looking for information about how to set up access control, as related to the Okera Policy Engine.


Okera offers both of the common access control styles, that is, Attribute-based Access Control and Role-based Access Control, both of which are explained subsequently in full detail. Before you can use them though you first need to configure one or more person in your organization who is taking on the role of system administrator.

With corporate identity and access management (IAM) based on a central, enterprise-wide directory service (such as Microsoft's Active Directory, or OpenLDAP), administrators are commonly defined as a group (of users) inside the directory. Every member of that group is considered equal in their sets of permissions, which extends to Okera in the same way.

The following describes how you can configure an Okera Data Access Service cluster with a group of initial system administrators, who are responsible to configure the system and grant access to resources, while delegating more compartmentalized administrative permissions to, for example, business units for self-service access control management, or catalog administrators who can manage access to catalog resources only (explained below as well).

System Administrators

These are defined by configuration; you can define a list of user and groups that are given system administration rights as part of the YAML-based cluster configuration file, which you can learn more about here:

Example: Defining specific groups as system administrators in the configuration file

CATALOG_ADMINS: "system_admins,okera_admins"


The configuration key is misleadingly named catalog admins, but does indeed cover system administrators. This key may be renamed SYSTEM_ADMINS in a future version of ODAS.

The system administrators have access to everything within the ODAS cluster and can manage all resources, that is, all objects in the Catalog and Policy Engine.

Catalog Administrators

These are defined by role; you need to define a role that grants all permissions to a user or group at the catalog level:

Example: Granting catalog administrative rights to a user group using a role

CREATE ROLE catalog_admin_role;
GRANT ALL ON CATALOG TO ROLE catalog_admin_role;
GRANT ROLE catalog_admin_role TO GROUP admins;

The catalog administrators can manage all Catalog resources, but cannot manage Policy Engine resources (see next section).

Administrative Scope

Note how you need to execute a CREATE ROLE <role> statement to define catalog administrators by role. In a brand new cluster, this can only be done by the system administrators defined in the cluster configuration file, which illustrates the difference between the two types of admins.

More specifically, when looking at SQL, the Structured Query Language standard, you can classify the supported statements into four groups of sub-languages:

  • DQL - Data Query Language

    These are the usual SELECT statements to query data from relational datasets.

  • DML - Data Manipulation Language

    Comprises INSERT, UPDATE, and DELETE statements.

  • DDL - Data Definition Language

    Here are the statements used to create and remove relational objects, such as databases and schemas. Includes CREATE {DATABASE,TABLE,VIEW} and the matching ALTER and DROP statements.

  • DCL - Data Control Language

    Finally, these statements are needed to control access to data stored in relational datasets. Includes the GRANT, REVOKE, CREATE ROLE and DROP ROLE statements.

The difference between the two types of ODAS global administrators is that the one defined in the configuration can execute all of those statements, while the administrator by role can only do the first three.

Table: Allowed SQL sub-language support by admin type

Administrator Type DQL DML DDL DCL
System Administrator (by configuration)
Catalog Adminstrator (by role)

The main reason for the difference is that when you execute the GRANT ALL ON CATALOG TO ROLE <role> statement you are doing this at the catalog level (see Object Types and Scope for details). This does not include the Policy Engine though, which is responsible for handling the DCL statements.

In fact, with the above GRANT statement you are also not allowed to grant any permissions to others. You must use this statement instead:


Note the extra WITH GRANT OPTION, which gives that role the ability to pass on permissions all the way to the catalog level.

Next Steps

After you have defined your global administrators you can continue from here with either ABAC and/or RBAC.