How do OCI policy verbs differ from AWS IAM actions?

OCI uses four cumulative verb levels — inspect, read, use, and manage — where each higher level includes all permissions of the lower levels. This is simpler than AWS where you specify individual API actions. For example, 'manage virtual-network-family' grants all networking permissions, while 'read virtual-network-family' allows listing and viewing but not modifying. This verb hierarchy reduces policy complexity but requires understanding which operations fall under each level.

What is the difference between identity policies and resource policies in OCI?

Identity policies are attached to compartments and grant permissions to groups or dynamic groups. Resource policies (Endorse/Admit/Define statements) enable cross-tenancy access. An Endorse statement in the source tenancy says a group can access resources in another tenancy, while an Admit statement in the destination tenancy accepts that access. Both must exist for cross-tenancy operations to work.

Can I scope OCI policies to specific resources rather than entire compartments?

Yes, you can use where clauses with conditions like target.resource.id, target.resource.compartment.id, or tag-based conditions such as target.resource.tag.namespace.key='value'. This lets you create fine-grained policies that apply only to specific resources or groups of tagged resources within a compartment.

OCI IAM Policy Builder

IAM & SecurityOCI

Build OCI IAM policy statements with compartment scope, verbs, and resource types.

Last verified: May 2026

OCI IAM Policy Configuration

Policy Name

Compartment OCID

Description

Statement 1

Subject

Verb

Resource Type

Location

Conditions (optional)

Output Format

Policy name is required
Compartment is required

Generated OCI IAM Policy

Output will appear here...

About This Tool

Oracle Cloud Infrastructure uses a human-readable policy language that is fundamentally different from the JSON-based policies in AWS or Azure. Policies follow the pattern Allow <subject> to <verb> <resource-type> in <location> where <conditions>, and getting the syntax right — especially compartment paths, verb levels (inspect, read, use, manage), and condition matching — can be tricky. The OCI IAM Policy Builder provides guided inputs for each policy component and generates syntactically correct policy statements. It supports both identity-based and resource-based policies, including cross-tenancy endorsement and admission statements.

Real-World Scenario

Your team is migrating a production workload to OCI and needs 4 IAM policies: developers can manage compute in dev compartment, ops can manage networking across all compartments, security can read everything everywhere, and a dynamic group for OKE worker nodes can access object storage. The builder generates each statement with correct syntax in 5 minutes. Without the tool, the team would have spent 2-3 hours hand-crafting policy strings, hitting syntax errors on first apply, and debugging from cryptic 'NotAuthorizedOrNotFound' errors.

When to Use This Tool

•Building compartment-scoped policies that grant developers manage access to compute instances but only read access to networking resources
•Creating cross-tenancy policies using Endorse and Admit statements for sharing resources between OCI tenancies
•Generating condition-based policies that restrict actions by request.region, target.compartment.name, or tag namespaces
•Building service-level policies that allow OCI services like Functions or Container Engine to access other resources on your behalf

Pro Tips

TIP

OCI's verb hierarchy (inspect → read → use → manage) is fundamentally simpler than AWS's individual action lists. The downside: it's coarser-grained. If you need 'read most things but not list secrets', you may need to combine 'read <type>' with explicit deny conditions, or use multiple narrow groups.

TIP

The most common OCI policy mistake is forgetting compartment hierarchy. A policy at the tenancy root applies everywhere. A policy in a compartment applies only there. If you grant 'manage all-resources in compartment X' to a group, they have no access to compartment Y unless explicitly granted there too.

TIP

Always use dynamic groups for service-to-service auth, not pre-shared credentials. A dynamic group + matching rule (e.g., `instance.compartment.id = '...'`) lets all VMs in a compartment automatically authenticate as that group. No keys to rotate, no secrets to leak.

How It Works Under the Hood

The builder constructs OCI policy statements following the canonical syntax: `Allow <subject> to <verb> <resource-type> in <location> where <conditions>`. It validates verb levels (inspect/read/use/manage), resource type spellings against the OCI catalog, compartment paths, and condition expressions. Output is generated as policy statement strings ready to paste into the OCI console, oci CLI commands, or Terraform oci_identity_policy resources.

Frequently Asked Questions

How do OCI policy verbs differ from AWS IAM actions?: OCI uses four cumulative verb levels — inspect, read, use, and manage — where each higher level includes all permissions of the lower levels. This is simpler than AWS where you specify individual API actions. For example, 'manage virtual-network-family' grants all networking permissions, while 'read virtual-network-family' allows listing and viewing but not modifying. This verb hierarchy reduces policy complexity but requires understanding which operations fall under each level.
What is the difference between identity policies and resource policies in OCI?: Identity policies are attached to compartments and grant permissions to groups or dynamic groups. Resource policies (Endorse/Admit/Define statements) enable cross-tenancy access. An Endorse statement in the source tenancy says a group can access resources in another tenancy, while an Admit statement in the destination tenancy accepts that access. Both must exist for cross-tenancy operations to work.
Can I scope OCI policies to specific resources rather than entire compartments?: Yes, you can use where clauses with conditions like target.resource.id, target.resource.compartment.id, or tag-based conditions such as target.resource.tag.namespace.key='value'. This lets you create fine-grained policies that apply only to specific resources or groups of tagged resources within a compartment.

Related Learning Guides

OCI IAM, Compartments & Policies22 min read
OCI Security Best Practices24 min read

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.