Configure Access to OCF Data Sources

Alation Cloud Service Applies to Alation Cloud Service instances of Alation

Important

You are viewing documentation for Classic Alation.

Overview

In Alation, you can control who can view and edit metadata for data sources, schemas, and tables in your catalog. This helps protect sensitive data while ensuring the right people have appropriate levels of access.

Alation provides basic access controls by default. Optionally, you can enable advanced access controls and table-level privacy.

Basic Access Controls

Basic access controls are always available and enable you to configure access for an entire data source. All objects in a data source inherit the privacy mode and permission levels of the data source. If table-level privacy is enabled, you can also set privacy modes and permission levels for individual tables.

With basic access controls, you can:

• Choose between two privacy modes: Public and Private

• Choose between two user permission levels: Data Source Admin and Viewer

Advanced Access Controls

Available in beta from version 2024.3.5

Applies only to Alation Cloud Service on the cloud native architecture

In Alation 2024.3.5 and later, as a beta feature for the cloud native architecture only, you can enable advanced access controls.

With advanced access controls, you can:

• Set permissions for individual schemas or allow schemas to inherit permissions from their parent data source. (If table-level privacy is enabled, you can also set privacy modes and permission levels for individual tables.)

• Choose between three privacy modes: Public, Editing Restricted, and Private

• Choose between three user permission levels: Admin, Editor, and Viewer

  Note

  With advanced access controls, the Data Source Admin permission level is renamed to Admin. The name reflects the fact that this permission level doesn’t necessarily have admin permissions for an entire data source, if privacy settings have been overridden on specific schemas or tables.

Table-Level Privacy

Optionally, you can enable privacy settings for tables. This allows you to set permissions for individual tables.

Table-level privacy is available with both basic and advanced access controls.

Permission Levels

Permissions grant access to specific objects, while user roles grant the ability to use features and functionality. In order to perform a given action on a specific data object, you must have both the appropriate user role in Alation and the appropriate permission level for the specific object.

Note

Viewer permissions are distinct from the Viewer role. Users with the Viewer role have the ability to view objects in the catalog, but they must also have Viewer permissions on a specific object to see it. Everyone has Viewer permissions by default unless you set an object to Private mode.

The available permission levels depend on whether you have enabled advanced access controls.

Basic Access Controls

By default, Alation provides two permission levels on data sources (and tables, if enabled). The levels are described in the table below.

Permission Level	Description
Data Source Admin	Can change privacy and permission settings Can grant or revoke access for users and groups For data sources, can edit all settings, including connection parameters, metadata extraction (MDE), Compose, sampling, profiling, per-object parameters, query log ingestion (QLI), and lineage settings Has all Viewer permissions
Viewer	Can view the object anywhere it’s exposed in the catalog, including in search results, reports, and so forth Can bookmark, star, and watch the object (available actions depend on whether you’re in the New or Classic User Experience) Can view field change history Can edit field values and trust flags Can upload and download data dictionaries Can upload Compose queries

Advanced Access Controls

When advanced access controls are enabled, Alation supports three permission levels on data sources and schemas (and tables, if enabled). The levels are described in the table below.

Note

With advanced access controls, the Data Source Admin permission level is renamed to Admin. The name reflects the fact that this permission level doesn’t necessarily have admin permissions for an entire data source, if privacy settings have been overridden on specific schemas or tables.

Permission Level	Description
Admin	Can change privacy and permission settings Can grant or revoke access for users and groups For data sources, can edit all settings, including connection parameters, metadata extraction (MDE), Compose, sampling, profiling, per-object parameters, query log ingestion (QLI), and lineage settings Has all Editor and Viewer permissions
Editor	Can edit field values and trust flags Can upload data dictionaries Can upload Compose queries Has all Viewer permissions
Viewer	Can view the object anywhere it’s exposed in the catalog, including in search results, reports, and so forth Can bookmark, star, and watch the object (available actions depend on whether you’re in the New or Classic User Experience) Can view field change history Can download data dictionaries

Privacy Modes

The available privacy modes depend on whether you have enabled advanced access controls.

Basic Access Controls

By default, you can set data sources to one of two privacy modes. The modes are described in the table below.

Privacy Mode	Description
Public	Everyone has Viewer permissions Only selected people have Data Source Admin permissions Default permission level for new members is Data Source Admin Server Admins always have permissions to edit access settings On a data source, Server Admins must give themselves Data Source Admin permissions to the data source before they can edit other settings
Private	Only selected people have permissions On a data source, Admins can add members with any permission level On a data source, the default permission level for new members is Viewer On a table, new members inherit their permission level from the data source; if they they have no permissions on the data source, their permission level is Viewer Server Admins always have permissions to edit access settings On a data source, Server Admins must give themselves Data Source Admin permissions to the data source before they can edit other settings

Advanced Access Controls

Whent advanced access controls are enabled, you can set data sources and schemas (and tables, if enabled) to one of three privacy modes. The modes are described in the table below.

Privacy Mode	Description
Public	Everyone has Viewer and Editor permissions Only selected people have Admin permissions Default permission level for new members is Admin Server Admins always have permissions to edit access settings On a data source, Server Admins must give themselves Admin permissions to the data source before they can edit other settings
Editing Restricted	Everyone has Viewer permissions Only selected people have Editor and Admin permissions Default permission level for new members is Editor Server Admins always have permissions to edit access settings On a data source, Server Admins must give themselves Admin permissions to the data source before they can edit other settings
Private	Only selected people have permissions Admins can add members with any permission level Default permission level for new members is Viewer Server Admins always have permissions to edit access settings On a data source, Server Admins must give themselves Admin permissions to the data source before they can edit other settings

Permission Inheritance

Data objects inherit privacy modes and permissions by default. Schemas inherit from their parent data source, tables inherit from their parent schema, and columns inherit from their parent table.

With advanced access controls enabled, you can disable inheritance for any schema. If table-level privacy is enabled, you can disable inheritance for any table. When you disable inheritance for a schema or table, it copies all settings from its parent object as a starting point. You can then change the privacy mode and customize permissions for users and groups. With inheritance disabled, the settings on the child object override the settings on the parent object.

Columns always inherit permissions from their parent table. You can’t set permissions for individual columns.

Effects on Other Features

When you limit access to data objects, the following features are affected:

Alation Analytics

• Alation Analytics is always a private data source.

• In addition to the permission levels described above, Alation Analytics has a separate permission level for Queriers. The Querier permission level is higher than an Editor. Queriers have all permissions for lower permission levels. Queriers can also run queries on Alation Analytics. Otherwise, access to Alation Analytics data objects is the same as for other data sources.

• See User Access to Alation Analytics V2 for more information about access to Alation Analytics.

Column Access

• Columns automatically inherit permissions from their parent table.

• You can’t set configure permissions for individual columns.

Compose

• Schemas and tables that are explicitly set to Private mode and aren’t inheriting from their parent won’t appear in Compose SmartSuggest, even for users that have permissions to them. Tables that inherit permissions from a schema that’s explicitly set to Private mode will also not appear in Compose SmartSuggest for any user.

• Users can manually type the name of any data object into their query and run the query on any data object they have database-level access to.

• To prevent exposure of sensitive data, avoid publishing or sharing queries that reference private data objects.

• It may take time for Compose to reflect permission changes. For performance reasons, Compose relies on the cached search index. Alation triggers an update to the search index automatically whenever you change permissions. The update may take some time to complete.

Custom Fields

• To edit a custom field value on a data object, a user must have an appropriate permission level for the object and permission to edit the custom field itself. If their permission level differs between the data object and the custom field, they’ll have the more restrictive permission level.

Object Sets and References

• When editing the value of an object set or reference field, users can only see and select objects they have permission to view.

• Users can see all values on an object set or reference field, even if the value is for an object they don’t have permission to, but they can’t open the object’s catalog page.

• Avoid referencing sensitive objects in object set and reference fields.

Reports

• Analytical Stewardship reports only show objects the user can access. This applies to the:

  • Curation Progress Report

  • Catalog Activity Report

  • Data Objects Without Stewards Report

Search

• When searching in Alation, users will only see data objects they have permission to view.

• It may take time for search results to reflect permission changes. For performance reasons, search relies on the cached search index. Alation triggers an update to the search index automatically whenever you change permissions. The update may take some time to complete.

@-mentions

• Users can only see and select objects they have permission to view when adding an @-mention.

• Users can see @-mentions for objects they don’t have permission to view, but they can’t open the object’s catalog page.

• Avoid referencing sensitive objects in @-mentions.

Best Practices

• Use schema-level permissions when you want to restrict access to all tables in a schema.

• Use table-level permissions for exceptions to schema permissions.

• Regularly review permissions to make sure they remain appropriate.

• Consider using Editing Restricted mode when you want everyone to see the data but limit who can make changes.

• To prevent exposure of sensitive data: - Avoid publishing or sharing queries that reference private tables. - Avoid using sensitive objects in @-mentions, object sets, or reference fields.

Enable Privacy Settings

Use the following instructions to enable advanced access controls and table-level privacy. You can also hide ingested queries if you want to prevent potential exposure of private table names.

Enable Advanced Access Controls

