Getting Started

Before you can get started with Exadata Fleet Update as shown in the diagram here, there are some prerequisites that need to be met. Review the prerequisites listed below carefully.

Figure 3-1 Exadata Fleet Update


This image provides an overview of how Exadata Fleet Update works

Required Network Setup

Review the security rules to use with your ExaDB-D Infrastructure. Security rules control the types of traffic allowed for the client network and backup network of the Exadata's compute nodes.

Security Rules for Oracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D)

Client Network

Client ingress rule 1: Allows TCP traffic from within the subnet ExaDB-D resides or Allows TCP traffic from within the ExaDB-D client subnet.

Stateless: No (all rules must be stateful)
Source Type: CIDR
Source CIDR: Client subnet's CIDR
IP Protocol: TCP
Source Port Range: All
Destination Port Range: 7085
Description: Optionally, add a meaningful description of the rule. For example, Allow access to Exadata Fleet Update private endpoint within the subnet.

General egress rule 1: Allows all egress traffic.

Stateless: No (all rules must be stateful)
Destination Type: CIDR
Destination CIDR: 0.0.0.0/0
IP Protocol: All

Required IAM Policies to Manage Collections

Review the IAM policies required to manage an Exadata Fleet Update collection of Oracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D) or Oracle Exadata Database Service on Cloud@Customer (ExaDB-C@C) resources.

To use Oracle Cloud Infrastructure, you must be granted security access by an administrator using IAM policies. This access is required whether you're using the Console or the REST API with an SDK, CLI, or other tool. If you get a message that you don't have permission or are unauthorized, verify with your administrator what type of access you have and which compartment you should work in. If you're new to policies, see Getting Started with Policies and Common Policies.

Policies to Manage an Exadata Fleet Update Collection of Oracle Databases or CloudVmClusters on Oracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D)

The following policies give permission to the example group CollectionAdmins to manage an Exadata Fleet Update collection of Oracle Databases or CloudVmClusters on Oracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D). The statements provide the minimum access needed to complete administrative tasks with Exadata Fleet Update collections. Access is limited to resources in the specified example compartments.

allow group CollectionAdmins to manage fleet-software-update-discoveries in compartment ABC
allow group CollectionAdmins to manage fleet-software-update-collections in compartment ABC
allow group CollectionAdmins to read fleet-software-update-work-requests in compartment ABC
allow group CollectionAdmins to inspect database-software-images in compartment ABC
allow group CollectionAdmins to inspect db-homes in compartment ABC
allow group CollectionAdmins to inspect databases in compartment ABC
allow group CollectionAdmins to inspect cloud-exadata-infrastructures in compartment ABC
allow group CollectionAdmins to inspect db-nodes in compartment ABC
allow group CollectionAdmins to use cloud-vmclusters in compartment ABC
allow group CollectionAdmins to use vcns in compartment ABC
allow group CollectionAdmins to use subnets in compartment ABC
allow group CollectionAdmins to use vnics in compartment ABC
allow group CollectionAdmins to use private-ips in compartment ABC
allow group CollectionAdmins to use network-security-groups in compartment ABC
Note

If you do not include <identity_domain_name> before <group_name>, then the policy statement is evaluated as though the group belongs to the default identity domain.

Policies to Manage an Exadata Fleet Update Collection of Oracle Databases or VmClusters on Oracle Exadata Database Service on Cloud@Customer (ExaDB-C@C)

The following policies give permission to the example group CollectionAdmins to manage an Exadata Fleet Update collection of Oracle Databases or VmClusters on Oracle Exadata Database Service on Cloud@Customer (ExaDB-C@C). The statements provide the minimum access needed to complete administrative tasks with Exadata Fleet Update collections. Access is limited to resources in the specified example compartments.

allow group CollectionAdmins to manage fleet-software-update-discoveries in compartment ABC
allow group CollectionAdmins to manage fleet-software-update-collections in compartment ABC
allow group CollectionAdmins to read fleet-software-update-work-requests in compartment ABC
allow group CollectionAdmins to inspect database-software-images in compartment ABC
allow group CollectionAdmins to inspect db-homes in compartment ABC
allow group CollectionAdmins to inspect databases in compartment ABC
allow group CollectionAdmins to inspect exadata-infrastructures in compartment ABC
allow group CollectionAdmins to inspect vmclusters in compartment ABC
allow group CollectionAdmins to inspect db-nodes in compartment ABC
Note

If you do not include <identity_domain_name> before <group_name>, then the policy statement is evaluated as though the group belongs to the default identity domain.

Required IAM Policies to Manage Maintenance Cycles

Review the IAM policies required to manage Exadata Fleet Update Maintenance Cycle and Action resources for Oracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D) or Oracle Exadata Database Service on Cloud@Customer (ExaDB-C@C) resources.

To use Oracle Cloud Infrastructure, you must be granted security access by an administrator using IAM policies. This access is required whether you're using the Console or the REST API with an SDK, CLI, or other tool. If you get a message that you don't have permission or are unauthorized, verify with your administrator what type of access you have and which compartment you should work in. If you're new to policies, see Getting Started with Policies and Common Policies.

