How do I control access to metadata and data?

Have more questions? Submit a request

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

πŸ€“ Who can do this? A user must be both an admin user and a connection admin to define access policies for the connection's assets.

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:

  • View an asset's activity log, lineage, custom metadata, and SQL queries
  • Update asset metadata including description, certification, owners, readme and resources
  • Update custom metadata values for the assets
  • Add classifications to the assets
  • Remove classifications from the assets
  • Add terms to the assets*
  • Remove terms from the assets*
  • Create new assets within the selected connection (via API)
  • Delete assets within the selected connection (via API)

* These policy permissions are only available within personas.

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:

  • Create terms and categories inside the glossary
  • Update descriptions, certification, owners, readme 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 classifications to the terms
  • Remove classifications 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

🚨 Careful! When you explicitly deny a user a permission, this takes priority over all other permissions you have granted the user.

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 classification.

  • 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 classification from any of these assets.
πŸ’ͺ Did you know? The combination of mechanisms in the example above shows their power. Through a small number of controls we can define wide-ranging but granular access permissions.

Related articles

Was this article helpful?
1 out of 1 found this helpful