Available in beta from version 2024.3.5

Applies only to Alation Cloud Service on the cloud native architecture

To enable the advanced access controls, contact Alation Support. Our team will enable the feature and migrate your old settings to the new system.

If you experience problems or want to disable schema privacy, contact Alation Support for assistance. We don’t recommend disabling the feature once it’s enabled. To disable the feature, our team will have to migrate your privacy settings back to the old system. We can’t guarantee that your settings will return to the same state as before the feature was enabled.

Enable Table-Level Privacy

Table-level privacy is disabled by default and can be activated by a Server Admin with Alation server access using the alation_conf command and the parameter alation.granular_object_privacy.enabled. When the alation.granular_object_privacy.enabled parameter is set to True, the Settings page is available for every table object in the catalog.

Note

Alation Cloud Service customers can request server configuration changes through Alation Support.

To enable table-level privacy:

1. Use SSH to connect to the Alation server.

2. Enter the Alation shell using the following command:

   sudo /etc/init.d/alation shell
   

3. To see the current value:

   alation_conf alation.granular_object_privacy.enabled
   

4. To set a value:

   alation_conf alation.granular_object_privacy.enabled -s True
   

5. Restart Alation’s web services:

   alation_supervisor restart web:*
   

Hide Ingested Queries

Applies to the Classic User Experience only

Queries that come into the catalog during query log ingestion (QLI) and from Compose produce statement template objects. In the Classic User Experience, these objects are displayed on the catalog page of schema and table objects, under the Queries tab, from the History link. Table privacy is not enforced for statement templates, and they may expose private table names if object permissions for a user are not aligned.

You can hide the History link from the Queries tab of the schema and table catalog page by setting the parameter alation.privacy.hide_statement_templates to True. Note that the parameter applies to all data sources and all table objects.

Note

Alation Cloud Service customers can request server configuration changes through Alation Support.

To hide the History link:

1. Use SSH to connect to the Alation server.

2. Enter the Alation shell using the following command:

   sudo /etc/init.d/alation shell
   

3. To see the current value:

   alation_conf alation.privacy.hide_statement_templates
   

4. To set a value:

   alation_conf alation.privacy.hide_statement_templates -s True
   

Change the Privacy Mode of a Data Source

To change the privacy mode on a data source, you must have one of the following:

• The Source Admin role and Admin (or Data Source Admin) permissions on the data source

• The Catalog Admin role and Admin (or Data Source Admin) permissions on the data source

• The Server Admin role

To change the privacy mode on a data source:

1. Go to the data source’s catalog page.

2. Click the three dots in the top right corner, then Settings. The settings page isn’t available in the New User Experience, so you’ll see a temporary construction page. Click Continue to Classic Experience to open the settings page.

   Click More > Settings.

3. You’ll see the current privacy settings. Choose a privacy mode. See the section on Privacy Modes for definitions of each mode. A confirmation dialog appears when you change the privacy mode. Confirm your choice.

   Note

   If you’re setting the privacy mode to Editing Restricted, and you’ve already given users Viewer permissions, they will be migrated to Editors.

4. If you’ve set the privacy mode to Editing Restricted or Private, add users or groups to grant them permissions:

   1. Click + Add.

   2. Find the user or group you want to add.

   3. Click on a user or group. The user or group is added to the list with the default permission level. See Privacy Modes for more on default permission levels.

5. If the selected settings allow multiple permission levels, you can change a user’s or group’s default permission level by clicking on the dropdown menu in the Access or Access Level column.

The changes you’ve made take place right away, except in search and Compose, which may take some time to reflect the new permissions.

Change the Privacy Mode of a Schema or Table

To change the privacy mode on a schema or table, you must have one of the following:

• The Source Admin role and Admin (or Data Source Admin) permissions on the object or, if inheriting, on its parent

• The Catalog Admin role and Admin (or Data Source Admin) permissions on the object or, if inheriting, on its parent

• The Server Admin role

To change the privacy mode of a schema, advanced access controls must be enabled. To change the privacy mode of a table, table-level privacy must be enabled. See the section on Enable Privacy Settings for instructions.

Schemas and tables inherit their privacy mode from their parent objects by default. To change the privacy mode of a specific schema or table, you must disable permission inheritance from its parent. The schema or table copies all settings from its parent as a starting point. You can then change the privacy mode and customize permissions for users and groups.

To change the privacy mode on a schema or table:

1. Go to the schema’s or table’s catalog page.

2. Click the three dots in the top right corner, then Settings. If you see a temporary construction page, click Continue to Classic Experience to open the settings page.

   Click More > Settings.

