1. Concepts Guide
  2. Identity and Access Management Overview
  3. Organizing Resources in Compartments

Organizing Resources in Compartments

After initial setup, your tenancy only contains a root compartment. A tenancy administrator needs to perform setup tasks and establish an organization plan. The plan should include the compartment hierarchy for organizing your resources and the definitions of the user groups that need access to the resources. These two things impact how you write policies to manage access, and therefore should be considered together.

Understanding Compartments

Think carefully about how you want to use compartments to organize and isolate your cloud resources. Compartments are fundamental to that process. Most resources can be moved between compartments. However, it's important to think through your compartment design for your organization up front, before implementing anything.

When planning your compartment structure, keep the following things in mind:

  • You can create a hierarchy up to six compartments deep under the tenancy or root compartment.

  • Compartments are logical, not physical. Related resource components can be placed in different compartments. For example, your cloud network subnets with access to an internet gateway can be secured in a separate compartment from other subnets in the same cloud network.

  • Compartments behave like a filter for viewing resources. When you select a compartment, the Compute Web UI only shows you resources that are in that compartment. To view resources in another compartment, you must first select that compartment.

    This experience is different when viewing users, groups, and federation providers. Those reside in the tenancy itself, not in an individual compartment. A policy can be attached to either the tenancy or a compartment. Where it is attached controls who has access to modify or delete it.

  • The Compute Web UI only displays the compartments and resources that you have permission to access. Only an administrator can view all compartments and work with all resources.

  • At the time you create a resource (for example, instance, block storage volume, VCN, subnet), you must decide in which compartment to put it.

Considerations for Granting Resource Access

Another primary consideration when planning the setup of your tenancy is who should have access to which resources. Defining how different groups of users need to access the resources helps you plan how to organize your resources most efficiently, making it easier to write and maintain your access policies.

For example, you might have users who need to:

  • View the Compute Web UI, but not be allowed to edit or create resources

  • Create and update specific resources across several compartments; for example: network administrators who need to manage your cloud networks and subnets

  • Launch and manage instances and block volumes, but not have access to your cloud network

  • Have full permissions on all resources, but only in a specific compartment

  • Manage other users' permissions and credentials

For information on accessing resources across tenancies, see Cross-Tenancy Policies.

Examples of Compartment Organization

This section describes examples of how compartments can be structured to align with your resource management goals.

All Resources in the Root Compartment

If your organization is small, or if you are still in the proof-of-concept stage, you might consider placing all of your resources in the root compartment or the tenancy. This approach makes it easy for you to quickly view and manage all your resources. You can still write policies and create groups to restrict permissions on specific resources to only the users who need access.

High-level tasks to set up the single compartment approach:

  1. Create a sandbox compartment. Even though your plan is to maintain your resources in the root compartment, Oracle recommends setting up a sandbox compartment so that you can give users a dedicated space to try out features. In the sandbox compartment you can grant users permissions to create and manage resources, while maintaining stricter permissions on the resources in your tenancy (root) compartment.

  2. Create groups and policies.

  3. Add users.

Separately Managed Project Compartments

Consider this approach if your organization has multiple departments that you want to manage separately, or if several distinct projects exist that would be easier to manage separately.

In this approach, you can add a dedicated administrators group for each project compartment who can set the access policies for just that project. Users and groups still must be added at the tenancy level. You can give one group control over all their resources, while not allowing them administrator rights to the root compartment or any other projects. This way, you enable different groups to set up their own "sub-clouds" for their own resources and manage them independently.

High-level tasks to set up the multi-project approach:

  1. Create a sandbox compartment. Oracle recommends setting up a sandbox compartment so that you can give users a dedicated space to try out features. In the sandbox compartment you can grant users permissions to create and manage resources, while maintaining stricter permissions on the resources in your tenancy and other compartments.

  2. Create a compartment for each project. For example: ProjectA, ProjectB.

  3. Create an administrators group for each project. For example: ProjectA_Admins.

  4. Create a policy for each administrators group. For example:

    Allow group ProjectA_Admins to manage all-resources in compartment ProjectA

  5. Add users.

  6. Let the administrators for ProjectA and ProjectB create subcompartments within their designated compartment to manage resources.

  7. Let the administrators for ProjectA and ProjectB create the policies to manage the access to their compartments.

Working with Compartments

This section describes the basics of compartment management.

Creating Compartments

When creating a compartment, you must provide a name that is unique within the tenancy. It can be up to 100 characters long, and include letters, numbers, periods, hyphens, and underscores. You must also provide a description for the compartment, which must be 1-400 characters long and is non-unique and changeable. The new compartment is automatically assigned a unique identifier called an Oracle Cloud ID (OCID).

