Oracle Cloud Infrastructure Documentation

Learn Best Practices for Setting Up Your Tenancy

After Oracle creates your tenancy in Oracle Cloud Infrastructure, an administrator at your company will need to perform some set up tasks and establish an organization plan for your cloud resources and users. Use the information in this topic to help you get started.

Tip

To quickly get some users up and running while you are still in the planning phase, see Adding Users.

Also see Tenancy Management for more information on managing your tenancies.

Create a Plan

Before adding users and resources you should create a plan for your tenancy. Fundamental to creating your plan is understanding the components of the Oracle Cloud Infrastructure Identity and Access Management (IAM). Ensure that you read and understand the features of IAM. See Overview of Identity and Access Management.

Your plan should include the compartment hierarchy for organizing your resources and the definitions of the user groups that will need access to the resources. These two things will impact how you write policies to manage access and so should be considered together.

Use the following primer topics to help you get started with your plan:

Understanding Compartments

Compartments are the primary building blocks you use to organize your cloud resources. You use compartments to organize and isolate your resources to make it easier to manage and secure access to them.

When your tenancy is provisioned, a root compartment is created for you (your tenancy is your root compartment). Your root compartment holds all of your cloud resources. You can think of the root compartment like a root folder in a file system.

The first time you sign in to the Console and select a service, you will see your one, root compartment.

Console showing the root compartment

You can create compartments under your root compartment to organize your cloud resources in a way that aligns with your resource management goals. As you create compartments, you control access to them by creating policies that specify what actions groups of users can take on the resources in those compartments.

Keep in mind the following when you start working with compartments:

  • At the time you create a resource (for example, instance, block storage volume, VCN, subnet), you must decide in which compartment to put it.
  • Compartments are logical, not physical, so 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.
  • You can create a hierarchy of compartments up to six compartments deep under the tenancy (root compartment).
  • When you write a policy rule to grant a group of users access to a resource, you always specify the compartment to apply the access rule to. So if you choose to distribute resources across compartments, remember that you will need to provide the appropriate permissions for each compartment for users that will need access to those resources.
  • In the Console, compartments behave like a filter for viewing resources. When you select a compartment, you only see resources that are in the compartment selected. To view resources in another compartment, you must first select that compartment. You can use the Search feature to get a list of resources across multiple compartments. See Overview of Search.
  • You can use the tenancy explorer to get a complete view of all the resources (across regions) that reside in a specific compartment. See Viewing All Resources in a Compartment.
  • If you want to delete a compartment, you must delete all resources in the compartment first.
  • Finally, when planning for compartments you should consider how you want usage and auditing data aggregated.

Consider Who Should Have Access to Which Resources

Another primary consideration when planning the setup of your tenancy is who should have access to which resources. Defining how different groups of users will need to access the resources will help 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 Console, 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

To see some sample policies, see Common Policies.

Sample Approaches to Setting Up Compartments

Put all your resources in the tenancy (root compartment)

If your organization is small, or if you are still in the proof-of-concept stage of evaluating Oracle Cloud Infrastructure, you might consider placing all of your resources in the root compartment (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. (Best practice) 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. See Create a Sandbox Compartment.
  2. Create groups and policies. See Common Policies.
  3. Add users. See Managing Users.

Create compartments to align with your company projects

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

In this approach, you can add a dedicated administrators group for each compartment (project) 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. In this way, you can enable different groups at your company to set up their own "sub-clouds" for their own resources and administer them independently.

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

  1. Create a sandbox compartment. Oracle recommends setting up a sandbox compartment so 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 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.

    Example: 
    Allow group ProjectA_Admins to manage all-resources in compartment ProjectA)
  5. Add users. See Managing 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.

Create compartments to align with your security requirements

Consider this approach if your company has projects or applications that require different levels of security.

A security zone is associated with a compartment and a security zone recipe. When you create and update resources in a security zone, Oracle Cloud Infrastructure validates these operations against the policies in the security zone recipe. If any security zone policy is violated, then the operation is denied. By default, any subcompartments are also in the same security zone.

Security zone policies align with Oracle security principles, including:

  • Data in a security zone can't be copied to a compartment that's not in the zone because it might be less secure.
  • Resources in a security zone must not be accessible from the public internet.
  • Resources in a security zone must use only configurations and templates approved by Oracle.

In this approach, you create compartments and security zones for projects that must comply with our maximum security architecture and best practices. For projects that don't require this level of security compliance, you create compartments that aren't in security zones. You can also create custom recipes for your security zones that only enable a subset of available policies.

Similar to the previous approach, you can add a dedicated administrator group for each compartment who can then set the access policies for that single project.

  • Access (IAM) policies grant users the ability to manage certain resources in a compartment.
  • Security zone policies ensure that management operations in a security zone compartment comply with Oracle security best practices.
Caution

To ensure the integrity of your data, you can't move certain resources from a compartment in a security zone to a compartment that's not in a security zone.

To learn more, see Overview of Security Zones.