Policies

Resource Principals

Configure resource principal authentication for Full Stack Disaster Recovery by creating a dynamic group with matching rules for DR protection groups, compute instances, and compute container instances, then assigning IAM policies for DR and the OCI services managed during recovery. Required permissions vary by member type and can include disaster recovery, compute, storage, networking, databases, OKE, load balancer, Vault, Functions, Integration, tagging, and Object Storage access; replace placeholder dynamic-group and compartment values with actual identifiers.

Policies For Full Stack Disaster Recovery

This chapter defines the IAM policies required for Full Stack Disaster Recovery, covering policy concepts, resource types and permissions, REST API operation requirements, cumulative access levels for inspect, read, use, and manage verbs, and example policies for administering DR operations, configurations, and prechecks.

About IAM Policies For Disaster Recovery

IAM policies for Disaster Recovery can target individual resource types or the complete disaster-recovery-family. The family includes protection groups, plans, plan prechecks, plan executions, and work requests, allowing administrators to choose either granular or family-wide access controls.

Resource Types And Permissions

This page lists the permissions associated with each Full Stack Disaster Recovery resource type, including protection groups, plans, prechecks, executions, work requests, and the aggregate disaster-recovery-family. Permissions cover inspection, reading, creation, updates, deletion, and work-request monitoring.

Permissions For REST API Operations

Full Stack DR REST API operations require specific IAM permissions, with some operations accepting alternative permissions. The mappings cover creating, reading, updating, deleting, pausing, resuming, retrying, or canceling DR plans and executions, managing protection groups, and inspecting or controlling work requests.

Details Of Verb And Resource-Type Combinations

Access is cumulative across the inspect, read, use, and manage verbs. The page maps each verb to incremental permissions and REST APIs for protection groups, DR plans, plan executions, prechecks, and work requests, clarifying which operations become available at each access level.

Examples Of IAM Policy Definitions For Disaster Recovery

Example policies demonstrate how to grant tenancy-wide DR administration, compartment-scoped configuration and precheck execution, or configuration-only access. The examples use separate groups to illustrate full administration, monitored DR setup, and limited creation of protection groups and plans.

Policies For Other Services Managed By Full Stack Disaster Recovery

Because Full Stack DR orchestrates resources across the application stack, additional IAM policies are required for services such as Compute, Block Volume, Networking, Functions, databases, Autonomous Database, Object Storage, Tags, Vault, File Systems, load balancers, OKE, MySQL, PostgreSQL, compartments, Automatic DR, Integration, and Generative AI. The required policies depend on the selected member types and authentication method.

Policies For Compute Service And Oracle Cloud Agent

DR requires Compute and Oracle Cloud Agent permissions to manage movable and non-movable instances, volumes, networking, capacity reservations, images, and agent commands. Resource principal configurations use dynamic groups, while user authentication uses group policies; Oracle Cloud Agent also requires instance membership in a dynamic group and administrator privileges for command execution.

Policies For Block Volume Service

Block Volume and volume group recovery requires permissions to manage the volume family and read Vaults and secrets when resource principal authentication is used. Equivalent user-authenticated policies grant the appropriate group access to volume resources, Vaults, and secrets within the target compartment.

Policies For Networking Service

Networking policies allow Full Stack DR to inspect virtual networking and use subnets, VNICs, network security groups, and private IPs. Equivalent resource principal and user-authenticated statements can be scoped to the compartment containing the application networking resources.

Policies For Functions Service

To invoke Functions from user-defined DR plan steps, the DR principal or user group must read the target application and function and use Function invocation permissions in the relevant compartment.

Policies For Oracle Database

Oracle Base Database and Exadata database recovery requires permissions to manage databases and read Vaults and secrets when using resource principals. User-based policies can grant full database-family management or restrict access to update operations for switchover and failover, with additional permissions for database homes, Data Guard associations, and supported VM cluster types.

Policies For Oracle Autonomous Database

Autonomous Database recovery requires resource principals to manage the autonomous database family, read Vaults and secrets, and manage Autonomous Container Databases where applicable. User policies can provide full management or restrict access to update and Data Guard operations for Serverless and dedicated Exadata deployments.

Policies For Log Location For Operation Logs

Full Stack DR needs Object Storage bucket and object management permissions to write operation logs during DR plan executions. The same bucket and object permissions can be granted either to the DR dynamic group or to a user group in the selected compartment.

Policies For Object Storage

Object Storage policies allow DR to manage buckets that participate in a DR protection group and to write execution logs. Resource principals use object-family management permissions, while user authentication grants equivalent permissions to a designated group.

Policies For Tags Service

DR requires permission to use tag namespaces when launching compute instances during plan execution. This access can be granted to the resource principal dynamic group or a user group at the tenancy level.

Policies For Vault Service

Vault policies allow DR to read Vaults and secrets, enabling retrieval of database credentials required during plan executions. Equivalent permissions can be assigned to the DR dynamic group or an authenticated user group within the relevant compartment.

Policies For File Systems

File system recovery requires resource principals to manage the file-family and read Vaults and secrets where credential access is needed. User authentication requires the designated group to manage the file-family in the target compartment.

Policies For Load Balancers

DR load balancer management requires the dynamic group or authenticated user group to manage load-balancers in the compartment containing the application’s load balancers.

Policies For Kubernetes Engine (OKE)

OKE recovery requires permissions to manage compute containers, Object Storage, clusters, and virtual node pools. Additional workload identity policies support Brie service accounts for virtual node pools, while managed node pools, container instances, and jump hosts require suitable dynamic groups and policies for cluster and bucket access.

Policies For MySQL Heatwave DB System

MySQL HeatWave recovery requires management of the MySQL resource family and, when needed, read access to Vault secrets and Object Storage for credentials and execution logs. Policies can be assigned to resource principals through dynamic groups or to user groups, with compartment-specific scoping.

Policies for PostgreSQL DB System

PostgreSQL recovery requires the dynamic group to manage PostgreSQL DB systems, backups, configurations, and work requests in the target compartment.

Policies For Network Load Balancers

Network load balancer recovery requires the resource principal dynamic group or authenticated user group to manage network-load-balancers in the relevant compartment.

Policies For Compartments

Compartment policies provide DR with read access to all resources in a specified compartment or across the tenancy. The access can be granted to a dynamic group for resource principals or to a user group through compartment- or tenancy-scoped statements.

Policies For Automatic DR Configuration

Resource principal authentication is a prerequisite for configuring Automatic Disaster Recovery.

Policies For Integration Instance

Integration instance recovery requires the resource principal dynamic group or authenticated user group to manage integration-instance resources in the target compartment.

Policies For Generative AI

Generative AI integration requires the DR dynamic group or authenticated user group to use the generative-ai-family in the relevant compartment. Existing Full Stack DR dynamic groups do not require matching-rule changes; only the additional policy statement is needed.

Oracle Cloud Infrastructure Documentation