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 Permission Enforcement

By default, permission enforcement is disabled for your organization. An organization administrator can enable permission enforcement 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.

Note: Data Collector version 2.4.0.0 introduces pipeline sharing and permissions. If permission enforcement is enabled for your organization and you run a job on an earlier version of Data Collector, that Data Collector can run pipelines for the job but does not support permissions.
  1. In the Navigation panel, click Administration > Organizations.
  2. Hover over your organization, and then click the organization Configuration icon: .
  3. On the Organization Configurations 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 Data Collectors provisioned with the deployment.

When provisioned Data Collectors are registered with Control Hub, they inherit the same 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 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 just as they can on any manually administered Data Collector. As a result, Data Collectors provisioned by the same deployment can be granted different permissions.

When you share a 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 deployment and of all Data Collectors provisioned with the deployment.
  • Write - Edit and delete the deployment. Assign labels to all Data Collectors provisioned with the deployment.
  • Execute - Scale, start, and stop the deployment. Start jobs on all Data Collectors provisioned with the deployment - also requires execute access on the job and read access on the pipeline.

Engine Permissions

By default, only users with the Organization Administrator role or the Auth Token Administrator role can access a registered StreamSets engine, such as Data Collector or Transformer.

A user with the Organization Administrator role can grant other users and groups access to any StreamSets engine. A user with the Auth Token Administrator role can grant other users and groups access to execution engines that they are the owners of.

Note: When provisioned Data Collectors are registered with Control Hub, they inherit the same permissions assigned to the deployment. Users with the Organization Administrator role can then modify permissions on any provisioned Data Collector just as they can on any manually administered Data Collector. For more information, see Deployment Permissions.
When you share an engine, you can grant users and groups the following access levels to the engine:
  • Read - View the details of the engine.
  • Write - Assign labels to the engine.
  • Execute - Start jobs on the engine. Also requires execute access on the job and read access on the pipeline.

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.

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. Users who have access to the job in Control Hub can log in to the UI of the execution engine to monitor the progress of the pipeline running from the job.

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.

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

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. Use Data Collector to download published Data Collector pipelines from Control Hub. Use Transformer to download published Transformer pipelines from Control Hub.
  • Write - Design and publish the pipeline. Create and remove tags for the pipeline. Delete pipeline versions. Publish an updated version of the pipeline from Data Collector or Transformer to Control Hub.

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.

You can work with pipelines and assign pipeline permissions in Control Hub or in the UI for the pipeline execution engine. Pipeline permissions apply when you share pipelines between Data Collector and an execution engine. The process is the same on all execution engines. Let's examine how pipeline permissions apply when you share pipelines between Control Hub and Data Collector:
Publish pipelines
You must have read permission on a pipeline within Data Collector to publish the pipeline to Control Hub. The first time that you publish a pipeline, you become the owner of the pipeline in Control Hub. The pipeline is private to you. Pipeline permissions assigned in Data Collector are not retained with the published pipeline in Control Hub. As the object owner, you can log in to Control Hub and share the pipeline with others.
When you publish the same pipeline an additional time, Control Hub enforces pipeline permissions assigned within Control Hub. You must have write permission on the pipeline within Control Hub.
Download pipelines
When you download a pipeline from Control Hub to Data Collector, Control Hub enforces pipeline permissions assigned within Control Hub. You must have read permission on the pipeline within Control Hub.
You become the owner of the downloaded pipeline in Data Collector. The pipeline is private to you - pipeline permissions assigned in Control Hub are not retained with the downloaded pipeline. As the object owner, you can use Data Collector to share the pipeline with others.
Export pipelines
When you export a pipeline from Data Collector, Data Collector does not retain the pipeline permissions with the exported pipeline.
Import pipelines
When you import a pipeline into Control Hub, you become the owner of the pipeline in Control Hub. The pipeline is private to you. You can use Control Hub to share the pipeline with others.

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.

Report Task Permissions

When you share a report task, you can grant users and groups the following access levels to the task:
  • Read - View report definition and view generated report tasks.
  • Write - Edit the report definition task.
  • Execute - Generate the report task.

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.

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 Jobs 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 Jobs 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.