An administrative partition is a logical container that you create, containing a defined set of BIG-IP system objects. If you have the Administrator or User Manager user role assigned to the BIG-IP system user account, you can create administrative partitions to control other users’ access to BIG-IP objects. More specifically, when a specific set of objects resides in a partition, you can 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.
The following illustration shows an example of user objects within partitions on the BIG-IP system.
For every administrative partition on the BIG-IP system, the BIG-IP system creates an equivalent high-level folder with an equivalent name.
During BIG-IP system installation, the system automatically creates a partition named Common. At a minimum, this partition contains all of the BIG-IP objects that the system creates as part of the installation process.
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 partition Common, and by default, partition Common is their current partition.
Some users, such as those with the user role of Administrator, can also create, update, and delete objects in partition Common. No user can delete partition Common itself.
The current partition is the specific partition to which the system is currently set for a logged-in user.
A user who has permission to access all partitions can actively select the current partition, that is, the specific partition he or she wants to view or manage. A user who has permission to access one partition only cannot actively select the current partition; the system sets the current partition for that user when he or she logs in to the system. For example:
Partitions have a special relationship to user accounts. With respect to partitions and user accounts, you can:
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. On BIG-IP system, there are specific validation rules for object referencing with respect to the administrative partitions in which those objects reside.
Normally, when you create BIG-IP objects, a referenced object must reside either in the same partition as the object that is referencing it, or in partition Common. For example, this figure shows a valid object-referencing configuration where a virtual server and the pool it references reside in the same partition (named my_app):
Another valid object referencing case is when the object resides in one partition, while the object it references resides in partition Common. This figure shows an example of this configuration, where a virtual server in partition my_app references a pool in partition Common:
In addition to these two valid object referencing configurations, the system also allows a third type of object referencing, specifically regarding iRules. That is, an iRule can reference any object, regardless of the partition in which the referenced object resides. For example, an iRule that resides in partition my_app_A can contain a pool statement that specifies a pool residing in partition my_app_B. Neither object is required to reside in Common.
This figure shows an example of an invalid object-referencing configuration, where a virtual server resides in partition Common, but the pool the virtual server references resides in a different partition. In this case, the virtual server cannot successfully forward traffic to the pool that it is referencing: