Understanding Compartments and Policies in Oracle Cloud Infrastructure

When building on Oracle Cloud Infrastructure (OCI), organizing your cloud resources and controlling who can access them is critical. OCI offers a powerful and flexible model to achieve this using two key constructs: Compartments and IAM Policies.

Together, they form the backbone of resource isolation, access control, and governance in OCI. This post explains how they work individually and how they interact to enforce permissions and boundaries across your OCI tenancy.\

What Are Compartments in OCI?

A compartment is a logical container within your OCI tenancy used to organize and isolate cloud resources like compute instances, databases, storage, and networking components.

You can think of compartments as folders or projects. Each resource in OCI must reside in exactly one compartment.

Key Characteristics:

Compartment structure is hierarchical (you can nest compartments).
Designed to support multi-team and multi-project environments.
Resource visibility and control is based on where the resource is placed.
Helps with cost tracking, governance, and access isolation.

Common Use Cases:

Isolate environments like Dev, Test, Prod
Organize by department or application
Enforce different compliance or lifecycle policies per compartment

What Are Policies in OCI?

Policies define who can do what on which resources in your OCI tenancy. They are written in a human-readable language and attached to compartments or the tenancy root level.

OCI uses Identity and Access Management (IAM) to evaluate these policies when a user, group, or service principal makes a request.

Policy Format:

For example:

This allows all users in the DBAdmins group to manage any database resource within the Prod compartment.

Supported Verbs:

inspect (read metadata only)
read (full read access)
use (read and write except for lifecycle operations)
manage (full access including create, delete, update)

How Compartments and Policies Work Together

Here’s how they interoperate:

Resources live inside compartments.
When you create a compute instance, DB system, or object storage bucket, you must choose the compartment where it resides.
Policies determine access based on compartments.
Policies are always evaluated in context of a compartment. A policy grants or denies access to resources within a specific compartment, not across the entire cloud account unless explicitly scoped at the root level.
IAM evaluates user request in context.
When a user tries to perform an action, OCI checks:
- Is there a policy that allows the user (or their group) to take the action?
- Is the action permitted in the target compartment?
- Is the action allowed for the specific resource type?
Cross-compartment access is not automatic.
If a resource in compartment A needs to interact with a resource in compartment B, policies must be written to allow it. OCI doesn’t allow automatic cross-compartment permissions.

Best Practices for Designing Compartments and Policies

Start with a compartment strategy that reflects your org’s structure (e.g., environment, application, department).
Use nested compartments only when necessary. Too many levels can make policies harder to manage.
Define least privilege policies. Only give groups access to exactly what they need.
Use dynamic groups and resource principals to allow services like Functions or OKE to act on other resources securely.
Use tags to add metadata to resources for cost tracking and automation, in combination with compartments.
Monitor access using Audit logs and periodically review policies for stale permissions.

Example Scenario

You are managing a tenancy with separate compartments for Dev, Test, and Prod. You have groups like Developers, Testers, and DBAdmins.

You can define these policies:

Developers can create and manage compute instances in Dev only.

Allow group Developers to manage instance-family in compartment Dev
Testers can only read instances in Test.

Allow group Testers to read instance-family in compartment Test
DBAdmins can manage DB systems in all compartments.

Allow group DBAdmins to manage db-system in tenancy

This structure ensures that:

Teams work within their designated environments
Access is controlled and isolated
Auditing and compliance are easier

OCI’s compartment and policy model is designed to scale. Whether you are managing a small cloud footprint or an enterprise-wide deployment with dozens of teams, this model allows you to enforce segregation of duties, granular access control, and resource isolation—all while keeping things manageable and auditable.

Design your compartment layout thoughtfully, and write policies that reflect the principle of least privilege. Combined, they offer a secure and flexible foundation for any OCI architecture.