DEV Community

Cover image for OCI IAM Policies Explained: How Authorization Actually Works
Lwandile Majola
Lwandile Majola

Posted on

OCI IAM Policies Explained: How Authorization Actually Works

#oci #iam #cloud #security

In Part 1, we looked at how Oracle Cloud Infrastructure is structured physically and logically.

Now comes the part where OCI usually starts to feel confusing in practice:
IAM policies

Policies are where OCI stops being theoretical and starts enforcing reality.
If something doesn’t work in OCI, nine times out of ten, it’s a policy issue.

Let’s break them down properly.

🧠 The One Rule to Remember

OCI IAM follows a strict rule:
Everything is denied by default.

There are no implicit permissions.
No “but I’m an admin” shortcuts.
If a policy doesn’t allow it, it won’t happen.

This makes OCI predictable and secure, but only if you understand how policies are evaluated.

🔐 What a Policy Really Does

A policy answers four questions:

Who → can do what → on which resources → where
Enter fullscreen mode Exit fullscreen mode

If any part is missing or wrong, access is denied.

Policies are not attached to users.
They are attached to groups and scoped to compartments or the tenancy.

🧱 Policy Syntax (The Core Pattern)

Every OCI policy follows the same structure:

Allow <Subject> to <Verb> <Resource-Type> in <Location> where <Condition>
Enter fullscreen mode Exit fullscreen mode

Once this clicks, policies become much easier to reason about.

👥 Subject: Who Is Allowed?

The subject defines who gets the permission.

Common options:

  • A group (most common)
  • A dynamic group (for compute instances)
  • any-user (rare, dangerous, usually avoided)

Example:

Allow group NetworkAdmins to manage virtual-network-family in compartment Prod
Enter fullscreen mode Exit fullscreen mode

Best practice:
Always grant permissions to groups, never individual users.

🧩 Verbs: What Actions Are Allowed?

OCI has four verbs, and they are cumulative.

🔍 Inspect

  • List resources
  • No sensitive data

📖 Read

  • Inspect +
  • View metadata and configuration

🛠️ Use

  • Read +
  • Interact with existing resources
  • Cannot create or delete

🧨 Manage

  • Full control
  • Create, update, delete

If someone can’t do something, check the verb first.

📦 Resource Types: What Is Being Accessed?

OCI groups related resources into families.

Examples:

  • instance-family
  • virtual-network-family
  • object-family
  • database-family

Using families avoids writing dozens of policies.

Example:

Allow group StorageAdmins to manage object-family in compartment Data
Enter fullscreen mode Exit fullscreen mode

📍 Location: Where the Policy Applies

Policies are scoped to:

  • The tenancy (root compartment), or
  • A specific compartment

Example:

Allow group DevOps to use instance-family in compartment Dev
Enter fullscreen mode Exit fullscreen mode

Important:

  • Policies attached to a parent compartment are inherited by children
  • OCI evaluates policies top-down

Best practice:
Attach policies at the lowest possible level.

🎯 Conditions: Making Policies Precise

The where clause is optional, but powerful.

It lets you restrict access using conditions like:

  • Compartment name
  • Resource OCID
  • Network source
  • Requesting group

Example:

Allow group Admins to manage all-resources in tenancy
where request.networkSource.name = 'CorpNet'
Enter fullscreen mode Exit fullscreen mode

This means:
Even admins must come from a trusted network.

🤖 Dynamic Groups (Policies for Compute)

Dynamic groups are how OCI grants permissions to instances, not people.

Example use case:

  • A compute instance needs access to Object Storage
  • No API keys
  • No stored credentials

You define:

  1. A dynamic group based on instance rules
  2. A policy granting permissions to that dynamic group

Example:

Allow dynamic-group AppServers to read object-family in compartment Data
Enter fullscreen mode Exit fullscreen mode

This is how Instance Principals work securely.

🧪 Common Policy Mistakes (Real-World Pain)

Here’s where people usually get stuck:

  • Granting read when use is required
  • Writing policies at tenancy level “just to test”
  • Forgetting policy inheritance
  • Using the wrong compartment
  • Mixing identity domain admin roles with OCI resource access

Quick check when something fails:

  1. Is the user in the right group?
  2. Is the policy in the correct compartment?
  3. Is the verb strong enough?
  4. Is a condition blocking access?

🧠 How OCI Evaluates Policies (Mental Model)

OCI evaluates policies like this:

  • Start at the resource’s compartment
  • Walk up the compartment hierarchy
  • Apply all matching policies
  • If any policy allows, access is granted
  • If none allow, access is denied

There are no explicit deny policies.
Silence equals denial.

🧭 Best Practices That Actually Scale

  • Design compartments first
  • Map roles to groups
  • Write policies per role, not per service
  • Use manage sparingly
  • Restrict admin access with network sources
  • Review policies regularly

Good IAM design feels boring.
That’s how you know it’s working.

✅ Final Takeaway

Policies are not configuration details.
They are your security model.

Once you understand:

  • Subjects
  • Verbs
  • Resource families
  • Compartments
  • Conditions

OCI IAM stops feeling strict and starts feeling precise.

That’s when you move from “why is this denied?”
to “I know exactly why this is allowed.”

🔔 What’s Coming Next

In the next article, we’ll shift focus to OCI networking, starting with Virtual Cloud Networks (VCNs).
We’ll break down how VCNs, subnets, route tables, gateways, and security lists fit together, and how networking decisions shape everything built on top of OCI.

Stay tuned.

Top comments (0)