7.3 OCI IAM Policy Syntax, Inheritance & Structure

7.3 OCI IAM Policy Syntax, Inheritance & Structure

[!NOTE] Foundations Blueprint Focus: OCI IAM policies are declarative authorization statements that control access to every resource in your tenancy. The 1Z0-1085-26 exam heavily tests the canonical policy syntax, the strict four-verb hierarchy (inspect, read, use, manage), resource type granularity (individual vs. family types), and compartment downward inheritance rules.

In Oracle Cloud Infrastructure, authentication verifies who a principal is, but authorization determines what actions that principal can execute. Authorization in OCI is enforced entirely through Policies.

OCI IAM uses a declarative, natural-language policy syntax that is both human-readable and mathematically unambiguous. By default, OCI operates under a strict Zero Trust, Default-Deny security posture: when an IAM user or dynamic group is created, it possesses zero permissions. No principal can list, view, create, or modify any cloud resource until an explicit policy statement permits that specific action.

[!IMPORTANT] No DENY Statements in OCI IAM: Unlike some other cloud platforms that support explicit "DENY" statements, OCI IAM policies support only ALLOW statements. You cannot write a statement that says DENY group Developers TO.... Access is denied by default; permission exists solely if an explicit ALLOW policy statement covers the request.

---

The Canonical Policy Anatomy

Every OCI IAM policy statement conforms to a standardized, five-part grammatical syntax:

ALLOW <subject> TO <verb> <resource-type> IN <location> WHERE <condition>

+-------------------------------------------------------------------------+
|                    OCI IAM POLICY SYNTAX DECONSTRUCTION                 |
+-------------+--------+------------------+------------------+------------+
|   SUBJECT   |  VERB  |  RESOURCE-TYPE   |     LOCATION     |  CONDITION |
+-------------+--------+------------------+------------------+------------+
| group       | inspect| instances        | tenancy          | WHERE      |
| NetworkAdmin| read   | virtual-network- | compartment Dev  | request... |
| dynamic-    | use    |   family         | compartment      |            |
|   group App | manage | all-resources    |   Prod:DBTier    |            |
+-------------+--------+------------------+------------------+------------+

1. Subject: Who Is Granted Access?

The subject specifies the principal entity receiving permission:

• Standard Group: group <group-name> (or within an identity domain: group '<domain-name>'/'<group-name>').
• Dynamic Group: dynamic-group <dynamic-group-name>.
• Crucial Rule: The subject can never be an individual user. Statements such as ALLOW user jdoe TO... are syntactically invalid in OCI IAM.

2. Verb: The Four-Level Permission Hierarchy

OCI simplifies hundreds of underlying API operations into exactly four hierarchical verbs. Each verb represents an escalating tier of privilege, where higher verbs inherently encompass all capabilities of the verbs below them:

1. inspect (Lowest Privilege):
   • Grants the minimal ability to list resources without viewing confidential configuration details or user-specified metadata.
   • Example: An auditor can execute ListInstances to see that virtual machines exist, but cannot view instance OCIDs, IP addresses, or attached storage configurations.
2. read:
   • Includes all capabilities of inspect PLUS the ability to view user-specified metadata and inspect the full configuration details of the resource.
   • Example: A monitoring engineer can execute GetInstance to view private IP addresses, VNIC attachments, and resource state. However, read is strictly non-operational; it cannot start, stop, modify, create, or delete resources.
3. use:
   • Includes all capabilities of read PLUS the ability to work with and operate existing resources.
   • Capabilities under use vary by resource type, such as starting, stopping, and rebooting compute instances, attaching block storage volumes, or writing objects into an existing bucket.
   • Critical Boundary: use CANNOT create new resources or permanently delete existing resources. A user with use permissions on instance-family can reboot a server, but cannot provision a new VM or terminate an existing VM.
4. manage (Highest Privilege):
   • Includes all capabilities of use PLUS full administrative lifecycle control.
   • Grants complete authority to create, provision, update, reconfigure, move across compartments, and delete/terminate resources.

3. Resource-Type: What Is Being Accessed?

OCI supports both granular, service-specific resource types and aggregate "family" resource types:

• Individual Resource Types: Target a specific cloud component. Examples include instances, boot-volumes, vcns, subnets, route-tables, security-lists, buckets, objects, and autonomous-databases.
• Family Resource Types: Aggregate multiple related individual resource types into a single convenient keyword. Examples include:
  • virtual-network-family: Grants rights across VCNs, subnets, route tables, security lists, internet gateways, NAT gateways, service gateways, and local peering gateways.
  • instance-family: Grants rights across compute instances, custom images, boot volumes, and console connections.
  • database-family: Grants rights across Autonomous Databases, DB Systems, Exadata infrastructure, and database backups.
  • object-family: Grants rights across Object Storage buckets and objects.
  • volume-family: Grants rights across Block Volumes, boot volumes, volume backups, and volume groups.
  • all-resources: The ultimate aggregate; grants rights across every single resource type in OCI.

