How do I control access to metadata and data?

You can customize access for users through several mechanisms.

User roles

The most general mechanism is a user role. These define the very broad permissions a user has in Atlan — for example, whether they can administer other users, or only discover metadata. When it comes to what metadata and data a user can access, though, we need to use the additional mechanisms below.

Connection admins

Connection admins are users who manage connectivity to a data source. By default, these users can:

• Read and write all metadata on assets from that connection.
• Preview and query the data in all data assets from that connection.
• Manage access policies to grant others access to the assets from that connection.

You define the connection admin when crawling a new data source for the first time. A connection admin can also extend the list of connection admins on their connection at any time.

Access policies

Access policies either allow or restrict access to certain assets. These allow you to be much more creative (and granular) about access than the all-or-nothing privileges of connection admins.

You start by defining which assets to control with each policy. There are two complementary mechanisms to do this in Atlan — personas and purposes.

Once you have defined the subset of assets, you can then define granular access to both metadata and data:

Metadata policies

Metadata policies control what users can do with the assets' metadata. Through them, you can control who can:

• Read: view an asset's activity log, custom metadata, and SQL queries
• Update: change asset metadata, including description, certification, owners, README, and resources
• Update Custom Metadata Values for the assets
• Add Tags to the assets
• Remove Tags from the assets
• Add Terms to the assets
• Remove Terms from the assets
• Create: create new assets within the selected connection (via API)
• Delete: delete assets within the selected connection (via API)

Data policies

Data policies control what users can do with the assets' data. Through them, you can control who can:

• Query and preview the data within the assets
• Whether to hide any data, through various masking techniques:
  • Show first 4: replaces all the data with X except the first 4 characters of data. For example 1234 5678 9012 3456 would become 1234XXXX.
  • Show last 4: replaces all the data with X except the last 4 characters of data. For example 1234 5678 9012 3456 would become XXXX3456.
  • Hash: replaces the data with a consistent hashed value. Because the hash is consistent you can still join on it across assets. For example 1234 5678 9012 3456 would become f43jknscakc12nk21ak.
  • Nullify: replaces the data with the null value. For example 1234 5678 9012 3456 would become null.
  • Redact: replaces all alphabetic data with x and all numeric data with 0. For example 1234 Street Name would become 0000 Xxxxxx Xxxx.

Glossary policies

Glossary policies control what users can do with glossary metadata — terms and categories. Through them, you can control who can do the following against each glossary:

• Read permission on terms, categories, and glossaries exists by default and cannot be modified. Glossary policies do not restrict users from viewing any glossary and its contents within the Glossary section.
• Create terms and categories inside the glossary
• Update descriptions, certification, owners, READMEs, and resources for the glossary, terms and categories
• Link terms in the glossary with all other assets
• Delete terms and categories inside the glossary
• Add tags to the terms
• Remove tags from the terms
• Update custom metadata values for the terms and categories inside the glossary

Glossary policies can only be defined through personas.

Interactions

All the mechanisms above can coexist. This is powerful, but can also be a bit overwhelming to think about. What takes priority when a user is under the control of all these mechanisms? 😵‍💫

It's actually not as bad as you might think — only these three rules:

Access is denied by default (implicitly)

By default, users will not have the permissions listed above. This remains true until you explicitly grant a user a permission.

For example, imagine you have not set up any access policies and a new user joins.

• They will not have any of the permissions above against any assets in Atlan.

Explicit grants (allows) are combined

When you grant a user a permission, this is combined with all other permissions you have granted the user.

Continuing our example, imagine you add the new user to a group defined as the connection admins for Snowflake.

• The user will now have full read/write access to all metadata for Snowflake assets, and be able to query and preview the data in those assets.

Then you add the user to a persona that gives read/write access to a Looker project.

• The user will now have access to all Snowflake assets and a Looker project's assets.

Explicit restrictions (denies) take priority

Continuing our example, imagine you define a purpose with a data policy that masks PII data.

• The user will still have full read/write access to all metadata for Snowflake assets and a Looker project's assets.
• In general, they will still be able to query and preview the data in the Snowflake assets.
• However, any PII data in Snowflake will now be masked.

Then you add a metadata policy to the purpose that denies permission to remove the PII tag.

• The user will no longer have full read/write access to all metadata for Snowflake assets and a Looker project's assets.
• The user can no longer remove the PII tag from any of these assets.