Introduction

Compartments are a powerful feature in Oracle Cloud Infrastructure (OCI) for security isolation and access control. They accomplish that by providing a global logical namespace where policies can be enforced, as folders in a file system. By being global, they stretch out to all OCI regions within a given tenancy. Through policy enforcement, they deliver the right access level according to the parameters defined by the organization for resource management and delegated administration. These parameters vary across organizations. For instance, compartments can reflect an organization functional structure, where each department has a compartment with a designated administrator. Each department compartment, in turn, can have sub compartments for different environments (Dev, Test, Prod), each one with their own administrators, if necessary. The diagram below depicts this particular structure and is used as the basis for the practical example described in this article. The little shapes (cubes, circles, squares) inside the compartments represent OCI resources.

Besides giving an overview on compartments, I also want to give an example on how to share a resource (a Compute instance definition) across compartments. It illustrates the case where someone in the HR department builds out a pretty useful and cool Compute instance and wants to share it with the Sales department for reuse.

By default, any OCI tenancy has a default root compartment, named after the tenancy itself. The tenancy administrator (default root compartment administrator) is any user who is a member of the default Administrators group. Once compartments are created, they can be assigned their own administrators who can then create sub-compartments and assign delegated administrators to each of them. OCI supports up to a 6-level deep compartment hierarchy and the administrator of a parent compartment has full powers over its children compartments.

For the record, my colleague Gustavo Saurez has a post worth checking on How to Use Policies for Restricting Access to the Default Root Compartment. Another nice post that covers compartments in a great level of detail is Sanjay Basu's How MSPs Can Deliver IT-as-a-Service with Better Governance.

When working with compartments, it's important to realize that some OCI resources are only available in the region where they are created, i.e., they have regional scope. Among these resources are Compute instances, Databases, Block Volumes and Virtual Cloud Networks (VCNs). Such aspect surfaces very often in the OCI admin console, where an administrator is looking at the right compartment, but doesn't see a given resource. It is very likely the administrator does not have the correct region selected. Some other resources are global and thus always available regardless of the selected region. Among global resources are all the IAM (identity and Access Management) resources, including users, groups, policies and compartments themselves.

Delegated Administration and Access Control

Compartment access control is governed by policies. Policies are made of statements, created as simple well-formed phrases in English following a particular grammar. In a nutshell, they associate a subject (always a group of users) to actions on selected resources (or family of resources) within a tenancy or compartment. A policy statement can be further qualified by conditions, offering the possibility of very fine-grained access control. Policies are an extensive topic and deserve an article on their own. Here, we touch upon them exclusively for the purposes of delegated administration on compartments.

A compartment policy is typically defined as a set of statements in the form:

allow <subject> to <verb> <resource-type> in <compartment-name> where <conditions>

If we were to deploy compartments as per the diagram above, here's what we could do:

As the tenant administrator:

1. Create two top-level compartments, named HR and Sales.

2. Create two groups for managing those compartments. Let's name them HR-Admins and Sales-Admins.

3. Create one policy with the following statements for making members of those two groups compartments administrators. It makes sense to create the policy in the default root compartment. If we were to picture the policy and the compartment in a tree-like structure, those would be siblings. In my opinion, it is more logical doing this way than defining the policy inside each HR and Sales compartments. But that would also a valid approach.

allow group HR-Admins to manage all-resources in compartment HR

allow group Sales-Admins to manage all-resources in compartment Sales

4. Assign users to those two groups.

5. Create groups for managing the sub-compartments within HR and Sales compartments. Remember that users and groups are global resources, i.e., they can't be confined in a compartment and must be defined at the tenancy level. Therefore, unless you are ok granting user/group management permissions to compartment-level administrators, the tenant administrator is the most suitable for creating users and groups. Let's assume this groups are named HR-Prod-Admins, HR-Test-Admins, HR-Dev-Admins, Sales-Prod-Admins, Sales-Test-Admins and Sales-Dev-Admins.

As an HR compartment administrator:

1. Create three sub-compartments in the HR compartment: HR-Prod, HR-Test and HR-Dev

2. Create one policy with the following statements for making members of HR-Prod-Admins, HR-Test-Admins and HR-Dev-Admins groups administrators of the respective compartments. It's a good practice to create the policy in the HR compartment itself.

allow group HR-Prod-Admins to manage all-resources in compartment HR-Prod

allow group HR-Test-Admins to manage all-resources in compartment HR-Test

allow group HR-Dev-Admins to manage all-resources in compartment HR-Dev

As a Sales compartment administrator, repeat the same steps executed for the HR compartment:

1. Create three sub-compartments in the Sales compartment: Sales-Prod, Sales-Test and Sales-Dev.

