What is a Compartment?
Let’s start with some fundamental characteristics of compartments.
-
From an architectural viewpoint, a compartment is simply a logical group of OCI resources. There is no specific implication of network structure, geographical placement, or even any relationship between resources. They are merely a set of resources that are associated with a set of group based permissions.
-
Compartments can stretch across more than one Oracle Region. Each compartment is accessible within every Oracle Region that your tenancy subscribes to.
-
Resources associated with a compartment can easily be re-associated with a different compartment
-
Quotas and budgets can be set at the compartment level. This allows you to restrict how many instances of a given resource type can be deployed, as well as enable cost tracking.
-
Every tenancy has at least one compartment. This is the Root compartment, and it is at the highest level in the tenancy. It is the parent of all other compartments. The Root compartment has the same name as the tenancy. We recommend that you do not use the Root compartment for your own OCI resources.
Important:
Compartments provide the contextual scope when granting permissions to groups of users. This is achieved through the use of Policies.
Understanding Policies
In OCI, administrative permissions are never granted against a single resource instance, but to resource types, or family resource types, within a compartment or across the whole tenancy.
Examples of network resource types include;
- vcns, subnets, route tables, network security groups, public ips, service gateways, vnics
Permissions can be granted against each network resource type or against the family of resources of that type. In this case, that would be; virtual-network-family
Similar individual resource types and an associated family exist for all OCI resources (e.g. databases, compute, containers, file storage)
As a general guide, we recommend that all members of a specific resource type (e.g. databases), within a compartment, are administered by the same team of people. Different teams can still administer each resource type (vcns, gateways, compute instances) within a compartment.
Important:
Compartments are a key tool in providing separation of resources across your organizational structure.
Example Compartment Structure
The following example illustrates the role that compartments, groups and policies play in achieving separation between different organizational units.
In the diagram above, we can see three compartments within the tenancy; Development, Test and Production.
In this example organization, there are different teams of people responsible for managing each of these environments. The Development teams are much more self-service, whereas the Test and Production teams have a progressively more rigorous change control mechanism.
With each of the example compartments, there are different types of OCI resources that make up one or more applications/systems. The resources in our example are managed in a horizontal nature. That is to say that all production databases, for all applications, are managed by the same group of people. The same is true for production networks, and production compute resources.
So, we have;
- a Production Network team that manages one or more production networks
- a Production Sys Admin team that manages one or more compute resources
- a Production DBA team that manages one or more databases
The permissions for these teams are granted through each team member belonging to an appropriate Group in the tenancy IAM. This group is granted explicit permissions to act upon either a resource type or a resource family. The context of the grant is specific to a compartment or the entire tenancy.
Tip:
A compartment does not have its own users, groups or policies. They are defined within the tenancy identity provider and can only be managed by a user with tenancy wide administration privileges. The compartment provides the scope within the policy whereby a certain privilege can be executed for a group of users.
For example, the permissions granted to the Production Network team (who are individually members of the Prod-Network group) might look like this;
An individual member can belong to more than one group. Therefore, it is possible for the same person to administer resources in the development and production environments. They will then be subject to the policies that apply to the environment in which they are working.
For example, “David” can create and drop a Dynamic Router Gateway (DRG) in the Development environment, but he can only attach VCNs to a DRG in the Production environment.
There are many more ways of designing the Compartment hierarchy than just the one shown. You might wish for individual workloads or applications to be managed in a more “vertical” way. This could mean that you want one team of people to manage all of the OCI components for an application “A” within the production compartment. A different team, but maybe with some shared members, might be responsible for application “B”. Another team with no shared members could be responsible for application “C”.
And, as with the first example, this design still needs to respect the different policies relating to Development, Test and Production environments.
This approach can easily be achieved through the use of a Sub-Compartments.
Making Use of Sub-Compartments
Compartments can contain sub-compartments. This approach can be used to create compartment hierarchies that are up to 6 levels deep. This approach is very flexible and can lend itself to supporting very complex levels of hierarchy and still delivering the control and governance you need.
When creating a sub-compartment, permissions are inherited from compartments higher up in the hierarchy. In the above diagram, members of a group that had been granted permissions to manage virtual-network-family in Compartment 1would also be able to manage all network resources in the 12 sub-compartments shown. This highlights the importance of identifying the specific responsibilities of each group at the compartment level. Policies that grant the appropriate permissions must be attached to the lowest level sub-compartment where they are needed. Attaching them at a higher level may result in too broad a permission being granted.
For our previous example where we wanted to manage applications “vertically”, we might decide to design our compartment structure like this;
In our tenancy, we still have three compartments, but this time they represent individual applications rather than technology layers. We have; Application A, Application B and Application C.
Within each application’s compartment, there are three sub-compartments. They represent the three types of environment for each application; Development, Test and Production.
The OCI resources associated with each sub-compartment are administered by users belonging to groups that have been given permission against the resource types in each sub-compartment. These groups may have been created so that every member of the group can administer any resource, regardless of type (i.e. network, database, compute), or we might create groups that confer specific permissions against resource types. In this way, we can super-impose the “technology layers” approach used in our first example. This means, for example, that DBA’s can only administer databases and not VCN’s.
Important:
A strong understanding of Tenancies, Regions and Compartments means we can design a secure, operationally effective, and flexible organizational structure in OCI.