Access Overview¶
Okera offers both common access control styles, role-based access control(RBAC) and attribute-based access control(ABAC). Within Okera, these access control styles are not mutually exclusive, but complementary.
Access control in Okera makes use of:
System Administrators¶
System administrators are defined by configuration. You define a list of users that have system administration rights as part of the Okera YAML-based cluster configuration file. For more information, see The Okera Configuration File.
Example: Defining specific groups as system administrators in the configuration file
CATALOG_ADMINS: "system_admins,okera_admins"
System administrators have access to everything within the Okera 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 (RBAC)¶
With role-based access control (RBAC), Okera uses roles to apply permissions to groups of users. A user's access to data is controlled by the roles to which the user has been assigned.
Users or groups are integrated from your organization's identity management system and can be assigned to Okera roles. Roles can be customized to your organization's naming convention and can be managed programmatically as well as in the UI. For more information, see Role-Based Access Control and Managing Roles.
System administrators can control data access management for users 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. For more information, see Access Delegation.
RBAC is useful for simplifying access control, and saves you from having to create individual grants for individual users.
However as the number of users, datasets, and use cases increase, it becomes painful to maintain different permutations of different objects for each role and can lead to role explosion. For example, to restrict access to data in a sales transaction dataset that must be viewed differently for sales analysts in different regions, you would need to create a sales analyst role for each region (for example, sales_analyst_usa and sales_analyst_emea). To reduce such role explosion, Okera also supports attribute-based access control, described next.
Attribute-Based Access Control (ABAC)¶
Okera allows you to assign attributes, or tags, to objects in Okera, such as databases, datasets, URIs, and schema columns. You can then grant permission to data based on these tags. For example, to restrict access to data in a sales transaction dataset that must be viewed differently for sales analysts in different regions, you could tag the region column in the data (for example, region) and then create a permission for the sales_analyst role that uses the tag to restrict the data viewed by analysts to the regions to which they are assigned in their user profiles. For more information about ABAC, see Attribute-Based Access Control (ABAC).
Safeguard Policies¶
Note: Safeguard policies are an Okera preview (beta) feature. If you want to use safeguard policies, please contact Okera for more information.
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.
Permissions¶
After you have created and assigned role in Okera, and you have set up any global safeguard policies, and you have tagged your data appropriately, you can start granting access to data using role-based (RBAC)permissions, leveraging attribute-based ABAC permission conditions where needed. Permissions can be granted in the UI using the Permissions Builder or programmatically using Okera SQL. See Permission Examples for some examples.