In addition, for some operations, you are required to authorize Exadata Fleet Update resources as principal actors that can act on other resources.

Step 1: Create a Dynamic Group

Create a dynamic group (example name: fsu-action-dyn-group) using one of the following matching rules. For more information about dynamic groups, refer to Managing Dynamic Groups and Writing Matching Rules to Define Dynamic Groups. You need this dynamic group in order to authorize Exadata Fleet Update Actions to make API calls against other services, as needed. Exadata Fleet Update Actions typically need permission to use Oracle Cloud Infrastructure Database service resources.

This matching rule defines a dynamic group that includes all Exadata Fleet Update Actions as members.

resource.type='fsuaction'

Step 2: Create a Policy for the Dynamic Group

After creating the dynamic group, you create a policy for the dynamic group. This type of policy is referred to as a resource principal policy because it authorizes a resource as a principal actor that can act on other resources.

The following policy gives members of dynamic group fsu-action-dyn-group permission to create Database Homes and update Oracle Databases or CloudVmClusters on Oracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D). The statements provide the minimum access needed to complete administrative tasks with Exadata Fleet Update Maintenance Cycles and Actions. Access is limited to resources in the specified example compartments.

allow dynamic-group fsu-action-dyn-group to read db-nodes in compartment ABC
allow dynamic-group fsu-action-dyn-group to use database-software-images in compartment ABC
allow dynamic-group fsu-action-dyn-group to manage db-homes in compartment ABC where any {request.permission='DB_HOME_CREATE', request.permission='DB_HOME_UPDATE', request.permission='DB_HOME_INSPECT'}
allow dynamic-group fsu-action-dyn-group to manage databases in compartment ABC where any {request.permission='DATABASE_CREATE', request.permission='DATABASE_UPDATE', request.permission='DATABASE_INSPECT'}
allow dynamic-group fsu-action-dyn-group to use cloud-vmclusters in compartment ABC
allow dynamic-group fsu-action-dyn-group to use vcns in compartment ABC
allow dynamic-group fsu-action-dyn-group to use subnets in compartment ABC
allow dynamic-group fsu-action-dyn-group to use vnics in compartment ABC
allow dynamic-group fsu-action-dyn-group to use private-ips in compartment ABC
allow service fppcsprod to use cloud-vmclusters in compartment ABC

The following policy gives members of dynamic group fsu-action-dyn-group permission to create Database Homes and update Oracle Databases or VmClusters on Oracle Exadata Database Service on Cloud@Customer (ExaDB-C@C). The statements provide the minimum access needed to complete administrative tasks with Exadata Fleet Update Maintenance Cycles and Actions. Access is limited to resources in the specified example compartments.

allow dynamic-group fsu-action-dyn-group to read db-nodes in compartment ABC
allow dynamic-group fsu-action-dyn-group to inspect exadata-infrastructures in compartment ABC
allow dynamic-group fsu-action-dyn-group to use database-software-images in compartment ABC
allow dynamic-group fsu-action-dyn-group to manage db-homes in compartment ABC where any {request.permission='DB_HOME_CREATE', request.permission='DB_HOME_UPDATE', request.permission='DB_HOME_INSPECT'}
allow dynamic-group fsu-action-dyn-group to manage databases in compartment ABC where any {request.permission='DATABASE_CREATE', request.permission='DATABASE_UPDATE', request.permission='DATABASE_INSPECT'}
allow dynamic-group fsu-action-dyn-group to use vmclusters in compartment ABC
The following policy gives members of dynamic group fsu-action-dyn-group permission to delete Database Homes as part of a Cleanup action.
allow dynamic-group fsu-action-dyn-group to manage db-homes in compartment ABC where request.permission='DB_HOME_DELETE'
allow dynamic-group fsu-action-dyn-group to manage databases in compartment ABC where request.permission='DATABASE_DELETE'
Note

If you do not include <identity_domain_name> before <dynamic_group_name>, then the policy statement is evaluated as though the dynamic group belongs to the default identity domain.

Step 3: Add a Policy for Users

The following policies give permission to the example group CycleAdmins to manage Exadata Fleet Update Maintenance Cycle and Action resources.

allow group CycleAdmins to use fleet-software-update-collections in compartment ABC
allow group CycleAdmins to manage fleet-software-update-cycles in compartment ABC
allow group CycleAdmins to manage fleet-software-update-actions in compartment ABC
allow group CycleAdmins to manage fleet-software-update-jobs in compartment ABC
allow group CycleAdmins to manage fleet-software-update-work-requests in compartment ABC
allow group CycleAdmins to use database-software-images in compartment ABC
allow group CycleAdmins to manage db-homes in compartment ABC 
allow group CycleAdmins to use cloud-vmclusters in compartment ABC
allow group CycleAdmins to manage databases in compartment ABC where any {request.permission='DATABASE_CREATE', request.permission='DATABASE_UPDATE', request.permission='DATABASE_INSPECT'}
allow group CycleAdmins to use vmclusters in compartment ABC
allow group CycleAdmins to inspect exadata-infrastructures in compartment ABC
Note

If you do not include <identity_domain_name> before <dynamic_group_name>, then the policy statement is evaluated as though the dynamic group belongs to the default identity domain.