Permissions

Permissions determine the access level that users have on objects. When permission enforcement is enabled for your organization, you can share and grant permissions on objects.

When you create an object, you become the owner of that object and have full access to the object. By default the object is private, and can only be seen by the owner and by any user with the Organization Administrator role. A user with the Organization Administrator role has full access to all objects in the organization.

An object owner or a user with the Organization Administrator role can share the object. When you share an object, you grant others one or more of the following access levels:
  • Read - Ability to find, open, and view the object. Ability to export the object.
  • Write - Ability to edit and save the object.
  • Execute - Ability to start and stop the object.

You can share objects with both users and groups. If you share an object with a user and also share the same object with a group that the user belongs to, the user has the union of all permissions.

Changes to permissions take effect the next time the user logs in.

If needed, the object owner or Organization Administrator can change the owner of the object. You can also disable permission enforcement for your organization if you want all users to have full access to all objects.

To perform Control Hub tasks, you must have the appropriate object permissions as well as the role associated with the task. For example, if you have the Job Operator role, you can delete a job only when granted write permission on the job.

Example

The user Rita publishes a pipeline to Control Hub and then creates a job for the pipeline. She becomes the owner of the pipeline and job. She has full access to the pipeline and job and can grant other users and groups permission on these objects.

Rita wants to share the pipeline and job with her co-workers in the NorthernRegion group, granting the group full access to both objects. Miguel is not a member of the NorthernRegion group and so does not need full access to the objects. However, he does need read access on the pipeline and job to monitor them. So Rita also shares the pipeline and job with Miguel, granting him read access to both.

Let's look at the Sharing Settings window for the job in this example:

Note how the window designates Rita as the owner, and note the Is Owner icon () that displays in the row for Miguel. Rita or a user with the Organization Administrator role can click the icon to make Miguel the owner of the object. As the owner, Miguel would then have full access to the object.

The Sharing Settings window does not list the users that have the Organization Administrator role. However, remember that all users who have the Organization Administrator role have full access to all objects and can grant others permission on the objects.

Enabling and Disabling Permission Enforcement

By default, permission enforcement is enabled for your organization to secure the integrity of your data.

Disable permission enforcement if you want all users to have full access to all objects. When permission enforcement is disabled, you can still assign permissions. However, Control Hub does not enforce the permissions until you enable enforcement.

  1. In the Navigation panel, click Manage > My Organization.
  2. Click Advanced.
  3. On the Configuration window, select the Enforce permissions during object access property to enable permission enforcement. Clear the property to disable permission enforcement.
  4. Click Save.

Connection Permissions

When you share a connection, you can grant users and groups the following access levels to the connection:
  • Read - View the connection name and description in the Connections view, but cannot view the values of any other connection properties. Use the connection in a pipeline or pipeline fragment. Start jobs for pipelines that use the connection.
  • Write - Edit and delete the connection. Can view the values of all connection properties.

As with pipelines, if you modify the permissions of a connection that is included in a pipeline in an active job, the changes do not affect the active job until the job is stopped and restarted.

Data SLA Permissions

When you share a data SLA, you can grant users and groups the following access levels to the data SLA:

  • Read - View the data SLA within the topology. View and acknowledge the triggered data SLA alert in the Alerts view. Viewing the data SLA within the topology also requires read access on the topology and on all jobs included in the topology.
  • Write - Edit and delete the data SLA. Also requires read access on the topology and on all jobs included in the topology.
  • Execute - Activate or deactivate the data SLA. Also requires read access on the topology and on all jobs included in the topology.

Deployment Permissions

Deployment permissions determine the access level that users have on deployments and also the access level that users have on all engines managed by the deployment.

Note: For a description of permissions for legacy Kubernetes deployments, see Legacy Deployment Permissions.

Engines inherit the permissions assigned to the deployment. For example, if you grant a user Execute permission on a deployment, that user also has Execute permission on all engines managed by that deployment.

Engines automatically inherit all permission changes on the parent deployment. You do not need to restart engines for the changed deployment permissions to take effect.

