Skip to content

Access Overview

This document is for administrators who are looking for an overview of how to set up access control using Okera.


Okera offers both of the common access control styles, that is Role-based Access Control(RBAC), and Attribute-based Access Control(ABAC), both of which are explained below in more detail. Within Okera these are not seen as mutually exclusive, but instead complementary.

This overview of how access control works in Okera covers:

Setting up system administrators

These are defined by configuration; you can define a list of users 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.

System administrators have access to everything within the ODAS cluster and can manage all resources across the Catalog and the Policy Engine. Therefore system administration rights should be granted sparingly.

Role-based access control

Okera leverages roles to make grouping permissions for users easier and more scalable. These roles can then be granted to users or groups that are integrated from your organization's identity management system. Roles can be customized to each organization's naming convention and can be managed programmatically as well as in the UI. Read RBAC Overview and Managing Roles for more information. Role-based Access Control

Access Delegation

After you have defined your system administrators, you can delegate access management to other personas for your data platform by creating roles and granting them specific access levels. For example you might want to set up data steward roles for each line of business, or an auditing role for a compliance officer. Read more about Access Delegation.

Permissions vs Policies

Once you have set up system administrators and delegated access to perform key access management tasks to other users, it will be time to start granting access to data using permissions. At this point it's important to define the distinction between permissions and policies within Okera, as you may sometimes see these terms used interchangeably.

  • Permissions grant access to perform a specific action, on a specific scope of data objects, to a role.
  • Policies do not grant access to data objects. Instead, they are added as conditions to a permission to change the way data is seen for different users via:

    • Column-level security
    • Row-level security
    • Obfuscation & masking using attributes and tags

    Safeguard Policies do this at the catalog level, which you can read more about below.

It may be an easier shorthand to think of "permissions" as being RBAC, and "policies" as being ABAC.

Useful Docs

Safeguard policies

Safeguard policies are global, catalog wide policies that ensure certain specified data is always masked, or restricted to certain users. Safeguard policies do not grant access to any data objects. Instead, they act as a global defense check, or 'safeguard', to ensure that certain data is always protected regardless of lower level permissions granting access to it. Read more about Safeguard Policies.

Granting access to data via permissions

Once you have delegated your key persona roles, and setup global safeguard policies, you can start granting access to data via RBAC permissions, leveraging dynamic ABAC policy conditions where needed. Permissions can be granted in the UI using the Policy Builder or programmatically via Okera's policy syntax shown in the RBAC and ABAC guides above.