Use Cases: Creating Roles & Policies in OpenMetadata

OpenMetadata comes with default configurations such as the Organization Policy and Data Consumer Roles. These roles are setup to foster data collaboration.

We advise retaining the Organization policy, which enables everyone to view the assets and claim ownership when no owner is specified.

For individual teams, tailor your policies according to the specific needs of both the organization and the team. You may choose to adopt stricter policies as detailed in the previous sections.

Use Case 1: We want our teams to be able to create services and extract metadata

You can create a policy with DatabaseService, Ingesiton Pipeline, and Workflow resources with All operations set to allow.

Allow All Operations

You can create a Role such as ServiceOwner role and assign the above policy. Once the role is created, you can assign it to users to enable service creation by themselves without the need for an Admin.

Use Case 2: Roles for Data Steward

A data steward in OpenMetadata should be able to create Glossaries and Glossary Terms and be able to view all data and manage it for governance purposes.

Here is an example of a policy to enable it for Data Stewards using two rules.

1. Allow Glossary Operations: Enables the policy to allow operations on all Glossary related actions.
2. Edit Rule: Grants access to the Data Steward to edit description, edit tags on all entities; enabling the user to manage the data.

You can fine tune these permissions to suit your organizational needs.

Roles for Data Steward

Use Case 3: Only the team that owns the data asset should be able to access it

To safeguard the data owned by a specific team, you can prevent external access.

The above rule specifies to deny all operations if the logged-in user is not the owner, or if the logged-in user’s team is not the owner of an asset.

Team Only Policy

Use Case 4: Deny all the access if the data asset is tagged with PII.Sensitive and allow only the owners

Just like the above policy, you can create a rule with complex conditions as shown below

PII Sensitive Tag Policy

In this rule, we are specifying to deny operations if the table tag contains PII.Sensitive tag and if the logged-in user is not the owner, or their team is not the owner of the Table.

Use Case 5: Restrict User Account Access to a Specific Service/Database

To restrict a user account to only see data from one specific service/database, you can create a policy that includes rules to allow access to the desired service and deny access to others. This involves setting up policies with specific conditions based on the service name. The following steps outline how this can be done using the API:

1. Create a Policy: Define a policy that allows access to the specific service.
2. Assign the Policy: Assign this policy to the user or role.

Example Policy:

By implementing this policy, the user account will be restricted to access only the specified service, enhancing data security and ensuring that users can only view the data they are authorised to see.