Posted on Jun 20

Introduction to IAM in Oracle Cloud Infrastructure

#oracle #cloud #iam #security

🚀 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 🔜