Compartment design and movement: policy implications

Problem

Compartments split resources and policy scope, and the layout you choose on day one is hard to change quietly. When a compartment moves, the set of policies that apply to it can change with it, and people can gain or lose access without anyone editing a statement.

I wanted a hierarchy that makes moves boring and lets me check the result afterwards.

Options and trade-offs

• A flat design: simple, with few movement cases and limited delegation.
• A hierarchical design: flexible, with inherited access, and it needs careful names and ownership.
• Policies attached at a shared ancestor: they adjust automatically when a descendant moves under the same ancestor, and lower-level policies may need manual edits.

My recommendation

Use a clear hierarchy with named owners, and attach policies at an ancestor that will survive the moves you expect. After any move, verify access from the point of view of the people involved and fix anything that attached lower down.

Worked example

Take a move from A:B:C to A:D. Policies written at A, the common ancestor, keep working and update their path references. A policy attached inside B that named C by path no longer matches its target, and the access it granted disappears until someone rewrites it.

# Attached at A (the shared ancestor): survives the move
Allow group TeamA-Admins to manage all-resources in compartment A:Prod
Allow group TeamA-Users  to use instance-family in compartment A:Dev
 
# Attached inside A:B and naming C by path: must be reviewed after the move
Allow group TeamC to use instance-family in compartment A:B:C

Before a move, list the policies that mention the compartment and note which ancestor each is attached to. After the move, check access with a test user for each group. Quotas and budgets are set per compartment, so confirm them too.

Checklist

1. Define the hierarchy, names and owners before creating compartments.
2. Attach policies at ancestors that will not move.
3. Before a move, list the policies that reference the compartment.
4. After a move, test access for every affected group.
5. Use quotas and budgets at the compartment level as guardrails.
6. Avoid duplicate compartment names under the same parent.

Where this doesn't apply

Security zones have their own rules, and a move that crosses a zone boundary is restricted. Manage those through the Security Zones service.

One honest limitation

Changes in implicit access are easy to miss. Treat a move as a planned change with a validation step afterwards, and do not call it finished until you have checked.

Sources

• OCI Documentation: Managing Compartments (moving a compartment)
• OCI Documentation: Policy Syntax (compartment paths)
• OCI Documentation: Compartment Quotas and Budgets