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, role-based access control(RBAC) and attribute-based access control(ABAC). Both are explained below in more detail. Within Okera these are not seen as mutually exclusive, but instead complementary.
This overview covers how access control works in Okera in the following topics:
- Setting up system administrators
- How RBAC works in Okera
- Using roles to delegate access management
- Understanding the difference between 'permissions' and 'policies'
- Setting up safeguard policies for catalog-wide compliance
- Granting access via permissions and adding ABAC policy conditions
Set 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
Note: The configuration key is misleadingly named catalog admins, but does indeed cover system administrators. This key may be renamed
SYSTEM_ADMINSin 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.
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 Versus Policies¶
Once you set up system administrators and delegate access to perform key access management tasks to other users, you can start granting access to data using permissions. It is 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 Documentation Links
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.
Grant Access to Data Using Permissions¶
Once you have delegated your key persona roles, and set up global safeguard policies, you can start granting access to data using RBAC permissions, leveraging dynamic ABAC policy conditions where needed. Permissions can be granted in the UI using the Permissions Builder or programmatically via Okera's policy syntax shown in the RBAC and ABAC guides above.