Use Oracle API Access Control with Oracle Exadata Database Service on Cloud@Customer and Oracle Exadata Database Service on Dedicated Infrastructure

Introduction

Oracle API Access Control enables customers to manage access to the REST APIs exposed by Oracle Exadata Database Service on Dedicated Infrastructure and Oracle Exadata Database Service on Cloud@Customer. By designating specific APIs as privileged, customers can ensure that invoking these APIs requires prior approval from an authorized group within their tenancy.

Oracle API Access Control also aids in audit integration by utilizing Oracle Cloud Infrastructure (OCI) technology to enforce a specific workflow.

A person requests access to perform a privileged operation, an approver reviews and approves the operation whereafter the OCI control plane transitions a special approval resource into an approved state. This allows the requester to send an API to a target resource and perform the desired task.

Key Benefits:

• Reduced Risk: Minimize accidental or malicious deletions of mission-critical database services.
• Separation of Duties: Ensure that API execution is distinct from approval, enhancing security and accountability.

Objectives

Configure and operate the Oracle API Access Control service for Oracle Exadata Database Service on Cloud@Customer. Similar instructions apply to Oracle Exadata Database Service on Dedicated Infrastructure.

• Set up users and groups in OCI tenancy.

• Configure Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) policy for Oracle API Access Control.

• Bring resources under control.

• Demonstrate API control enforcement.

• Create and approve an access request.

• Audit approved operations.

• Revoke Oracle API Access Control requests.

• Edit or remove controls.

• Complete final audit for control deletion.

Prerequisites

• Access to an OCI tenancy with an Oracle Exadata Database Service on Cloud@Customer or Oracle Exadata Database Service on Dedicated Infrastructure.

• User created in the tenancy, in a group with policies that grant Oracle API Access Control permissions (ExaCC Approver user in this tutorial).

• A second user created in the tenancy, in a group with policies that grant regular infra and DB management permissions (infra-db-admin-user user in this tutorial).

Task 1: Set up Users and Groups in OCI Tenancy

The first step in Oracle API Access Control involves setting up users and groups within your OCI tenancy. The second step is for these users and groups to configure the control and manage requests.

1. Log in to the OCI Console, navigate to Identity & Security within your default identity domain.

2. Create user and group. A user named ExaCC Approver has been configured, and this user is a member of the ExaCC-API-Approver-grp group.

   

Task 2: Configure OCI IAM Policy for Oracle API Access Control

In this task, configure OCI IAM policy to enable the Oracle API Access Control service to operate and for the ExaCC-API-Approver-grp group to manage the service. The policy statements provided in this example allow the service to function. OCI IAM policy syntax offers fine-grained control, allowing for further separation of duties.

Example OCI IAM policies for Oracle API Access Control:

allow group <admin_group/approver_group/managers> to manage privileged-api-family in tenancy
allow any-user TO use database-family IN tenancy where ALL { request.principal.type in ('pactlprivilegedapirequest', 'pactlprivilegedapicontrol') }
allow any-user TO use ons-topics IN tenancy where ALL { request.principal.type in ('pactlprivilegedapirequest', 'pactlprivilegedapicontrol') }
allow group <admin_group/approver_group/managers> to use database-family in tenancy
allow group <admin_group/approver_group/access_request_group> to read domains in tenancy
allow group <admin_group/approver_group/access_request_group> to inspect compartments in tenancy
allow group <admin_group/approver_group/access_request_group> to use ons-topics in tenancy

• The first policy line grants the ExaCC-API-Approver-grp group permission to manage the privileged-api-family. This means they can create controls, apply them to services, and approve access requests.

• The second policy line permits the Oracle API Access Control software to interact with the database service within your tenancy.

• The third policy line allows the Oracle API Access Control software to interact with OCI Notification topics in your tenancy. This is crucial for notifying your staff when access requests change their lifecycle states.

