As pipelines are being built, an administrator needs to delegate access rights. Delegation involves the use of environment groups, and is a multi-layered process.
Layer 1 will always involve granting the environment group access to the environment in which the pipeline resides. For more information, see Assigning environment groups to environments.
Layer 2 involves granting the environment group permissions to the pipeline.
Layer 3 involves delegating rights to the individual data stages that comprise the pipeline.
There are two options for delegating permissions to data stages at Layer 3, and numerous ways these options can be combined.
Inheriting security from a parent
By default, data stages with parents will inherit the security settings of the their parent. This setting is found within every data stage's Security tab, and it can be accessed when creating the data stage or editing it.
Customizing security
Pipeline security can also be customized, by item. For example, you could create a pipeline containing two paths and grant different rights to different environment groups for each path.
Custom security can be applied to any data stage. This option is found within a data stage's Security tab, and it can be accessed when creating the data stage or editing it.
When customizing security, the system will detect two common issues:
-
Read permission is being granted to environment groups, but those groups don't have Read permission to parent paths or the pipeline. To solve this issue, the system will offer to add the following permissions:
-
Read Data permission is being granted to environment groups, but those groups don't have Read Data permission to stages that the current stage references. To solve this issue, the system will offer to add the following permission:
How inheritance and customization interact
By default, data stages will always inherit the rights of their nearest parent. This means that, sometimes, the custom permissions of one parent can overwrite the custom permissions of another. For example:
"Environment Group A" has permission to access "Pipeline 1".
Within Pipeline 1, "Path 1" and "Dashboard 1" inherit the permissions from Pipeline 1, meaning that Environment Group A can also access these data stages.
However, if permissions are also set at the path level, then this overwrites the permissions set at the pipeline level, meaning that Environment Group A would not have access to Path 1, unless this was explicitly assigned.
Examples of delegating rights
Example 1
A basic pipeline, where everything is in one path and there is no need to delegate rights by item. Therefore, granting users access would only involve two layers:
- An environment group has access to the environment.
- The environment also has permissions to the pipeline, for example Write, Create Data Store, Create Data View and Create Dashboard.
Example 2
A pipeline with separate paths, "Path A" for users who are responsible for data stores and data views, and "Path B" for users who build dashboards:
- There are two environment groups ("Environment Group 1" and "Environment Group 2"). Both environment groups have access to the environment in which the pipeline resides.
- Both environment groups have Read access to the pipeline.
- The appropriate rights are delegated to each path within the pipeline.
- On Path A, Environment Group 1 has Write, Create Data Store and Create Data View permissions. Environment Group 2 only has Read and Read Data permissions on this path. This gives Environment Group 2 Read and Read Data access to the data view contained within Path A, allowing them to build dashboards.
- On Path B, Environment Group 1 only has Read and Read Data permissions, whereas Environment Group 2 has Write and Create Dashboard permissions.
Example 3
Two pipelines (Pipeline A and Pipeline B) to separate data stages:
- There are two environment groups ("Environment Group 1" and "Environment Group 2"). Both environment groups have access to the environment in which the pipelines reside.
- Environment Group 1 has an appropriate set of permissions to Pipeline A and Environment Group 2 has a different set of permissions to Pipeline B.
- To enable Environment Group 2 to create dashboards, Read and Read Data access is granted to Pipeline A because it contains the required data view.
- Environment Group 1 does not have any permissions on Pipeline B, so its members will not be able view any dashboards residing there.