Who Can Manage Tags?¶

Access to tag namespaces can be controlled like other objects in the system. ATTRIBUTE NAMESPACE is an object level that sits under catalog. You can grant CREATE, DROP, ADD_ATTRIBUTE, REMOVE_ATTRIBUTE, or ALL permission levels on tag namespaces. If a user has any of these permissions for a tag namespace, they can see the tags on the Tags page.

CREATE - Users can only create tags inside the specified tag namespace. Users who do not have permissions to create tags will not see the button on the Tags page in the UI. And if they do not have permissions to create tag namespaces, they cannot create tag namespaces in the UI.
DROP - Users can only drop tags inside the specified tag namespace. Users who do not have permissions to drop tags will not see the option on the Tags page in the UI.

Note: Tag namespaces cannot be dropped. A namespace only exists if at least one tag in that namespace exists.
ADD_ATTRIBUTE - Users can only assign tags inside the specified tag namespace to data for which they have permission to add tags. Users can only select tag namespaces for which they have privileges.
REMOVE_ATTRIBUTE - Users can only remove or unassign tags from catalog objects for data for which they have permission to drop tags. Users can only select tag namespaces for which they have privileges.
ALL - User can create, drop and assign tags inside the specified tag namespace.

For example if you wanted to give access to a role to create, drop and assign tags from a particular tag namespace, you would use the following SQL:

GRANT ALL on ATTRIBUTE NAMESPACE marketing TO ROLE marketing_steward;

Control Who Can Manage Tags on Objects¶

To assign tags to an object (i.e a database, dataset or column), the user must have:

ALL or ADD_ATTRIBUTE and REMOVE_ATTRIBUTE permissions for the data to which they want to assign tags. To grant a role the ability to assign a tag on an object, you must grant both ADD and REMOVE permissions.
ALL or ADD_ATTRIBUTE for the tag namespace to which they wish to assign tags.

If you only grant #1 without #2, then the user will not have any tags available to assign, since they have not been granted access to any tag namespaces.

To remove tags from an object, the user must have:

ALL or ADD_ATTRIBUTE and REMOVE_ATTRIBUTE permissions for the data for which they want to remove tags. To grant a role the ability to remove a tag on an object, you must grant both ADD and REMOVE permissions.
ALL or REMOVE_ATTRIBUTE for the tag namespace to which they wish to remove tags.

As an example, here's how you could set up a data steward who can only assign tags from the marketing tag namespace, on data inside the marketingdb database:

GRANT ALL on ATTRIBUTE NAMESPACE marketing TO ROLE marketing_steward;
GRANT ALL on DATABASE marketing TO ROLE marketing_steward;

Here's a more granular way of achieving the same use case, the only difference is the marketing steward does not have ALL access to the database here, so we have to give them permissions to add and remove tags on the data.

GRANT ALL on ATTRIBUTE NAMESPACE marketing TO ROLE marketing_steward;
GRANT ADD_ATTRIBUTE ON TABLE okera_sample.sample TO ROLE marketing_steward;
GRANT REMOVE_ATTRIBUTE ON TABLE okera_sample.sample TO ROLE marketing_steward;

Example of Tag Permissions¶

Below is an example of granting permissions for managing tags to a marketing data steward.

CREATE ROLE marketing_steward_role;
GRANT ROLE marketing_steward_role to group marketing_steward_group;

-- Marketing steward will be able to assign tags on the marketing database 
-- since they have ALL access on it
GRANT ALL ON DATABASE marketing TO ROLE marketing_steward_role;

-- Marketing steward will be able to create, drop and assign tags
-- only from the marketing tag namespace 
GRANT ALL on ATTRIBUTE NAMESPACE marketing TO ROLE marketing_steward_role;