Your approver group needs the ability to use the database family but does not need to manage it. Additionally, the approval group must be able to read domains, inspect compartments, and use OCI Notification topics for notifications.

For more information about OCI IAM policies, see About Resource-Types and Delegate Access Control Policies.

Task 3: Bring Resources Under Control

With Oracle API Access Control and its policies in place, log in as an Oracle API Access Control user to bring resources under control.

1. Go to the OCI Console, navigate to Oracle Database, API Access Control and click Create privileged api control.

   

2. Select the compartment (ExaCC) and create a new control.

3. Enter a Name and Description for your control.

4. Select a resource type: Select Exadata Infrastructure for this tutorial.

   • Exadata Cloud Infrastructure for an Oracle Exadata Database Service on Dedicated Infrastructure in OCI or Oracle Multicloud.
   • Exadata Infrastructure for Oracle Exadata Database Service on Cloud@Customer.

   

5. Select Exadata Infrastructure compartment: The Exadata Infrastructure is located in a separate compartment (eccw-infrastructure).

6. Select Exadata Infrastructure: The infrastructure to be brought under control is eccw-infrastructure.

7. Select the APIs you wish to control for your infrastructure.

   For example:

   • You can protect deletions of the infrastructure.
   • For a Virtual Machine (VM) cluster, you can protect updates, deletions, adding/removing VMs, and changing compartments.
   • For VM cluster updates, various attributes can be selected as privileged, such as changing CPU core counts (which affects autoscaling software) or SSH public keys.
   • You can also control:
     • Database home APIs, such as deletes.
     • Virtual machine APIs, such as updates and creating console connections.
     • VM cluster network APIs, including resizes, updates, and deletes.
     • Container database APIs, which include deletes, Transparent Data Encryption key management key rotations, updates, and upgrades.
     • Pluggable database APIs, with actions like starting/stopping, refreshing, updating, and deleting pluggable databases. In this example, we want to apply controls on changing CPU core counts (7a) and deletion of CDB (7b).

   Note: The assigned controls can be modified after the initial control is created, but modifications also require the Oracle API Access Control approval process.

8. In Approval Information, select Use IAM policy for approval information. This is mandatory when operating in a tenancy with identity domains.

9. Optionally, you can require a second approval for particularly sensitive systems, requiring two separate identities to approve an access request.

10. Select a notification topic: You need to select an OCI Notification topic for access request notifications and click Create. After creating the control, it takes a few minutes to come online.

    The following images show the creation of an OCI Notification topic, creation and configuration of a subscription.

    

    

Note: OCI audit records are linked to the compartments where the resources reside. Therefore, when creating this Oracle API Access Control in the ExaCC compartment, audit records related to lifecycle management on API controls will be found there. Updates to the Exadata infrastructure, located in the eccw-infrastructure compartment, will have their audit records show up in the eccw-infrastructure compartment.

Task 4: Demonstrate API Control Enforcement

To demonstrate how the API controls the system, follow the steps:

1. Log in to the OCI Console as the infra-db-admin-user user.

2. Select Oracle Database Service on Cloud at Customer.

3. Select your virtual machine cluster and Exadata infrastructure.

4. You will see the eccw-cl3 VM cluster, with Oracle API Access Control enabled.

5. If you attempt to change the ECPU count per VM directly from the menu, the operation will be denied as it is not allowed for the current resource.

   

6. Similarly, if you try to terminate a database, the operation will not be allowed.

7. To verify audit record from the OCI Console.

   1. Navigate to Observability and Management.

   2. Select Logging and click Audit.

   3. Select the ExaCC compartment.

   4. Audit for actions like PUT and POST or state changes.

   In the eccw-infrastructure compartment, you will see a Not Found (404) error indicating that the Oracle API Access Control check for approval has failed the request.

   

Task 5: Create and Approve an Access Request

1. Go to the OCI Console, navigate to Oracle Database and click API Access Control.

