Article 03 – OCI Policy Language Fundamentals: Syntax, Verbs, and Scope

1. Introduction to the OCI Policy Engine

In Oracle Cloud Infrastructure (OCI), authorization is controlled by a plain-text, SQL-like declarative policy language.

Unlike platforms that rely on complex JSON permission documents or predefined role assignments, OCI policies use human-readable statements that explicitly define who can perform what actions on which resources inside a specific location.

By default, OCI enforces a strict zero-trust denial model: users have no permissions to perform any actions on any resources until an explicit policy statement grants them access.

2. Policy Statement Structure and Syntax

Every OCI policy consists of one or more plain-text statements following a standardized grammar:

Allow <subject> to <verb> <resource-type> in <location> [where <conditions>]

Breakdown of Syntax Elements:

1. Allow: The mandatory opening keyword. OCI policies are exclusively allow-based.
2. <subject>: Specifies who receives the permissions. This must be a Group, a Dynamic Group, or a Service (e.g., group Dev-Admins, dynamic-group App-Instances).
3. <verb>: Specifies the level of access granted. OCI groups all API operations into four progressive verbs: inspect, read, use, or manage.
4. <resource-type>: Specifies the target cloud service or resource family (e.g., instance-family, virtual-network-family, buckets).
5. <location>: Defines the compartment boundary where the policy applies (in compartment Dev-Compartment or in tenancy).
6. where <conditions> (Optional): Additional conditional clauses restricting access based on tags, IP sources, user attributes, or target metadata.

3. The Four Progressive Verbs

To keep access control simple and auditable, OCI compresses thousands of granular API operations into four progressive verbs:

inspect ➔ read ➔ use ➔ manage  (Increasing level of access)

[!IMPORTANT]
The Critical Difference Between use and manage
Granting use instance-family allows an operator to reboot, stop, and attach VNICs to an existing VM. However, it does NOT grant permission to create a new VM or terminate (delete) an existing VM. Creating or destroying compute workloads requires the manage verb.

4. Policy Inheritance and Location Scope

OCI IAM policies are attached to a specific container in the resource hierarchy—either the Root Tenancy or a Child Compartment.

Rules of Policy Inheritance:

1. Top-Down Cascading: A policy attached at a parent container automatically applies to all child compartments nested beneath it.
2. Root Tenancy Scope: A policy written in tenancy applies globally across all compartments and regions in the account.
3. Compartment Scope: A policy written in compartment Engineering automatically inherits down to Engineering ➔ Dev and Engineering ➔ Stage, but has zero effect on sibling compartments like Production.

Policy Attached at Root Tenancy:
Allow group SecOps to read all-resources in tenancy
       │
       ▼ (Inherits Down Automatically)
├── Network-Compartment (Read Access Granted)
├── Engineering-Compartment (Read Access Granted)
│   └── Dev-Compartment (Read Access Granted)
└── Production-Compartment (Read Access Granted)

[!WARNING]
No Explicit “Deny” Statements in OCI
OCI IAM policies do NOT support Deny statements. You cannot grant access at the Root Tenancy and then add a Deny statement at a child compartment to block inheritance. Authorization is strictly additive based on Allow rules.

5. OCI Web Console (GUI) Step-by-Step Walkthrough

Managing IAM policies is executed directly inside the OCI Web Console GUI.

Step 1: Navigating to the Policy Interface

1. Log in to the Oracle Cloud Console (https://cloud.oracle.com).
2. Click the Navigation Menu (≡) in the top-left corner.
3. Select Identity & Security, then click Policies under the Identity column.

Console Path: [≡ Main Menu] ➔ [Identity & Security] ➔ [Identity] ➔ [Policies]

Step 2: Creating a Policy Using the GUI Policy Builder

1. On the Policies page, select the target compartment from the left-hand Compartment dropdown (e.g., Dev-Compartment).
2. Click Create Policy.
3. In the panel, specify:
4. Name: DevNetworkManagementPolicy
5. Description: Allow network team to manage VCNs in Dev.
6. Compartment: Ensure Dev-Compartment is selected.
7. Under Policy Builder:
8. Toggle the switch to Show manual editor to type raw policy statements, OR use the GUI dropdowns:
   • Verb: manage
   • Resource Type: virtual-network-family
   • Group: Dev-Network-Admins
   • Location: Dev-Compartment
9. Click Create.

Generated Policy Statement:
Allow group Dev-Network-Admins to manage virtual-network-family in compartment Dev-Compartment

6. Common Architectural Misconceptions & Pitfalls

Misconception 1: “IAM Policies Can Be Attached to Individual Users”

• Reality: OCI policies can ONLY be assigned to Groups or Dynamic Groups. You cannot write Allow user john.doe to....

Misconception 2: “Attaching a Policy in a Compartment Restricts the Subject to That Compartment”

• Reality: The location clause in the policy statement (in compartment Dev-Compartment) determines where the resources live, NOT where the policy document file is saved in the Console UI.

Misconception 3: “Verb Permissions Can Be Selectively Disabled”

• Reality: Verbs are cumulative. Granting manage automatically includes all permissions from use, read, and inspect. You cannot grant manage while revoking read.

7. OCI Policy Language vs. Google Cloud (GCP) IAM Roles

For architects familiar with Google Cloud, the following table compares permission assignment models: