Ownership groups

An ownership group defines a subset of users and objects within the system.

Ownership groups restrict access for users in the ownership group to only those objects that are defined within that ownership group. An owned object can belong to one ownership group. Users in an ownership group are restricted to viewing and managing objects within their ownership group. These restricted users can access only this subset of objects. Unrestricted users, who are not in an ownership group, can continue to view or manage all the objects on the system based on their defined user role, including objects within ownership groups. When the user within an ownership group logs on to the management GUI or command-line interface, only resources that they have access through the ownership group are available. The following objects can be assigned to ownership groups:
  • Child pools
  • Volumes
  • Volume groups
  • Hosts
  • Host clusters
  • Host mappings
  • FlashCopy® mappings
  • FlashCopy consistency groups
  • User groups
  • Portsets

Two basic use cases can be applied to using ownership groups on the system. The first use case for using ownership groups is on a system where new objects are created within the ownership group. There can also be other existing objects on the system that are not in the ownership group. The second use case for using ownership groups is on a system where these supported objects are already configured and you want to migrate these objects to use ownership groups.

When a user group is assigned to an ownership group, the users in that user group retain their role, but are restricted to only those resources within the same ownership group. The role that is associated with a user group can define the operations on the system and the ownership group can further limit access to individual resources. For example, you can configure a user group with the Copy Operator role, which limits user access to FlashCopy operations. Access to individual resources, such as a specific FlashCopy consistency group, can be further restricted by assigning it to an ownership group.

Inheriting ownership

Generally two basic inheritance rules that apply to all objects that can be associated to an ownership group:
  1. Owned objects inherit the ownership group of the owner who creates those objects.
  2. Only users with Security Administrator role can create, manage, or assign ownership group to new objects or existing objects.
Depending on the type of resource, ownership groups can be defined explicitly or inherited from these explicitly defined objects.
The following graphic shows how different objects inherit ownership from ownership groups:
Figure 1. Ownership group inheritance
Example of ownership group inheritance
You can explicitly define ownership groups for the following objects:
Child pools
New or existing volumes that are defined in the child pool inherit the ownership group that is assigned for the child pool.
Host clusters
New or existing hosts that are defined in a Host Cluster inherit the ownership group that is assigned to the Host Cluster.
Hosts that are not part of a Host Cluster
If a host is not part of a Host Cluster, an ownership group can be associated with the host when the host object is created or changed.
Volume groups
Volume groups can be created to manage multiple volumes that are used with transparent cloud tiering support. The following rules apply to volume groups that are defined in ownership groups:
  • Volumes can be added to a volume group if both the volume and the volume group are within the same ownership group or if both are not in an ownership group. When migrating existing resources to ownership groups, the volume group and its volumes can belong to different ownership groups temporarily until the migration completes.
  • The ownership of a volume group does not affect the ownership of the volumes it contains. If a volume group and its volumes are owned by different ownership groups, then the owner of the child pool that contains the volumes can change the volume directly. For example, the owner of the child pool can change the name of a volume within it. The owner of the volume group can change the volume group itself and indirectly change the volume, such as deleting a volume from the volume group. Neither the ownership group of the child pools nor the owner of the volume group can directly manipulate the resources that are not defined in their ownership group.
Note: Volume groups can only be created by using the CLI.
FlashCopy consistency groups
FlashCopy consistency groups can be created to manage multiple FlashCopy mappings. The following rules apply to FlashCopy consistency groups that are defined in ownership groups:
  • Users that are defined in ownership groups can add FlashCopy mappings to a consistency group if the volumes in the mapping and in the consistency group are within the same ownership group. For users that are not defined in an ownership group, no restriction for adding mappings to a FlashCopy consistency group. In this case, FlashCopy consistency groups are containers only and do not influence the ownership of the contents.
  • When you are migrating existing resources to ownership groups, a FlashCopy consistency group and its resources can belong to different ownership groups temporarily until the migration completes.
  • As with volume groups and volumes, the ownership of the consistency group has no impact in the ownership of the mappings it contains.
