Govern Security: Roles and Permissions

Note

This section only applies to Dataiku Govern

Roles and Permissions are two distinct notions that Dataiku Govern uses to configure who can do what on Govern objects and fields.

Roles are created at Govern instance level. They are different from the Users and Groups that come from the LDAP. The LDAP Users and Groups are usually based on the company structure and so may differ from the intended usage and associated permissions needed in Govern.

By using Roles instead of directly using LDAP Users and Groups in the permissions configuration, we can dynamically assign a role to LDAP Users or Groups, based on any combinations of rules and criteria, making for a highly flexible permissions system.

In action, the permission system will work this way:

  • The user wants to perform an action that is permission-locked

  • We need to compute the user’s effective permissions in the context of this action. The effective Permissions computation process always has two steps :

    1. Roles assignation: Given the Roles assignments rules, compute the set of Roles a given user has, in the context of this action

    2. Permissions computation: Given this set of roles and the permissions configuration, compute the effective permissions on the Govern object

  • Based on the effective permissions, the user is allowed, or not allowed, to perform the action

This Permissions computation process includes multiple Govern layers. The following layers are considered:

  • Blueprint: a category of objects (example: a Govern Project)

  • Blueprint Version: the template/schema for objects; it contains the field definitions, workflows definitions, etc. (example: a specific template for Govern Projects, with 5 workflow steps. Another Blueprint Version for Govern Projects might have a template with 9 workflow steps, perhaps for projects on teams with many regulatory requirements.) A Blueprint can contain multiple Blueprint Versions that can be seen as variants, with slight variations in their content.

  • Artifact: this is the effective object. It contains the fields that are defined in the Blueprint Version and that users can fill in. (Example: a Govern Project for “North America Fraud Detection”)

The Roles assignment rules and configuration for Permissions are stored at the Blueprint level.

Note: this permissions system won’t apply in the admin restricted configuration pages, like the Blueprint Designer page or the Permissions configuration page.

Effective Permissions

Effective permissions represent what a user can actually do in Govern. Effective permissions are slightly different from the Permissions configuration because some of the permissions are not configurable but will be induced.

Effective Permissions at the Artifact level

  • Read permission: the user is allowed to see that the Artifact exists, its name, its workflow status

  • Write permission: the user is allowed to edit the Artifact

  • Create permission: the user is allowed to create a new Artifact

  • Delete permission: the user is allowed to delete the Artifact

For each field:

  • Read permission: the user is allowed to see the field value

  • Write permission: the user is allowed to write the field value

Note: if the user doesn’t have the Artifact Read permission, the user can’t have any Field Read permissions.

Effective Permissions at the Blueprint Version level

At Blueprint Version level, we will consider the following permissions :

  • Read permission: Allow a user to see that the Blueprint Version exists, its name, its workflow definition.

  • Write permission: Allow a user to edit the Blueprint Version

Effective Permissions at the Blueprint level

At the Blueprint level, we will consider the following permissions :

  • Read permission: Allow a user to see that the Blueprint exists, its name, its icon.

  • Write permission: Allow a user to edit the Blueprint

Roles Assignments Rules

For each Role, we can set a list of Rules. For the Role to be assigned, at least one Rule must be valid.

A Rule contains a list of criteria (conditions). For a Rule to be valid, all the criteria must comply.

The logic is to always add Roles. If a Rule is valid, the user will have the associated Role. There is no way to create exceptions to the rules to remove the Role afterward.

Possible Choices for Criteria

  • Blueprint Version criterion:

    • restricts the Role assignment to one specific Blueprint Version

    • restricts the Rule to be valid only in the context of an action involving a Blueprint Version

  • Field value criterion:

    • restricts the Role assignment based on a field value. Multiple operators exist, such as Equals or Contains

    • restricts the Rule to be valid only in the context of an action involving an Artifact

  • Workflow criterion:

    • restricts the Role assignment based on the active step in the workflow

    • restricts the Rule to be valid only in the context of an action involving an Artifact

  • No criterion:

    • doesn’t restrict the Rule at all

Objects involved by Actions

All the actions below have their corresponding permission.

Action

Blueprint involved

Blueprint Version involved

Artifact involved

Blueprint Read

Blueprint Write

Blueprint Version Read

Blueprint Version Write

Artifact Create

Artifact Read

Artifact Write

Artifact Delete

Field Read

Field Write

As a result, it would be inconsistent to create a Rule restricted by a Field Value criterion that would create a Role with permission to Create an Artifact. This is because the Field Value criterion requires the specification of an Artifact to which the Role is relevant - this could never grant a “Create Artifact” permission because that action doesn’t involve an existing Artifact.

An action involving an Artifact can validate more criteria than an action involving only a Blueprint and can defacto unlock more Roles to the user.

Roles Inheritance

Roles inheritance is here to help to centralize Roles assignment Rules when they are the same for multiple objects.

Blueprint Inheritance

We can inherit Roles from another Blueprint by adding a Blueprint reference in the “inherit from blueprint” selector. In this case, all the Rules of the inherited Blueprint will be evaluated, and the granted Roles will be added to the user’s set of Roles. Note that only the Rules which contain no criteria can be valid for inheritance, because all criteria need a Blueprint Version or an Artifact to be specified, so they will not be valid in this new Blueprint which is inheriting them.

Artifact Inheritance

We can inherit Roles from another Artifact by configuring a field ID in the “inherit from artifact field reference”. When evaluating Roles, if this configuration entry contains a valid field ID, and if the field contains a valid Artifact reference, we will compute Roles assignments in the context of the referenced Artifact. All outputted roles will be added to the user’s set of Roles.

Permissions Computations

The Permissions are configured at the Blueprint level so each Blueprint can have its own configuration.

Note : All permissions will be granted to Govern admins.

Artifact Permissions

Configuration per Role

Artifact Read, Write, Create and Delete permissions are configured at Blueprint level, per Role, by the Govern admin. Granting any of the Artifact Write, Create and Delete permissions automatically also grants the Artifact Read permission.

Field Read and Field Write permissions are configured at Blueprint level, per field and per Role, by the Govern admin. Granting the Field Write permission automatically also grants the Field Read permission.

For a given Role, if a given field has not been specified in the configuration, the computation mechanism will fall back on the two values “Fields default read permission” and “Fields default write permission”.

Configuration for Everyone

It is possible to create a permission configuration for everyone - these permissions will be granted even to users with no assigned Roles.

The tool to configure permissions for “everyone” contains the same configuration as the configuration for specific roles, that is:

  • Artifact Read, Write, Create and Delete permissions

  • Field Read and Field Write permissions, per field

  • “Fields default read permission” and “Fields default write permission”

Beware: if the “Fields default read permission” is activated in this everyone block, every Field that is not specified to require Role configuration (in this everyone block) will be readable by everyone. The same applies to the “Fields default write permission”.

Blueprint Version Permissions

In most cases, users won’t interact directly with Blueprint Versions; instead they interact with the Artifacts that are generated based on the template from the Blueprint Version.

That’s why Blueprint Version permissions can’t be configured; they are computed based on the user’s Artifact permissions:

  • Any Artifact permission (Read, Write, Create, Delete) will imply the Blueprint Version Read permission automatically (it wouldn’t make sense to read values without their definitions)

  • The Blueprint Version Write permission will never be given to a standard user; only Govern admins can edit Blueprint Versions.

Note : If the user doesn’t have permission to read a specific field, the details of that particular field will be filtered out from the relevant Blueprint Version.

This logic doesn’t apply to administration pages like the Blueprint Designer, where the Govern admins need to access directly Blueprint Versions without going through an Artifact. As we said earlier, pages that are restricted to only Govern admins (like the Blueprint Designer) are not subject to the roles and permissions computation system.

Blueprint Permissions

With the same logic as Blueprint Versions, users won’t generally need access directly to a Blueprint. They will mostly get the Blueprints through the Blueprint Versions.

Blueprint permissions can’t be configured; they are computed based on the user’s Blueprint Version permissions :

  • any Blueprint Version permission (Read, Write) will imply the Blueprint Read permission automatically.

  • The Blueprint Write permission will never be given to a standard user; only Govern admins can edit Blueprints.

Default Permission Configuration

If a Blueprint doesn’t have a Permission Configuration, the system will fall back on the Govern instance default Permissions configuration. This default configuration is optional; if it also doesn’t exist, no permission can be granted on the Blueprint and descendant.

As soon as a Blueprint has a Permissions configuration, even an empty one, the default configuration is not used at all.

Permissions Configuration Inheritance

Permissions configuration inheritance does not exist; Govern supports only Roles assignments inheritance.

Direct access to a Blueprint or Blueprint Version

To directly access a Blueprint or a Blueprint Version, a user should have a Role granting any Artifact permission, but this Role must come from:

  • a Rule with no criteria for a Blueprint

  • a Rule with either no criteria or a Blueprint Version criterion for a Blueprint Version