| name | oraclecloud-enterprise-rbac |
| description | Design OCI compartment hierarchies, dynamic groups, and cross-tenancy access patterns.
Use when planning enterprise RBAC, setting up Instance Principal auth, or debugging policy inheritance.
Trigger with "oraclecloud enterprise rbac", "oci compartments", "oci dynamic groups", "oci policy inheritance".
|
| allowed-tools | Read, Write, Edit, Bash(pip:*), Bash(oci:*), Grep |
| version | 1.7.0 |
| license | MIT |
| author | Jeremy Longshore <jeremy@intentsolutions.io> |
| tags | ["saas","oraclecloud","oci"] |
| compatibility | Designed for Claude Code |
Oracle Cloud Enterprise RBAC
Overview
OCI compartments are powerful but the inheritance model is confusing. Policies at root vs compartment level behave differently, dynamic groups enable compute-to-service auth without API keys, and cross-tenancy access requires matching policies on both sides. Most teams get this wrong and over-permission everything with manage all-resources in tenancy. This skill designs proper compartment hierarchies with least-privilege access.
Purpose: Build a scalable, least-privilege OCI organization structure using compartments, policy inheritance, dynamic groups, and tag-based access control.
Prerequisites
- OCI Python SDK —
pip install oci
- OCI config file at
~/.oci/config with valid credentials (user, fingerprint, tenancy, region, key_file)
- Tenancy administrator access — compartment and policy creation requires root-level permissions
- Familiarity with OCI IAM basics (see
oraclecloud-security-basics for policy syntax)
- Python 3.8+
Instructions
Step 1: Design the Compartment Hierarchy
OCI compartments are nested organizational units. Unlike AWS accounts, they share a single tenancy with inherited policies. A standard enterprise layout:
Root (Tenancy)
├── shared-infra ← DNS, networking hub, shared services
├── security ← Vault, audit logs, Cloud Guard
├── dev
│ ├── dev-compute ← Dev instances, OKE clusters
│ └── dev-data ← Dev databases, object storage
├── staging
│ ├── staging-compute
│ └── staging-data
└── prod
├── prod-compute
└── prod-data
Create this hierarchy programmatically:
import oci
config = oci.config.from_file("~/.oci/config")
identity = oci.identity.IdentityClient(config)
tenancy_id = config["tenancy"]
def create_compartment(parent_id, name, description):
"""Create a compartment and return its OCID."""
result = identity.create_compartment(
oci.identity.models.CreateCompartmentDetails(
compartment_id=parent_id,
name=name,
description=description
)
)
print(f"Created: {name} ()")
result.data.
shared = create_compartment(tenancy_id, , )
security = create_compartment(tenancy_id, , )
dev = create_compartment(tenancy_id, , )
staging = create_compartment(tenancy_id, , )
prod = create_compartment(tenancy_id, , )
dev_compute = create_compartment(dev, , )
dev_data = create_compartment(dev, , )
prod_compute = create_compartment(prod, , )
prod_data = create_compartment(prod, , )