2. Click Create Privileged Access Request where you can create a request to update the CPU core count.

   1. Compartment: Select ExaCC compartment.

   2. Ticket numbers: Add a reference to a ticket (this is free-form text).

   3. Resource type: The resource type is your VM cluster.

   4. Select privileged operations: Request to update VM cluster cpuCoreCount. You can add more operations if needed for a single access window.

      

   5. You can request access for a future date for planned maintenance or immediately.

   6. Select a notification topic: Select a topic to be notified and click Create.

      

   In the compartment where the access request is created, you will see it in a Raised state.

   

   If you attempt to approve it yourself, you will receive an error indicating that a different user must approve it.

3. Access the system as your ExaCC Approver approver user. You can see the access requests in the compartment.

   

   An email notification will be send to the members of the ExaCC-API-Approver-grp.

   

4. You can access the raised request.

   

5. Review the request is for UpdateVmCluster cpuCoreCount and approve the request immediately or select a future time.

   

   

6. Once the access request is approved, return to the VM cluster resource and update ECPU count per VM. The system will now allow the ECPU count per VM change.

Task 6: Audit Approved Operations

From an audit perspective.

1. Go to the OCI Console, navigate to Observability and Management and select Audit.

2. Navigate to the compartment where the Oracle API Access Control access request is configured. See POSTs and PUTs.

3. You will see that the infra-db-admin-user user created an Oracle API Access Control access request.

   

4. You will see the Bad Requests (400) when you attempted to approve it yourself.

   

   

5. You will see that the ExaCC Approver approved the access request.

   

Similarly, when looking at the eccw-infrastructure compartment, you will observe the update to the VM cluster that occurred after approval. You can see the update VM cluster begin and the API access control check have approved, indicating that the APIs will be sent forward.

Task 7: Revoke Oracle API Access Control Requests

An Oracle API Access Control request can be revoked by either the person who submitted it or the approver. Once a request is revoked, any attempt to perform the action will be disallowed.

From an audit perspective in the eccw-infrastructure compartment, you can observe the PUT and POST methods. You will see VM cluster updates that were allowed after approval, as well as failures for VM cluster updates that occurred because the access request was not approved. When reviewing the lifecycle management of the access requests themselves, you can see when the request was opened, the 400 Error for self-approval, and the successful approval by a different user.

Task 8: Edit or Remove Controls

• If you attempt to remove a control, the software will automatically create an Oracle API Access Control request on your behalf to remove it.

  

• If you try to approve your own action to remove the control, the same enforcement rules apply (it will be denied).

  

• If a different user (for example, another test user with rights to approve access requests) approves the access request, they can then delete or remove the resource.

Task 9: Complete Final Audit for Control Deletion

From an audit perspective for control deletion.

• You can see the infra-db-admin-user attempt to delete the privileged API control and receive a 400 Error.

• Then, you can see a different user ExaCC Approver approving the privileged API access request, resulting in a 200 (successful) status.

• Finally, infra-db-admin-user issues the delete command, and you will see the delete succeed with a OK (202) status.

Related Links

• Oracle Exadata Database Service on Cloud@Customer

• Oracle API Access Control

• API Access Control Demonstration Video

Acknowledgments

• Author - Filip Vercauteren (Exadata Cloud@Customer Black Belt)

• Contributors - Matthieu Bordonne (Master Principal Sales Consultant - EMEA Solution Center), Zsolt Szokol (Exadata Cloud@Customer Black Belt), Jeffrey Wright (Distinguished Product Manager)

More Learning Resources

Explore other labs on docs.oracle.com/learn or access more free learning content on the Oracle Learning YouTube channel. Additionally, visit education.oracle.com/learning-explorer to become an Oracle Learning Explorer.

For product documentation, visit Oracle Help Center.

---

Title and Copyright Information

Use Oracle API Access Control with Oracle Exadata Database Service on Cloud@Customer and Oracle Exadata Database Service on Dedicated Infrastructure

G39091-01

Copyright ©2025, Oracle and/or its affiliates.