3. You’ll see the current privacy settings. By default, permissions inherit from the parent object and aren’t editable.

   Note

   If you don’t see the schema’s or table’s current privacy settings, ensure that you have the correct role and permissions and that you’ve enabled advanced access controls or table-level privacy.

4. If advanced access controls are enabled, disable the toggle for Inherits permissions from parent. If only basic access controls are enabled, select the checkbox for Enable explicit permissions on this object (this object will retain its access settings if the parent changes.). The privacy settings become editable. The object copies all permissions from its parent as a starting point.

5. Choose a privacy mode. See the section on Privacy Modes for definitions of each mode. A confirmation dialog appears when you change the privacy mode. Confirm your choice.

   Note

   If you’re setting the privacy mode to Editing Restricted, and you’ve already given users Viewer permissions, they will be migrated to Editors.

6. If you’ve set the privacy mode to Editing Restricted or Private, add users or groups to grant them permissions:

   1. If advanced controls are enabled, click the + Add Users/Groups button. If only basic access controls are enabled, click the plus (+) button.

      Click + Add Users/Groups, or + Add Users if only basic access controls are enabled.

   2. Find the user or group you want to add.

   3. Click on a user or group. The user or group is added to the list with the default permission level. See Privacy Modes for more on default permission levels.

7. If the selected settings allow multiple permission levels, you can change a user’s or group’s default permission level by clicking on the dropdown menu in the Access or Access Level column.

The changes you’ve made take place right away, except in search and Compose, which may take some time to reflect the new permissions.

Manage User Permission Levels for a Data Source

To change user permission levels, you must have one of the following:

• The Source Admin role and Admin (or Data Source Admin) permissions on the object or, if inheriting, on its parent

• The Catalog Admin role and Admin (or Data Source Admin) permissions on the object or, if inheriting, on its parent

• The Server Admin role

To manage user permissions for a data source:

1. Go to the data source’s catalog page.

2. Click the three dots in the top right corner, then Settings. If you see a temporary construction page, click Continue to Classic Experience to open the settings page.

   Click More > Settings.

3. You’ll see the current privacy settings. You can add users or groups to grant them permissions, change their permission levels, or remove them:

   • To add users or groups:

     1. If advanced access controls are enabled, click the + Add Users/Groups button. If only basic access controls are enabled, click the + Add button.

     2. Find the user or group you want to add.

     3. Click on a user or group. The user or group will be added to the list with the default permission level. See Privacy Modes for more on default permission levels.

   • To change a user’s or group’s permission levels, click on the dropdown menu in the Access or Access Level column. Some privacy modes allow only one permission level.

   • To remove users or groups, click Remove for the user or group you want to remove.

     Note

     You can’t remove the last Admin from an object.

The changes you’ve made take place right away, except in search and Compose, which may take some time to reflect the new permissions.

Manage User Permission Levels for a Schema or Table

For schemas and tables that are set to Editing Restricted or Private, you can add and remove users and groups and change their permission levels.

To change user permission levels, you must have one of the following:

• The Source Admin role and Admin (or Data Source Admin) permissions on the object or, if inheriting, on its parent

• The Catalog Admin role and Admin (or Data Source Admin) permissions on the object or, if inheriting, on its parent

• The Server Admin role

To change the privacy mode of a schema, advanced access controls must be enabled. To change the privacy mode of a table, table-level privacy must be enabled. See the section on Enable Privacy Settings for instructions.

To manage user permissions:

1. Go to the schema’s or table’s catalog page.

2. Click the three dots in the top right corner, then Settings. If you see a temporary construction page, click Continue to Classic Experience to open the settings page.

   Click More > Settings.

   Note

   If you don’t see the schema’s or table’s current privacy settings, ensure that you have the correct role and permissions and that you’ve enabled advanced access controls or table-level privacy.

3. You can only manage permissions for schemas and tables that are set to Editing Restricted or Private. You can add users or groups to grant them permissions, change their permission levels, or remove them:

   • To add users or groups:

     1. If advanced access controls, click the + Add Users/Groups button. If only basic access controls are enabled, click the plus (+) button.

        Click + Add Users/Groups, or + Add Users if only basic access controls are enabled.

     2. Find the user or group you want to add.

     3. Click on a user or group. The user or group will be added to the list with the default permission level. See Privacy Modes for more on default permission levels.

   • To change a user’s or group’s permission levels, click on the dropdown menu in the Access column. Some privacy modes allow only one permission level. You can’t change permission levels on tables when only basic access controls are enabled.

   • To remove users or groups, click Remove for the user or group you want to remove.

     Note

     You can’t remove the last Admin from an object.

The changes you’ve made take place right away, except in search and Compose, which may take some time to reflect the new permissions.