Applies To:

Show Versions Show Versions

Manual Chapter: Administrative Partitions and Folders
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

If you have the Administrator or User Manager user role assigned to your BIG-IP® system user account, you can control other users access to objects by using a feature known as administrative partitions. An administrative partition is a logical container that you create, containing a defined set of BIG-IP system objects.
When a specific set of objects resides in a partition, you can then give certain users the authority to view and manage the objects in that partition only, rather than to all objects on the BIG-IP system. This gives a finer granularity of administrative control.
A significant benefit to administrative partitions is that they allow you to place administrative ownership of an application into the hands of the business units that actually run the applications.
To configure and manage administrative partitions, log in to the BIG-IP Configuration utility, and on the Main tab, expand System, and click Users.
Figure 12.1, shows an example of partitions that you can create on a BIG-IP system. Partition App1 contains objects that pertain to an HTTP application, partition App2 contains objects that pertain to traffic utilizing Packet Velocity® ASIC (PVA), and partition Users contains local user accounts on the BIG-IP system.
During BIG-IP system installation, the system automatically creates a partition known as partition Common (often referred to as the Common partition). At a minimum, this partition contains all of the BIG-IP system objects that the system creates during installation.
Note: Until you create other partitions on the system, all objects that you or other users create automatically reside in partition Common. If you create other partitions later, you cannot move an object in Common to one of the new partitions. Instead, you must delete the object from Common and recreate it in the new partition.
With respect to permissions, all users on the system except those with a user role of No Access have read access to objects in the Common partition, and by default, the Common partition is their current partition. (For information on the current partition, see The current partition, following.)
Some users, such as those with the user role of Administrator, can also create, update, and delete objects in the Common partition. No user can delete the Common partition itself. For information about the permissions of each user role with respect to viewing and managing objects in partition Common, see Chapter 13, BIG-IP User Accounts.
One of the objects that the BIG-IP system creates in partition Common during installation is a route domain with an ID of 0. Route domain 0 is the default route domain on the BIG-IP system. For more information about route domains, see Chapter 23, Route Domains.
The current partition is the specific partition to which a logged-in user currently has access, as determined by the properties of that users account. Whenever a user performs an action on the BIG-IP system, the system automatically performs that action within the current partition.
As described in Chapter 13, BIG-IP User Accounts, a user account grants permission to access either a single partition (other than partition Common) or all partitions. If a user has permission to access one partition only, the user cannot select the current partition. Instead, the BIG-IP system establishes the users current partition at login time, based on the particular partition access that is specified in the properties of that user account.
Users who have permission to access all partitions can actively select the current partition, that is, the specific partition they want to view or manage.
For example, suppose user rsmith has a role of Manager, and a user with an Administrator role has given user rsmith access to all partitions on the system (for example, partitions A, B, C, and Common). In this case, before creating or managing any object on the BIG-IP system, user rsmith must select the partition (A, B, or C) that she wants to be the current partition. After selecting the current partition, any object that she creates will reside in that partition, and she can modify or delete only those objects that reside in the current partition. If she fails to select partition A, B, or C, the current partition is Common, by default. User rsmith selects a partition using either the Configuration utility or a command line interface.
Conversely, if user rsmith has the role of Manager and she is granted access to partition A only, then any object that she creates while logged into the BIG-IP system automatically becomes a member of partition A. Although she can view objects in partition Common, she cannot select Common as her current partition because she has read access only for that partition. For user rsmith, partition A is automatically her current partition, and she cannot change the current partition to create objects in another partition.
Certain BIG-IP system objects, such as virtual servers, always reference other objects. Examples of objects that a virtual server can reference are pools, profiles, and iRules®. When you create objects, a referenced object must reside either in the same partition as the object that is referencing it, or in the Common partition.
For example, if a virtual server such as my_vs resides in partition my_app and references the pool my_pool, then the object my_pool must reside either in partition my_app or in partition Common.
Figure 12.2 shows an example of an allowed configuration, where a virtual server and the pool it references reside in the same partition my_app).
The other case in which one object can reference another is when the object resides in one partition, while the object it references resides in partition Common. Figure 12.3, shows an example of this configuration, where a virtual server in partition my_app references a pool in partition Common.
Note in this illustration that direction is important; the referencing object (the virtual server) must be in a user-created partition (my_app), while the referenced object (the pool) must reside in partition Common. As shown in Figure 12.4, the virtual server cannot reside in partition Common and reference a pool that resides in partition my_app.
Assign partition access to user accounts
You can assign an authorized partition (known as partition access) to a user account. A partition access assignment gives a user some level of authority over the specified partition. As an option, for all user roles you can assign universal access to partitions, which grants users permission to access all partitions instead of one non-Common partition only. Note that assigning partition access to a user does not make the user a member of that partition, nor does it necessarily give the user full access to all objects in the partition.
Create user accounts as partitioned objects
As described earlier, when you create a user account, you assign partition access for that account as a way to define the scope of that users access control. However, like many other object types, user accounts also reside in partitions. This controls other users administrative access to those user accounts. Also like other object types, a BIG-IP system user account cannot belong to more than one partition simultaneously. Note that when you first install the BIG-IP system, every existing user account (root and admin) belongs to partition Common.
To see the relationship of partitions to objects, consider the following example. This example shows how you can configure the BIG-IP system to grant a particular BIG-IP system administrator, Jane Smith, permission to manage all objects in a specific partition pertaining to the management of HTTP traffic. Note that to perform this task successfully, your own user account must have the role of Administrator assigned to it.
Select the vendor_appl partition to be the current partition.
Create any HTTP-related objects that you want to reside in that partition, such as a virtual server, a load balancing pool, and an HTTP profile.
Select an existing partition in which you want Janes user account to reside, such as IT_users.
This is now your current partition.
Assign the name jsmith to the user account.
Note that this account resides in the current partition, IT_users.
Create a password for the jsmith user account.
Assign the user role of Manager to the jsmith account.
This role allows Jane to control all resources in the partition to which she is given access (see the following step).
Designate the vendor_appl partition as the partition to which user jsmith has access.
When Jane logs into the system as jsmith, the system sets her current partition to vendor_appl because this is the partition you assigned to her when you created her user account (see step 5d). Because you assigned her a user role of Manager, Jane can fully manage all objects in partition vendor_appl, as well as create new objects. Note, however, that the user account object jsmith resides in partition IT_users.
Important: As shown in this example, there is no relation between the partition in which the jsmith user account resides (IT_users) and the partition to which the jsmith account has access (vendor_appl).
When implementing the partitions feature, there are some specific aspects of the feature that you should consider, with corresponding recommendations. See Table 12.1 for more informationn.
An object can only reference another object if both objects are in the same partition, or if the referenced object is in partition Common.
When you create objects, ensure that the referencing object and its referenced object reside in the same partition, or that the referenced object resides in partition Common.
If you want to change the partition in which an object resides, delete the object from the old partition, and recreate the object in the new partition.
Note that if the object you want to delete and recreate in another partition is a pool that resides in partition Common, you should not only delete the pool, but also delete any nodes associated with that pool. Otherwise, pools in other partitions can reference those nodes that are in partition Common.
The same BIG-IP system object cannot be a member of more than one partition simultaneously.
If an authorized user modifies a parent object, the system propagates the changes to all child objects, regardless of the partition in which the child object resides.
Be aware that modifications to a child object that other administrators implemented might appear.
If a user with permission to manage objects in partition Common disables a monitor that is designated as the default monitor for nodes (such as the icmp monitor), this affects all nodes on the system.
An iRule can reference any object, regardless of the partition in which the referenced object resides. For example, an iRule that resides in partition A can contain a pool statement that specifies a pool residing in partition B.
For objects that cannot reside in partitions (such as packet filters), only users with the Administrator or Resource Administrator role have full access to these objects. Users with a role other than Administrator, Resource Administrator can view these objects, but they cannot create, modify, or delete them.
When attempting to create an object, the user might see an error message stating that the object already exists, even though the object name does not appear on the list screen. This is because the existing object resides in a partition that the user has no permission to access.
Every object on the system must have a unique name, regardless of the partition in which the object resides.Therefore, when creating an object on the system, be sure to assign a unique name to the object.
For every partition on the BIG-IP system, there is an equivalent folder. In the context of the BIG-IP system, a folder is a container for BIG-IP system objects. Folders resemble standard directories, in that the system includes a root folder (represented by the / symbol) that is the parent for other folders on the system.
You can use folders to set up granular synchronization and failover of BIG-IP configuration data in a device group. Instead of synchronizing or failing over all configuration data on a BIG-IP device to the same device group, the BIG-IP system can synchronize or fail over objects within a specific folder only to a different device group.
You can use tmsh to set a folders device group to the name of the device group to which you want to synchronize the contents of that folder. You can also set the folders traffic group attribute to the name of the traffic group that you want to associate with the contents of that folder.
You can use the BIG-IP Configuration utility to associate a device and traffic group with an administrative partition. This sets the device and traffic group attributes on the corresponding folder.
The root folder
The BIG-IP system includes a root folder. When you assign a device group to the root folder, all configuration data on the device, by default, is synchronized to the devices in that device group.
Folder-partition association
A high-level folder exists on the system within the root folder for each administrative partition. For example, for the Common partition, there is a corresponding high-level folder named /Common. If you create another administrative partition, such as partition App_A, the BIG-IP system automatically creates another high-level folder named /App_A.
Folders and the current partition
The close association of administrative partitions to folders means that when you use the BIG-IP Configuration utility to create objects on a BIG-IP device, the system puts those objects in the folder corresponding to the current partition. For example, if your current partition is partition Common, any objects you create reside in folder /Common. Examples of BIG-IP objects that reside in folders are virtual servers, pools, and self IP addresses.
BIG-IP object names
The folder in which an object resides becomes part of the name of that object. For example, if you create a pool in partition Common and name the pool my_pool, the complete name of the pool on the system is /Common/my_pool. If you create the pool in partition App_A, the complete name of the pool on the system is /App_A/my_pool.
You can create sub-folders within a high-level folder, using tmsh. For example, if you have a high-level folder (partition) within the root folder named Customer1, you can use tmsh to create a sub-folder, such as App_B, within Customer1. If you create a pool named my_pool within the sub-folder, the name of the pool is /Customer1/App_B/my_pool.
Viewing folder contents
When you use tmsh to view the contents of any folder on the system, the system also shows the objects in folder /Common.
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?

NOTE: Please do not provide personal information.

Additional Comments (optional)