4. Location: Where Does the Policy Apply?

The location establishes the administrative boundary where permissions are valid:

• Tenancy Root: IN TENANCY grants permissions across the tenancy root compartment and cascades to all child compartments.
• Specific Compartment: IN COMPARTMENT <compartment-name> restricts permissions strictly to the named compartment and any sub-compartments nested beneath it.

5. Condition (WHERE Clause): Granular Contextual Restrictions

An optional WHERE clause enforces contextual or attribute-based restrictions using boolean logic:

• Requiring MFA: WHERE request.user.mfaTotpVerified = 'true'
• Source IP Restriction: WHERE request.network.source-ip = '203.0.113.0/24'
• Tag-Based Access Control: WHERE target.resource.tag.Finance.CostCenter = '1042'

---

The Four Verbs: Comprehensive Comparison Matrix

---

Compartment Hierarchy and Downward Inheritance

Compartments are logical boundaries used to organize and isolate cloud resources. Compartments can be nested up to six levels deep beneath the root compartment. Policies exhibit a fundamental architectural behavior called Downward Inheritance:

+-------------------------------------------------------------------------+
|                 COMPARTMENT DOWNWARD INHERITANCE MODEL                  |
+-------------------------------------------------------------------------+
| ROOT TENANCY                                                            |
| Policy: ALLOW group SecAdmins TO inspect all-resources IN TENANCY       |
|         +-----------------------------------------------------+         |
|         |                                                     |         |
|         v                                                     v         |
|  +-----------------------------+               +---------------------+  |
|  | COMPARTMENT DEV             |               | COMPARTMENT PROD    |  |
|  | (Inherits SecAdmins inspect)|               | (Inherits SecAdmins)|  |
|  | Local Policy:               |               | Local Policy:       |  |
|  | ALLOW group DevTeam TO      |               | ALLOW group Ops TO  |  |
|  | manage instance-family      |               | use instance-family |  |
|  | IN COMPARTMENT Dev          |               | IN COMPARTMENT Prod |  |
|  +--------------+--------------+               +----------+----------+  |
|                 |                                         |             |
|                 v                                         v             |
|  +-----------------------------+               +---------------------+  |
|  | NESTED: DEV_SANDBOX         |               | NESTED: PROD_DB     |  |
|  | Inherits: SecAdmins inspect |               | Inherits: SecAdmins |  |
|  | Inherits: DevTeam manage    |               | Inherits: Ops use   |  |
|  +-----------------------------+               +---------------------+  |
+-------------------------------------------------------------------------+

The Rules of Downward Inheritance

1. Universal Cascade: Any policy attached at a parent level (such as IN TENANCY) automatically cascades down to all child compartments and sub-compartments within that branch.
2. No Child Overrides: A child compartment cannot diminish, block, or revoke permissions inherited from a parent compartment. Because OCI has no DENY statement, a child compartment administrator cannot restrict access previously granted at the tenancy root.
3. Attachment Location vs. Target Scope:
   • A policy written at the root compartment can target child compartments (e.g., a policy attached to Root stating: ALLOW group AppDevs TO manage instance-family IN COMPARTMENT ProjectA).
   • A policy written inside a child compartment can only grant permissions within that compartment or its own sub-compartments. It is impossible for a policy residing inside a child compartment to grant access IN TENANCY or in peer compartments.

---

Applying the Principle of Least Privilege in OCI

The Principle of Least Privilege dictates that users and applications must be granted only the minimum permissions necessary to perform their required job functions:

• Avoid Overusing all-resources: Reserve all-resources strictly for Tenancy Administrators (Administrators group). Departmental engineers should be granted family types (virtual-network-family, instance-family) or individual resource types.
• Use use Instead of manage: Daily support engineers rarely need to provision or delete infrastructure. Granting use allows them to reboot virtual machines and troubleshoot issues without risking accidental resource destruction.
• Scope to Specific Compartments: Avoid granting IN TENANCY to project teams. Confine project teams to dedicated compartments (IN COMPARTMENT Dev_Team).
• Enforce Conditions: Mandate MFA verification for sensitive production actions using WHERE request.user.mfaTotpVerified = 'true'.