2. Create one policy with the following statements for making members of Sales-Prod-Admins, Sales-Test-Admins and Sales-Dev-Admins groups administrators of the respective compartments. It's a good practice to create the policy in the Sales compartment itself.

allow group Sales-Prod-Admins to manage all-resources in compartment Sales-Prod

allow group Sales-Test-Admins to manage all-resources in compartment Sales-Test

allow group Sales-Dev-Admins to manage all-resources in compartment Sales-Dev

That's it. We have just easily implemented delegated administration on OCI resources through compartments usage. Each leaf-level compartment administrator can further delegate access to sub-compartments eventually created and/or configure access to the various OCI resources created. Each compartment works in complete isolation and is independent from each other. The only exception to this is the VCN (Virtual Cloud Network) definition, if peering is expected to be formed between any two VCNs across different compartments. Reason being peering VCNs must not have overlapping CIDR ranges. Obviously, this can be easily solved with minimum coordination from the tenant administrator, who should properly plan the partition of available CIDR range across different organization areas.

Having resources in different compartments has no impact at all in the ability of those resources to communicate. For instance, a database instance in HR compartment is able to connect to a database instance in Sales compartment, as long as the applicable security lists are properly configured.

Last, but not least, two very important security considerations: an administrator of a parent compartment has full power over its children compartments and an administrator of a child compartment cannot override the permissions set forth by the parent compartment administrator. For instance, a member of Sales-Dev-Admins cannot make itself an admin of the Sales parent compartment. An attempt to craft a policy statement like:

allow group Sales-Dev-Admins to manage all-resources in compartment Sales

would make OCI denying it with a message like:

InvalidParameter - The compartment Sales specified in the policy statement does not exist under current compartment hierarchy.

Sharing Resources across Compartments

Since compartments segregate resource management, how, for instance, a Compute instance definition in HR-Dev would be made available to Sales-Dev compartment? Imagine someone in HR Development spent a lot of time hardening an operating system and configured it with some highly specialized software but still don't want to make it available to the overall organization.

There are two ways for achieving this:

• Create a custom image and export the image to object storage and make it available to Sales-Admin-Dev group;
• Export the instance boot volume in HR-Dev to Sales-Dev compartment.

Let's see how each is done and their pros and cons.

Export the Custom Image to Object Storage

As an HR-Dev administrator (member of HR-Dev-Admins group), create a custom image from the running Compute instance. Notice the instance becomes unavailable for some time during the image creation. So, make sure to plan this action properly to avoid any downtime. Once the image is available, export it into an Object Storage bucket. Then create a pre-authenticated request URL and share it with the Sales Dev admin (member of Sales-Dev-Admins group), who should be able to use the URL for downloading the image and then uploading it as a custom image into his own compartment. This is all achievable in OCI console.

Pros:

• It doesn't require the involvement of any other user with greater privileges or the creation of an extra policy;

Cons:

• There's instance downtime when creating the custom image;
• Image needs to be downloaded and then uploaded;

Have the Instance Boot Volume Directly exported to Sales-Dev Compartment

To make this happen we need a user with the proper access level into both HR-Dev and Sales-Dev compartments. In our setup, this would be the tenancy administrator only.

Alternatively, a policy can be configured to allow some particular group with the very precise privilege just to execute this type of operation. In our setup, an HR-Dev administrator could grant inspect access level to Sales-Dev-Admins on compartment HR-Dev. The policy statement would be written as:

allow group Sales-Dev-Admins to inspect volumes in compartment HR-Dev

Notice that inspect is the least possible privilege and entails no access to any confidential information about the resource and no ability to any change operation on the resource. Sales-Dev-Admins can now see the volumes in compartment HR-Dev and create a clone out of them in Sales-Dev compartment. This is all achievable in OCI console as well.

Pros:

• No instance downtime required;
• Fast operation, once the clone operation is done, the cloned boot volume is immediately available;

Cons:

• Appropriate access level is required.

Counting pros and cons, it appears to me we have a clear winner here. If crafting an access policy is not an issue, I would go with the Boot Volume option.

Conclusion

In this article we took a quick look on OCI compartments through the lenses of a practical use case scenario. Compartments are very flexible and can reflect virtually any structure for isolated and secure resource management. With the appropriate policies in place, they can securely offload the chores of a tenancy administrator while enforcing the proper access constraints.

Another key takeaway is that communication between resources in different compartments is absolutely not constrained by policies applied to compartments, but subject to network configuration.

We also touched on how to make a Compute instance definition available across compartments, presenting the pros and cons of different approaches.

Hopefully this brief introduction sheds light on how compartments can benefit organizations of all sizes and shapes as a great tool for secure and decentralized resource management in Oracle Cloud Infrastructure.