When you share a deployment, you can grant users and groups the following access levels to the deployment and to all engines managed by the deployment:
  • Read - View the details of the deployment and of all engines managed by the deployment. Restart or shut down individual engines managed by the deployment in the Engines view.
  • Write - Edit, start, stop, and delete the deployment. Delete engines managed by the deployment. Also requires read access on the parent environment.
  • Execute - Start jobs on engines managed by the deployment. Starting jobs also requires execute access on the job and read access on the pipeline.

Environment Permissions

When you share an environment, you can grant users and groups the following access levels to the environment:
  • Read - View the details of the environment. Create and edit a deployment for the environment.
  • Write - Edit, activate, deactivate, and delete the environment.

Job Permissions

When you share a job, you can grant users and groups the following access levels to the job:
  • Read - Monitor the job. Also requires read access on the pipeline and read access on all appropriate engines with the assigned labels.

    For example, to monitor a job that runs a Transformer pipeline, users require read permission on the job, the pipeline, and on all Transformers assigned the same labels as the job.

  • Write - Edit and delete the job. Editing a job also requires read access on the pipeline.
  • Execute - Start, synchronize, and stop the job. Also requires read access on the pipeline and execute access on all appropriate engines with the assigned labels. Reset the origin for the job. Also requires read access on the pipeline.

    For example, to start, synchronize, or stop a job that runs a Data Collector pipeline, users require execute access on the job, read access on the pipeline, and execute access on all the Data Collectors assigned the same labels as the job. To reset the origin for a job, users require execute access on the job and read access on the pipeline.

Note: Job instances created from job templates can optionally be configured to inherit all permissions assigned to the parent job template. You can modify the inherited permissions or share the job instances with additional users and groups.

When you start a job, Control Hub sends an instance of the pipeline to each appropriate engine. As the engine runs the pipeline, the pipeline inherits the Control Hub job permissions.

If you change the permissions on an active job, those changes affect the active job and the pipelines running from the job. For example, let's say that another user needs to monitor an active job on Data Collector. You can modify the permissions on the active job, granting that user read access. The user can then monitor the job in Control Hub and the pipeline run from the job in Data Collector. You do not need to stop and restart the job for the changed permissions to take effect.

Job Template Permissions

When you share a job template, you can grant users and groups the following access levels to the template:
  • Read - View the job template configuration details. Export the job template.
  • Write - Edit, archive, and delete the job template. Editing a job template also requires read access on the pipeline.
  • Execute - Create and start job instances from the template. Also requires read access on the pipeline and execute access on all appropriate engines with the assigned labels.

Legacy Deployment Permissions

Legacy deployment permissions determine the access level that users have on legacy deployments and also the access level that users have on all Data Collectors provisioned with the deployment.

Note: Legacy deployments are included with legacy Kubernetes integration which is enabled only for some accounts.

When provisioned Data Collectors are registered with Control Hub, they inherit the same permissions assigned to the legacy deployment. For example, if you grant a user Execute permission on a legacy deployment, that user also has Execute permission on all Data Collectors provisioned by that deployment.

After provisioned Data Collectors are registered, users with the Organization Administrator role can modify the permissions on any provisioned Data Collector from the engine details page. As a result, Data Collectors provisioned by the same deployment can be granted different permissions.

When you share a legacy deployment, you can grant users and groups the following access levels to the deployment and to Data Collectors provisioned with the deployment:

  • Read - View the details of the legacy deployment and of all Data Collectors provisioned with the legacy deployment.
  • Write - Edit and delete the legacy deployment. Assign labels to all Data Collectors provisioned with the legacy deployment.
  • Execute - Scale, start, and stop the legacy deployment. Start jobs on all Data Collectors provisioned with the legacy deployment - also requires execute access on the job and read access on the pipeline.

Pipeline Fragment Permissions

When you share a pipeline fragment, you can grant users and groups the following access levels to the fragment:
  • Read - View the fragment configuration details and version history. Use the fragment in a pipeline. Export the fragment.
  • Write - Design and publish the fragment. Create and remove tags for the pipeline. Delete fragment versions. Publish an updated version of the fragment.

Fragment permissions apply to all versions of the fragment.

