Skip to content

Administration Overview

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

Introduction

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"

Note

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 Okera administrators is that the one defined in the configuration can execute all of those statements, while the catalog administrator, defined 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 Administrator (by role)

If you wish to enable the Catalog Administrator to be able to also grant access to objects, you can add the WITH GRANT OPTION flag to the CATALOG level permission:

GRANT ALL ON CATALOG TO ROLE catalog_admin_role WITH GRANT OPTION;

Access Delegation

After you have defined your global administrators, you can setup the other personas for your data platform. See Access Delegation.

Granting access to data

Once you have delegated your key persona roles, you can start granting access to data via ABAC and/or RBAC permissions.