You can create subcompartments within compartments, to create hierarchies that are up to six levels deep.

Compartment Access Control

After creating a compartment, you need to write at least one policy for it, otherwise it is only accessible to administrators and users with permissions set at the tenancy level. When creating a compartment inside another compartment, the subcompartment inherits access permissions from compartments higher up its hierarchy.

When you create an access policy, you need to specify which compartment to attach it to. This controls who can later modify or delete the policy. Depending on your compartment hierarchy design, you might attach it to the tenancy, a parent, or to the specific compartment itself.

For information on accessing resources across tenancies, see Cross-Tenancy Policies.

Adding Resources to Compartments

When you start working with cloud resources in the Compute Web UI, you must choose from a list which compartment to work in. That list is filtered to show only the compartments in the tenancy that you have permission to access.

To place a new resource in a compartment, you simply specify that compartment when creating the resource. The compartment is one of the required parameters to create a resource. When working in the Compute Web UI, make sure you are first viewing the compartment where you want to create the resource.

Keep in mind that most IAM resources reside in the tenancy. This is always the case for users and groups, but compartments and policies are also often attached to the tenancy. Tenancy-level resources cannot be created or managed from a specific compartment.

Moving Resources Between Compartments

Most resources can be moved after they are created.

Some resources have attached resource dependencies. When the parent resource is moved to another compartment, the attached dependencies do not all behave in the same way. Some are moved immediately with their parent resources, and some are moved asynchronously, meaning they are not visible in the new compartment until the move is complete. For other resources, the attached resource dependencies are not automatically moved to the new compartment. You can move these attached resources independently.

After you move a resource to a new compartment, the policies that govern the new compartment apply immediately and affect access to the resource. See the service documentation for individual resources to familiarize yourself with the behavior of each resource and its attachments.

Deleting Compartments

To delete a compartment, it must be empty of all resources. Before you initiate deleting a compartment, be sure that all its resources have been moved, deleted, or terminated, including any policies attached to the compartment.

The delete action is asynchronous and initiates a work request, which typically takes several minutes to complete. While a compartment is in the deleting state it is not displayed in the compartment picker. If the work request fails, the compartment is not deleted and it returns to the active state. You can track the progress of a work request during the operation, or check afterwards whether it completed successfully or if errors occurred.

After a compartment is deleted, its state is updated to deleted and a random string of characters is appended to its name. For example, CompartmentA might become CompartmentA.qR5hP2BD. Renaming the compartment allows you to reuse the original name for a different compartment. Deleted compartments are listed in the Compartments page for 365 days, but are removed from the compartment picker. If any policy statements reference the deleted compartment, these statements are updated to reflect the new name.

If the work request indicates that the compartment failed to delete, verify that you have removed all the resources. Verify that there are no policies in the compartment. If you cannot locate any resources in the compartment, check with your administrator; you might not have permission to view all resources.

Moving a Compartment to a Different Parent Compartment

To move a compartment, you must belong to a group that has manage all-resources permissions on the lowest shared parent compartment of the current compartment and the destination compartment.

You can move a compartment to a different parent compartment within the same tenancy. When you move a compartment, all its contents, meaning its subcompartments and resources, are moved with it. This section also describes the implications of moving a compartment. Ensure that you are aware of these before you move a compartment.

When moving a compartment, these restrictions apply:

  • You cannot move a compartment to a destination compartment with the same name as the compartment being moved.

  • Two compartments within the same parent cannot have the same name. Therefore you cannot move a compartment to a destination compartment where a compartment with the same name already exists.

Policy Implications

After you move a compartment to a new parent compartment, the access policies of the new parent take effect and the policies of the previous parent no longer apply. Before you move a compartment, ensure that:

  • You are aware of the policies that govern access to the compartment in its current position.

  • You are aware of the polices in the new parent compartment that will take effect when you move the compartment.

Groups with access to resources in the current compartment lose their permissions when the compartment is moved; groups with permissions in the destination compartment gain access. Ensure that you are aware not only of what groups lose permissions when you move a compartment, but also what groups will gain permissions. If necessary, adjust the policy statements to avoid certain users inadvertently losing access.

Tagging Implications

Tags are not automatically updated after a compartment has been moved. If you have implemented a tagging strategy based on compartment, you must update the tags on the resources after moving the compartment.

For example, assume that CompartmentA has a child compartment named CompartmentB. CompartmentA is set up with tag defaults so that every resource in CompartmentA is tagged with TagA. Therefore CompartmentB and all its resources are tagged with this default tag, TagA. When you move CompartmentB to CompartmentC, it will still have the default tags from CompartmentA. If you have set up default tags for CompartmentC, you need to add them to the resources in the moved compartment.