🚀 Just Started Exploring OCI – Part 1
🔐 Identity & Access Management (IAM) + 🔄 Compartments + 🌍 Regions
I’ve started diving into Oracle Cloud Infrastructure (OCI) and here’s what I’ve picked up so far from IAM & resource organization.
🔑 IAM = Who can do What on Which resources, and Where 🔐
OCI’s Identity and Access Management (IAM) system helps you secure cloud resources by defining:
🧍♂️ Users
👥 Groups
🔐 Policies
📦 Compartments
🛠️ Resources
IAM Flow:
👉 Create Identity Domain
👉 Add Users
👉 Organize into Groups
👉 Define Policies for groups
👉 Scope them to Compartments inside your Tenancy
👉 Grant access to Resources 💥
🧠 IAM Concepts:
AuthN (Authentication) = Who you are
🔸 Username/password
🔸 API signing keys
🔸 Auth tokens
🔸 SAML, OAuth2
AuthZ (Authorization) = What you’re allowed to do
✅ Authorization in OCI is handled through policies. These are plain-text statements that grant permissions to groups, not individual users, to perform actions on resources in specific compartments.
📜 Policies: Plain, Powerful & Human-readable
Example:
Allow group DevTeam to manage compute-instances in compartment ProjectA
🧠 Understanding IAM Policies in OCI
Policies are defined using a simple, human-readable language that specifies:
- Who (a group)
- What permissions (verbs like inspect, read, use, or manage)
- On what resource types (like instances, buckets, volumes)
- In which compartment or tenancy
Verbs:
- inspect: List and view metadata.
- read: View full details (but no updates).
- use: Perform standard operations (start/stop, etc.).
- manage: Full control (create/update/delete).
Policy Scope:
- Policies can be defined at the tenancy level (global) or at a compartment level (scoped).
- You can also create dynamic groups (for resources like instances or functions) and attach policies to allow them to access other OCI services—ideal for automation or service-to-service communication.
🗂️ Compartments = Logical Isolation
Think of compartments as folders 🗃️:
- Group resources by team/project/type
- Root compartment holds everything, but best to organize using sub-compartments
- Up to 6 levels of nesting allowed
Resources can:
- 🔄 Move between compartments
- 🌐 Belong to multiple regions
- 🔗 Interact across compartments
🆔 OCID – Oracle Cloud Identifier
Every OCI resource gets a globally unique ID:
ocid1.<resource_type>.<realm>.[region].<unique_id>
Useful for tracing, automation, and scripting!
🌍 Regions, Availability Domains, and Fault Domains – for High Availability
OCI is designed to minimize single points of failure (SPOF) and maximize uptime 🔁:
🟢 Region
│
├── 🟢 Availability Domains (ADs)
│ ├── 🔹 Fault Domain 1
│ ├── 🔹 Fault Domain 2
│ └── 🔹 Fault Domain 3
│
└── 🪢 Region Pair (for disaster recovery)
- Region: Geographical location (e.g., India Central, US East)
- Availability Domain (AD): Physically isolated DC within a region
- Fault Domain: Logical group within an AD – protects from rack/power failures
✅ Use multiple fault domains within an AD for HA
✅ Use multiple ADs across a region for redundancy
✅ Use Region Pairs for cross-region disaster recovery (DR)
🔐 IAM Best Practices in OCI
Start by creating an Identity Domain, then define users, group them
- logically (e.g., by role or function), and attach policies to groups.
- Avoid using the tenancy administrator for daily work—create least-privilege roles.
- Enable MFA for all users to prevent unauthorized access.
- Use dedicated compartments for network, compute, security, audit logs, etc.
- Regularly review and clean up unused users, groups, and policies.
IAM in OCI is built with enterprise-grade flexibility and security in mind. Whether you're building a secure landing zone, managing team access, or automating deployments, understanding IAM is essential to running a scalable and secure OCI environment.
💭 That's it for Part 1 of my OCI Journey! IAM + Compartments + Regions made clear 🧠
Coming up next: Networking, Compute & Storage modules 🔜
Top comments (2)
Nice blog Vishnu, looking forward for the next one :)
Fantastic App – feature-rich and intuitive.