9.1 IAM Policy Design: Verbs, Conditions, Dynamic Groups & Principals

7.1 IAM Policy Design: Verbs, Conditions, Dynamic Groups & Principals

The Anatomy of Advanced IAM Policy Syntax

Oracle Cloud Infrastructure uses a declarative policy language built on least privilege. All access is denied by default, and a principal can do only what allow statements grant. Allow statements are additive across all applicable policies in the tenancy and compartment hierarchy.

OCI also offers deny policies as an opt-in feature that an administrator must enable. Deny statements use the same syntax but begin with deny (also deny admit and deny endorse for cross-tenancy statements). They explicitly block actions, for example to stop anyone except a security team from changing certain policies. Members of the default domain's Administrators group are always exempt from deny policies, so the tenancy can never lock itself out.

Every policy statement adheres to a formal syntactic structure:

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

Understanding each component of this grammar is essential for enterprise governance:

• <subject>: Identifies the principal being authorized. This can be a domain-qualified group (group IdentityDomainName/GroupName or group GroupName within the evaluating domain), a dynamic group (dynamic-group DynamicGroupName), or all authenticated tenancy users (any-user).
• <verb>: Specifies the level of access granted (inspect, read, use, manage). Verbs operate cumulatively.
• <resource-type>: Identifies the cloud resource or family of resources being targeted (e.g., virtual-network-family, instance-family, buckets, secret-bundles).
• <location>: Defines the compartment boundary where permissions apply. This is expressed as tenancy (granting access across all compartments in all subscribed regions) or compartment <compartment-name>. For nested compartment hierarchies, paths are expressed using colon notation: compartment ParentCompartment:ChildCompartment or by targeting a specific OCID: compartment id <compartment-ocid>.
• where <conditions>: An optional clause that refines authorization using boolean expressions and environmental context.

---

Verb Hierarchy and Granular Resource Types

OCI structures access through an ordered verb hierarchy. Each ascending verb level inherits all capabilities of the verbs below it:

1. inspect: The lowest access tier. Grants permission to discover and list resources of the specified type without viewing user data, sensitive attributes, or resource contents. For example, inspect instances allows listing compute instance OCIDs, display names, and lifecycle states, but prohibits viewing instance metadata, VNIC IP attachments, or console history.
2. read: Encompasses inspect and adds permission to view user-defined metadata and retrieve actual resource contents. For instance, read buckets allows listing and downloading objects from an Object Storage bucket, while read instances exposes attached volume details and IP configurations. The read verb does not permit modifying, creating, or terminating resources.
3. use: Encompasses read and adds permission to work with existing resources, modify operational parameters, and execute operational state changes. For example, use instances allows starting, stopping, and rebooting existing virtual machines, and attaching block volumes. However, use prohibits creating new resources or permanently deleting/terminating existing resources.
4. manage: The highest tier. Grants complete administrative control, encompassing inspect, read, use, plus the creation and permanent destruction (deletion/termination) of resources.

Individual vs. Family Resource Types

OCI organizes resource types into individual types (fine-grained control over a specific resource) and family types (aggregate groupings encompassing all related subordinate types):

• Individual resource examples: vcns, subnets, route-tables, security-lists, instances, instance-images, buckets, objects.
• Family resource examples: virtual-network-family, instance-family, object-family, database-family, all-resources.

Enterprise security architecture mandates granting permissions using individual resource types whenever possible. Granting manage virtual-network-family to application developers allows them to alter core routing tables and Internet Gateways, whereas granting use subnets allows them to attach virtual network interfaces (VNICs) to existing subnets without granting the power to alter network security architecture.

---

OCI IAM Policy Verb Hierarchy & Operational Scope

---

Where-Clause Conditions: Network Scoping, MFA Enforcement & ABAC Tags

Where-clause conditions allow architects to inject contextual zero-trust evaluations into policy decisions. Conditions evaluate request context (request.*) and target resource attributes (target.*).

1. Network Perimeter Enforcement

Policies can restrict API calls to requests that come from approved networks. You first create a network source (a named set of public CIDR blocks and/or VCN addresses), then reference it in a condition:

Allow group SecurityAdmins to manage all-resources in tenancy
  where request.networkSource.name = 'corpnet'

2. Mandatory Multi-Factor Authentication (MFA)

To protect mission-critical environments against compromised API signing keys or stolen user sessions, architects can mandate that the caller has completed multi-factor authentication:

Allow group ProductionOps to manage database-family in compartment Production
  where request.user.mfaTotpVerified = 'true'

If a user authenticates without completing an MFA challenge (such as invoking an API script with an un-stepped session), OCI denies the request with an authorization error (often reported as NotAuthorizedOrNotFound).

3. Attribute-Based Access Control (ABAC) Using Defined Tags

Role-Based Access Control (RBAC) often leads to policy explosion in large enterprises. OCI solves this through Attribute-Based Access Control (ABAC), using Defined Tag namespaces to govern access dynamically:

Allow group Developers to manage instance-family in compartment Development
  where target.resource.tag.Project.Environment = 'NonProduction'

Furthermore, architects can enforce dynamic ownership matching between the calling user's group and the target resource:

Allow group CostCenterAdmins to manage all-resources in compartment SharedWorkloads
  where request.principal.group.tag.Finance.CostCenter = target.resource.tag.Finance.CostCenter

This single policy dynamically authorizes hundreds of project groups across the tenancy without requiring individual group-to-compartment policy statements.

---

Dynamic Groups and Resource Principals Architecture

Traditional architectures frequently embed static administrative credentials, OCI API signing keys, or private SSH keys inside compute virtual machines, container configurations, or application source code. If code repositories leak or an instance is compromised, static credentials provide adversaries with uninhibited lateral movement across the tenancy.

OCI eliminates static machine credentials through Dynamic Groups and Resource Principals.

Dynamic Groups

A Dynamic Group is an IAM principal whose membership is determined dynamically at runtime based on matching rules evaluated against resource metadata. Instead of adding human users, architects define membership criteria for OCI resources:

All {instance.compartment.id = 'ocid1.compartment.oc1..aaaaaaaaxxx', tag.Operations.Tier = 'Backend'}

Membership rules support logical operators: Any { ... } (OR) and All { ... } (AND). Any compute instance, autonomous database, or function meeting the rule automatically inherits all IAM policies granted to that dynamic group.

Resource Principals

Resource Principals extend this paradigm to serverless, containerized, and managed services. When an OCI Function, OKE Pod (via Workload Identity), OCI Data Flow application, or OCI Data Science job invokes an OCI API, it does not supply an API signing key. Instead, the application utilizes the OCI SDK configured for Resource Principal authentication:

OCI uses several principal types for non-human callers:

• Instance principals: a compute instance in a dynamic group obtains short-lived certificates from the instance metadata service and signs API calls with them. Every process on the instance shares that identity.
• Resource principals: services such as OCI Functions, Data Flow, Data Science jobs, Full Stack DR protection groups, and DevOps pipelines receive a resource principal session token from the service environment (for Functions, the runtime injects it into the container). Matching rules use resource.type, for example resource.type = 'fnfunc'.
• OKE workload identity: pods in enhanced clusters authenticate as a specific cluster, namespace, and service account.

In every case the SDK obtains and refreshes short-lived credentials automatically, and IAM evaluates the policies written for the dynamic group or workload:

Allow dynamic-group PaymentProcessingFunctions to read secret-bundles in compartment Finance

Because these credentials are short-lived and issued automatically, there are no API keys to store, rotate, or leak from source repositories.