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.

In the Navigation panel, click Administration > Organizations.

Hover over your organization, and then click the organization
Configuration icon: .

Data Collector Permissions

By default, only users with the Organization Administrator role or the Auth Token
Administrator role can access registered Data Collectors.

A user with the Organization Administrator
role can grant other users and groups access to any registered Data Collector. A user
with the Auth Token Administrator role can grant other users and groups access to Data Collectors 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 a Data Collector, you
can grant users and groups the following access levels to the Data Collector:

Read - View the details of the Data Collector.

Write - Assign labels to the Data Collector.

Execute - Start jobs on the Data Collector. Also requires execute access on the job and read access on the
pipeline.

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.

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 in Pipeline Designer. Create and remove tags for the pipeline. Delete fragment versions from the
pipeline repository. 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.

You can work with fragments in Control HubPipeline Designer. Here's how 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.

Note: Remember that any user with the Organization Administrator role has full access to all
objects in the organization. When an object is private, the object owner and any user
with the Organization Administrator role can see the object.

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. Use
Data Collector to download published pipelines from Control Hub. Create a job for the pipeline. Export the pipeline.

Write - Design and publish the pipeline in Pipeline Designer. Create and remove tags for the pipeline. Delete pipeline versions from the
pipeline repository. Publish an updated version of the pipeline from Data Collector 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 in both Control Hub and
Data Collector
and can assign pipeline permissions in both tools. Let's examine how pipeline
permissions are used 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.

Note: Remember that any user with the Organization Administrator role has full access to all
objects in the organization. When an object is private, the object owner and any user
with the Organization Administrator role can see the object.

Protection Policy Permissions

When you share a protection policy, you can
grant users and groups the following access level to the policy:

Read - Not used at this time.

Execute - Configure a job to use the policy and start a job that uses the
protection policy.

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.

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 Data Collectors
with the assigned labels.

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 Data Collectors
with the assigned labels. Reset the origin for the job. Also requires read
access on the pipeline.

When you start a job, Control Hub
sends an instance of the pipeline to each appropriate Data Collector. Each
pipeline running from a Control Hub
job inherits the job permissions as it runs in the Data Collector. That
way, users who have access to the job in Control Hub
can log in to each Data Collector 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. You can modify the permissions on the active job, granting the
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.

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.

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.

Click the Share icon: .

On the Sharing Settings window, select the users or
groups that you want to share the object or objects with and then click
Add.

Assign the appropriate permissions to each added user or group.

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.

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.

Click the Share icon: .

On the Sharing Settings window, if necessary, add the
user that you want to assign as the owner.

Hover over the user that you want to assign as the owner, and then click the
Is Owner icon: .