As with pipelines, if you modify the permissions of a fragment that is included in a pipeline in an active job, the changes do not affect the active job until the job is stopped and restarted.

Here's how fragment permissions are used when exporting and importing fragments:

Export fragments
When you export a fragment from Control Hub, Control Hub does not retain existing permissions with the exported fragment. Assign permissions to the fragment as needed after import.
Import fragments
When you import a fragment into Control Hub, you become the owner of the fragment in Control Hub. The fragment is private to you. You can use Control Hub to share the fragment with others.

Pipeline Permissions

Pipeline permissions determine the access level that users have on pipelines and also the access level that users have on the draft run started for the pipeline.

When you share a pipeline, you can grant users and groups the following access levels to the pipeline:
  • Read - View the pipeline configuration details and pipeline version history. Create a job for the pipeline. Export the pipeline.
  • Write - Design and publish the pipeline. Create and remove tags for the pipeline. Delete pipeline versions.

Pipeline permissions apply to all versions of the pipeline.

If you modify the permissions of a pipeline that is included in an active job, the changes do not affect the active job until the job is stopped and restarted. For example, let's say that you have read access on the Social Feeds pipeline. You create and start a job for the pipeline. Then, the pipeline owner removes all of your permissions on the pipeline. You can no longer create or start jobs for the Social Feeds pipeline. However, the job that you previously started for the pipeline continues to be active and you can continue to monitor the job until it is stopped and restarted.

Provisioning Agent Permissions

When you share a Provisioning Agent, you can grant users and groups the following access levels to the Provisioning Agent:

  • Read - View the details of the Provisioning Agent.
  • Write - Delete a Provisioning Agent from Control Hub after running the appropriate Kubernetes command to delete the Provisioning Agent application from your Kubernetes cluster.
  • Execute - Not used at this time.
Note: Provisioning Agents are included with legacy Kubernetes integration which is enabled only for some accounts.

Scheduled Task Permissions

When you share a scheduled task, you can grant users and groups the following access levels to the task:
  • Read - View and monitor the scheduled task.
  • Write - Edit the scheduled task.
  • Execute - Pause, resume, kill, or delete the scheduled task.

Sequence Permissions

When you share a sequence, you can grant users and groups the following access levels to the sequence:
  • Read - View and monitor the sequence.
  • Write - Edit the sequence, including enabling and disabling the sequence.
  • Execute - Manually run the sequence.

Subscription Permissions

When you share a subscription, you can grant users and groups the following access levels to the subscription:
  • Read - View the subscription.
  • Write - Edit, enable, disable, and delete the subscription.

Topology Permissions

When you share a topology, you can grant users and groups the following access levels to the topology:
  • Read - View the mapped systems and jobs in the topology canvas. View statistics and monitoring details for the topology. Also requires read access on all jobs and pipelines included in the topology.
    Note: If you have read access on only some of the jobs and pipelines included in the topology, you cannot view or monitor the topology.
  • Write - Delete topology versions. Edit the topology. Editing a topology also requires read access on all jobs and pipelines included in the topology.

Sharing Objects

As an object owner or as a user with the Organization Administrator role, you can share and grant permissions on the object. You can share objects with individual users or with groups.

You can share and grant permissions on a single object or on multiple objects at the same time.

  1. In the appropriate view, select the object or objects that you want to share.
    For example, to share multiple jobs with your group, select multiple jobs on the Job Instances view.
  2. Click the Share icon: .
  3. On the Sharing Settings window, select the users or groups that you want to share the object or objects with and then click Add.
  4. Assign the appropriate permissions to each added user or group.
  5. Click Save.

Changing the Object Owner

Each object has one owner. As an object owner or as a user with the Organization Administrator role, you can change the owner of the object.

You can change the owner of a single object or of multiple objects at the same time.

  1. In the appropriate view, select the object or objects that you want to modify.
    For example, to change the owner of a job, select the job on the Job Instances view.
  2. Click the Share icon: .
  3. On the Sharing Settings window, if necessary, add the user that you want to assign as the owner.
  4. Hover over the user that you want to assign as the owner, and then click the Is Owner icon: .
    The new owner is granted full access to the object or objects.
  5. Click Save.