User groups
The following rules apply to user groups:
  • Only users with Security Administrator role can create or manage ownership groups.
  • Users with Security Administrator role cannot be assigned to an ownership group.
Portsets
The following rules apply to portsets:
  • Users who are defined in an ownership group can view and create IP addresses or assign portset to host that are in their ownership group.
  • Users who are defined in an ownership group can assign portset to host that are not assigned to an ownership group.
  • When a user who are defined in an ownership group creates a portset, it is automatically assigned to the same ownership group as that restricted user.
  • Users who are defined in an ownership group can view all IP addresses in portsets owned by them and portsets not assigned to an ownership group.
  • Users who are defined in an ownership group cannot modify portsets associated with other restricted users.
  • Users who are defined in an ownership group cannot view portsets that have been assigned to a different ownership group.
  • Users who are defined in an ownership group cannot view IP addresses that are associated with a portset assigned to a different ownership group.
  • Users who are defined in an ownership group cannot create or delete IP addresses from a portset that is part of a different ownership group.
  • Users who are defined in an ownership group cannot own storage portsets.
  • Users with the Security Administrator role can view, create, and manage all portsets on the system.
  • Users with the Security Administrator role can view and create IP addresses to any portsets on the system.
  • Users with the Security Administrator role can assign portsets that are not assigned to an ownership group to hosts in an ownership group.
  • Users with the Security Administrator role can assign portset to hosts that are assigned the same ownership group.
  • Users with the Security Administrator role cannot assign portset to hosts if the host and portsets are in different ownership groups.
  • Users with the Security Administrator role cannot change the ownership of storage portsets.
Other objects inherit the ownership group from these explicitly assigned objects. Usually the ownership group is defined when an object is created. Ownership can also be changed when the explicitly defined object from which the ownership is established is assigned to a different ownership group. The following objects inherit the ownership from the explicitly defined object:
Hosts that are a part of a Host Cluster
The following rules apply to hosts that are defined in ownership groups:
  • The host inherits the ownership group of the Host Cluster that it belongs to.
  • If a host is removed from a Host Cluster within an ownership group, the host inherits the ownership group of the Host Cluster it used to belong to.
  • If a host is removed from a Host Cluster not within an ownership group, the host inherits no ownership group.
  • Hosts can be added to a Host Cluster if the host and Host Cluster have the same ownership group.
  • Changing the ownership group of a Host Cluster automatically changes the ownership group of all the hosts inside the Host Cluster.
Volumes
The following rules apply to volumes that are defined in ownership groups:
  • The volume inherits the ownership group of the child pools that provide capacity for the volume and its copies. Volume copies can be created in different ownership groups for backup up scenarios. However, this value must be set intentionally by users that are not defined in ownership groups. When you create a volume copy or migrate volumes to other pools, you can specify child pools that are defined in different ownership groups in the management GUI, which establishes inconsistent ownership. When you create a volume copy or migrating a volume in the command-line interface, use the -inconsistentownershipgroup to allow for inconsistent ownership groups. However, it is not recommended to leave volumes or volume copies in different ownership groups. After the migration, the user with Security Administrator role needs to ensure all volumes or copies are within the same ownership group as the users who need access.
  • With volume groups, the volume group and its volumes can belong to different ownership groups. However, the ownership of a volume group does not impact the ownership of the volumes that it contains.
Users
The following rules apply to users that are defined in ownership groups:
  • A user inherits the ownership group of the user group it belongs to.
  • Users that use LDAP for remote authentication can belong to multiple user groups, but belong to just one ownership group that is associated with one of the user groups.
Volume-to-host mappings
The following rule applies to volume-to-host mappings that are defined in ownership groups:

Volume-to-host mappings inherit the ownership group of the host or Host Cluster and volume in the mapping.

FlashCopy mappings
The following rules apply to FlashCopy mappings that are defined in ownership groups:
  • FlashCopy mappings inherit the ownership group of both the volumes that are defined in the mapping.
  • Like with FlashCopy consistency groups, it is possible for a consistency group and its mappings to belong to different ownership groups. However, the ownership of the consistency group has no impact in the ownership of the mappings that it contains.