5 How-to Guides

A collection of tasks and procedures for managing Oracle Exadata Database Service on Exascale Infrastructure.

Azure Key Vault Integration for Exadata Database Service on Exascale Infrastructure@Azure

Exadata Database Service on Exascale Infrastructure@Azure enables you to store your database's transparent data encryption (TDE) keys, also known as master encryption keys (MEKs) in either a file-based Oracle wallet or in the OCI Vault.

This feature enables Exadata Database Service on Exascale Infrastructure@Azure users to utilize Azure Key Vault (AKV) Managed HSM, AKV Premium and AKV Standard for managing TDE MEKs. This integration allows applications, Azure services, and databases to use a centralized key management solution for enhanced security and simplified key lifecycle management.

Parent topic: How-to Guides

Prerequisites

You must complete these steps before you can configure Azure Key Vault as the key management for your databases.

The following steps must be completed before you can configure Azure Key Vault as Key Management Service at the Exadata VM Cluster level:

  1. If you plan to use a private network, then you must first complete the registration required for delegated subnets to use advanced network features mentioned in Network planning for Oracle Database@Azure, and then create an Azure Virtual Network with at least one delegated subnet in it to be used by Exadata VM cluster.
  2. Provision an Exadata VM Cluster via the Azure interface. See Provisioning an Exadata VM Cluster for Azure for step-by-step instructions.
  3. Review the networking requirements to determine whether the VM Cluster will connect to Azure KMS through a public network or through private connectivity. For more information, see Connected Machine agent network requirements or Network Requirements for Creating an Identity Connector and KMS Resources for specific steps to follow.
  4. Ensure that the following policy is created before creating the database.
    allow any-user to manage oracle-db-azure-vaults IN tenancy where ALL { request.principal.type in ('exadbvmcluster') }

Parent topic: Azure Key Vault Integration for Exadata Database Service on Exascale Infrastructure@Azure

Network Requirements for Creating an Identity Connector and KMS Resources

Azure Key Management Service (KMS) resources support both public and private connectivity.

The following sections outline the network requirements for public network access:

Configuration Using Private Network

  • Arc agent network configuration

    Make sure the endpoints listed below are accessible from the VM cluster nodes:

    • guestconfiguration.azure.com
    • his.arc.azure.com
    • login.microsoftonline.com
    • management.azure.com
    • pas.windows.net
    • guestconfiguration.azure.com
    • packages.microsoft.com
    • aka.ms

    To create an Identity Connector over a private network, an Azure Arc Private Link Scope and a Private Endpoint must be configured through the Azure portal. Refer to the Azure documentation for detailed steps on setting up private connectivity for Azure Arc-enabled servers.

    Important:
    • The Private Endpoint must be created in a non-delegated subnet within the Azure Virtual Network (VNet) that hosts the Oracle Exadata VM Cluster. Private Endpoints are not supported in delegated subnets. By default, Exadata VM Clusters are provisioned in delegated subnets.
    • Managed HSM requires private connectivity and is supported only in Azure regions that offer Advanced Networking features. For a list of supported regions, see Network planning for Oracle Database@Azure.

    To allow communication with private agent resources over the private network, a private DNS zone and corresponding A records must be created within the VCN's DNS configuration in your Oracle Cloud Infrastructure (OCI) tenancy.

    The DNS configuration for the Private Endpoint associated with the Private Link Scope must include the necessary private agent resource addresses. For more information, see URLs section in Connected Machine agent network requirements.

    First, retrieve the list of required addresses from the Azure portal. Then, update the DNS zone entry in OCI to complete the configuration.

    Steps to retrieve the list of required IP addresses:
    1. Sign in to the Azure portal.
    2. Search for "Azure Arc Private link scopes".
    3. Choose any private link scope from the list.
    4. Under the Configure menu, click Private endpoint connections.
    5. Click the Private endpoint link.
    6. Under Settings, select DNS configuration to view the required addresses.

    Example: Add a Private Agent Resource (for example, gbl.his.arc.azure.com)

    The IP address associated with gbl.his.arc.azure.com, along with any other required agent resources, must be defined in the private DNS zone.

    Steps:

    1. Create a Private Zone
      For more information, see Creating a Private DNS Zone.
      • Zone type: Primary
      • Zone name: <Descriptive name>
      • Compartment: <Compartment name or OCID>
    2. Add DNS Records
      • Navigate to the Records tab on the zone details page.
      • Click Manage Records, then Add Record:
        • Name: gbl.his.arc.azure.com
        • Type: A (IPv4 address)
        • TTL (seconds): 3600
        • RDATA mode: Basic
        • Address: <Private IP address>
    3. Publish the Zone.
    4. Ensure the record appears on the zone's page after publishing.
    5. Verify that connectivity to Azure services from the VM cluster is routed through the private network.

    Even with Private Connectivity, the following endpoints must be routed through the Azure NAT gateway.

    Agent resources:

    • packages.microsoft.com
    • login.microsoftonline.com
    • pas.windows.net
    • management.azure.com
    • aka.ms
  • Azure Key Vault private endpoints configuration

    To access endpoints of Azure Key Vaults over private connectivity, you must create a DNS zone. Additionally, an A record mapping the fully qualified domain name (FQDN) of the resource to the IP address of the corresponding private endpoint must be added in the OCI tenancy.

    To access the Managed HSM service over a Private Endpoint in your virtual network hosting an Exadata VM Cluster, you can establish a private link connection to Managed HSM and associate it with either the default subnet or a non-delegated subnet. Follow the steps outlined in the "Configuration Using Private Network" section of the "Network Requirements for Creating an Identity Connector and KMS Resources" topic. For more information, see Integrate Managed HSM with Azure Private Link.

Configuration Using Public Network

Create a NAT gateway in Azure portal and associate it with the delegated subnet of the Exadata VM Cluster. For more information, see Create a NAT gateway and associate it with an existing subnet.

Alternatively, you can also use Azure network firewall to restrict traffic. For more information, see Deploy and configure Azure Firewall using the Azure portal.

Parent topic: Azure Key Vault Integration for Exadata Database Service on Exascale Infrastructure@Azure

Using the Console to Manage Azure Key Vault Integration for Exadata Database Service on Exascale Infrastructure@Azure

Learn how to manage Azure Key Vault integration for Exadata Database Service on Exascale Infrastructure@Azure.

Parent topic: Azure Key Vault Integration for Exadata Database Service on Exascale Infrastructure@Azure

Creating an Identity Connector installs the Azure Arc agent on the Exadata VM Cluster VMs, registering them as Azure Arc-enabled virtual machines.

This enables secure communication with the Azure Key Management Service (KMS) using the Azure identity generated by the Arc agent. The Azure Arc agent can communicate with Azure services over either a public network or a private connectivity setup. Learn more about Azure Arc.

Each VM cluster must have an identity connector enabled to access Azure resources. The identity connector establishes either a public or private connection between the VM cluster and Azure Key Management resources, depending on the roles assigned. You need roles to access the Azure KMS resources.

To generate an access token for your current Azure account, see az account get-access-token.

You can create an identity connector in one of two ways—using the Oracle Exadata Database Service on Exascale Infrastructure interface or the Database Multicloud Integrations interface.

Oracle Exadata Database Service on Exascale Infrastructure

  1. Open the navigation menu. Click Oracle AI Database, then click Oracle Exadata Database Service on Exascale Infrastructure.

    The VM clusters page is selected by default.

  2. From the list of VM Clusters, select the cluster you are using.
  3. In the VM Cluster information tab, navigate to Identity connector located under Multicloud information. Click the Create button.

    Note:

    If an identity connector has not been created previously, it is displayed as None.

  4. The Identity connector name, ExaDB-XS VM cluster, Azure subscription id, and Azure resource group name are read-only fields and will be populated with values.
  5. Enter your Azure tenant id, and Access token.
  6. Expand the Show advanced options section.

    The Private connectivity information and Tags sections populate.

    To enable a private endpoint connection, enter the Azure arc private link scope name if it is in the same subscription of Arc agent. Enter the Full Azure Resource ID if the Azure arc private link scope is in a different subscription.

    Enter the full Azure Resource ID in the following format:
    /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.HybridCompute/privateLinkScopes/<azure-arc-private-link-scope>
  7. To add tags for your resources, click Add tag, and then enter required values.
  8. Review your selections, and then click Create to create the identity connector.

Database Multicloud Integrations

  1. Open the navigation menu. Click Oracle AI Database, click Database Multicloud Integrations, and then click Microsoft Azure Integration.
  2. Select Identity Connectors from the left navigation menu.
  3. From the Compartment drop-down list, select your compartment that you are using.
  4. Click Create Identity Connector.
  5. In the Identity connector information section, provide the following information:
    1. Identity mechanism: (read-only) Name of identity mechanism
    2. Resource Type: Select ExaDB-XS VM cluster from the drop-down options
    3. ExaDB-XS VM cluster compartment: Select the compartment from the drop-down options
    4. ExaDB-XS VM cluster: Select the VM Cluster from the drop-down options
    5. Identity connector name: Once you select your ExaDB-XS VM cluster, the Identity connector name automatically populates a name.
  6. In the Azure information section, provide the following information:
    1. Enter your Azure tenant id.
    2. The Azure subscription id and Azure resource group name fields populate values based on your ExaDB-XS VM Cluster selection.
    3. Enter an Access token.
  7. Expand the Show advanced options section. The Private connectivity information and Tags sections populate. These fields are optional.

    To enable a private endpoint connection, enter the Azure arc private link scope name if it is in the same subscription of Arc agent. Enter the Full Azure Resource ID if the Azure arc private link scope is in a different subscription.

    Enter the full Azure Resource ID in the following format:
    /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.HybridCompute/privateLinkScopes/<azure-arc-private-link-scope>
  8. To add tags for your resources, click Add tag, and then enter required values.
  9. Review your selections, and then click Create.
    The newly created identity connector will be displayed in the Identity Connectors page.

    Note:

    The Identity Connectors page displays the list of identity connectors based on the resource type and can be filtered using the Search and Filter functionality.

To view the details of an identity connector, use this procedure.

  1. Open the navigation menu. Click Oracle AI Database, then click Oracle Exadata Database Service on Exascale Infrastructure.

    The VM clusters page is selected by default.

  2. Click the name of the VM cluster of your choice.
  3. On the resulting VM Cluster Details page, in the Multicloud Information section, confirm that the Identity connector field displays the identity connector created previously.
  4. Click the name of the Identity Connector to view its details. You can also view the associated ExaDB-XS VM Cluster.

This step installs the required library on the VM cluster to support Azure Key Vault integration. Ensure that an identity connector is created before enabling Azure Key Management on the Exadata VM Cluster.

  1. Open the navigation menu. Click Oracle AI Database, then click Oracle Exadata Database Service on Exascale Infrastructure.

    The VM clusters page is selected by default.

  2. Click the name of the VM cluster of your choice.
  3. On the resulting VM Cluster Details page, in the Multicloud Information section, click the Enable link next to Azure key store.
  4. On the resulting Enable Azure key management dialog, click Enable to confirm the operation.

    Confirming the action will install a library on your VM Cluster.

    The status of Azure key store changes from Disabled to Enabled.

  5. To disable Azure key store, click the Disable link.
  6. On the resulting Disable Azure key management dialog, click Disable to confirm the operation.

    Disabling the Azure key management removes the library installed during enablement, which will impact the availability of databases configured to use it.

Note:

Azure key management is configured at the VM cluster level, requiring all databases in the cluster to use the same key management solution. However, databases that use Oracle Wallet can coexist alongside those that use Azure Key Vault within the same cluster.

Create Azure Key Vault Managed HSM, Azure Key Vault Premium, or Azure Key Vault Standard, then assign the permission.

For more information, see Create a key vault using the Azure portal.

Note:

There are specific roles that must be assigned to the group to grant the necessary permissions for accessing and managing Azure Key Vault Managed HSM, Azure Key Vault Premium, and Azure Key Vault Standard resources.
  1. Create a group and add members.

    Azure groups allow you to manage users by assigning them the same access and permissions to resources.

    • To manage group in Azure, you are required to have User Administrator or Groups Administrator role. For more information, see Manage Microsoft Entra groups and group membership.
    • You must create a security group and add members from the Microsoft Azure portal. You must select the Security option as your Group type. For more information, see Create a basic group and add members.
    • You can add Arc-enabled VMs to the group. The roles mentioned in the subsequent step can be assigned to a group containing multiple VMs, instead of assigning roles to individual VMs.
  2. Assign the following roles based on the type of Azure Key Vault:
    • For Managed HSM:
      • IAM: Reader
      • Local RBAC: Managed HSM crypto officer + Managed HSM crypto user
    • For Key Vault Premium and Standard:
      • IAM: Reader + Key Vault Crypto Officer

For detailed steps, refer to Assign Azure roles using the Azure portal.

This is an alternative way to register your Azure key vaults from the OCI console. If you have already registered your vault during the creation of a database in your existing VM Cluster, you can skip this step.

  1. From the OCI console, navigate to Database Multicloud Integrations, and then select Microsoft Azure Integration. From the Microsoft Azure Integration section, select Azure Key Vaults.

    Note:

    At least one key must be created in the vault on the Azure portal for the registration to succeed.
  2. Select the Register Azure key vaults button.
  3. From the drop-down list, select your Compartment.
  4. To discover Azure Key Vault or Managed HSM within the same subscription in an Azure tenancy (Identity Connector and Azure Key Vault or Managed HSM in the same subscription) and register keys:
    1. From the Azure key vaults section, select an identity connector from the Discover Azure key vaults using connector list.
    2. Click Discover.

      The list of Vault names is displayed.

    3. Select the check box located next to Vault name.
  5. To discover a single Azure Key Vault or Managed HSM within the same subscription in an Azure tenancy, you can provide either the short key vault name or the full resource ID. Provide the full resource ID in one of the following formats:

    For Azure Key Vault:

    /subscriptions/<subscription-id>/resourceGroups/<resource-groups>/providers/Microsoft.KeyVault/vaults/<key-vault-name>

    For Azure Managed HSM:

    /subscriptions/<subscription-id>/resourceGroups/<resource-groups>/providers/Microsoft.KeyVault/managedHSMs/<hsm-name>

    Note:

    Cross subscription only supports the full resource ID.
  6. To discover Azure Key Vault or Managed HSM across subscriptions in an Azure tenancy (Identity Connector and Azure Key Vault or Managed HSM in different subscriptions) and register keys:
    1. From the Azure key vaults section, select an identity connector from the Discover Azure key vaults using connector list.
    2. Provide the full resource ID of the Azure Key Vault in the following format.
      /subscriptions/<subscription-id>/resourceGroups/<resource-groups>/providers/Microsoft.KeyVault/vaults/<key-vault-name>
    3. Click Discover.
  7. If you want to add tags for your resources, expand the Advanced options section, and then click Add tag.
  8. Click Register to register the vaults locally in the OCI.
  9. Once you register the vault, you can view the Display name, State, Type, Azure resource group, and Created information of the vaults in the list.
  10. Select the vault you are using, and then click the Identity connector associations tab, which lists identity connector associations in the current compartment.

    Note:

    A default association is automatically created between the vault and the Identity Connector used during the vault registration process. This allows the vault to be used on the VM cluster associated with that specific Identity Connector.

    If you want to use the same vault in other clusters that are registered with different Identity Connectors (that is, not the one used during vault discovery), you must explicitly create an association between the vault and those additional Identity Connectors.

  11. If you expand the Advanced options section, you can add Tags for organizing your resources.
  12. Review your selections, and then click Create.
Create a Database and Use Azure Key Vault as the Key Management Solution

This topic describes only the steps for creating a database and using Azure Key Vault as the key management solution.

For the generic database creation procedure, see To Create a Database in an Existing Oracle Exadata Database Service on Exascale Infrastructure VM Cluster.

Prerequisites

Before creating your first database and selecting Azure Key Vault for key management, ensure the following prerequisites are met:

Limitations

  • Virtual Machines Restriction: Scaling out a VM cluster does not automatically extend databases that use Azure Key Vault to the newly added virtual machine. To complete the extension, you must update the existing Identity Connector for the VM Cluster by supplying the Azure access token. After updating the Identity Connector, run the dbaascli database addInstance command to add the database instance to the new VM.
  • Data Guard Restrictions:
    • When creating a standby database for a primary that uses Azure Key Vault, ensure that the target VM cluster has an active Identity Connector, Azure key management is enabled, and the required association between the Identity Connector and the Key Vault is properly configured.
    • Cross-region Data Guard and database restore operations are not supported for databases that use Azure Key Vault for key management.
  • PDB Operations Restriction: Remote PDB operations—such as clone, refresh, and relocate—are supported only if both the source and destination databases use the same Transparent Data Encryption (TDE) key.

Steps

Note:

If Azure key management is enabled at the VM cluster level, you will have two key management options: Oracle Wallet and Azure Key Vault.

  1. In the Encryption section, choose Azure Key Vault.
  2. Select a registered Vault available in your compartment.

    Note:

    • The Vault list populates only registered vaults.

      Click the Register new vaults link to register your vault. From the Register Azure key vaults page, select your vault, and then click Register.

    • At least one key must be registered in your vaults.
  3. Select the Key available in your compartment.

Learn to change encryption keys between different encryption methods.

  1. Navigate to your existing VM Cluster in the OCI console. Select the Container Databases tab. Then, select the database resource that you are using.
  2. Select the Database information tab, and then scroll down to Key management section.
  3. In the Encryption section, verify that Key management is set to Oracle Wallet, and then select the Change link.
  4. Enter the following information on the Change key management page:
    1. Select your Key management as Azure key vault from the drop-down list.
    2. Select your Vault compartment that you are using, and then select your Vault that is available in the compartment.
    3. Select the Key compartment that you are using, and then select your Key from the drop-down list.
    4. Click Save changes.

Note:

Changing key management from Azure Key Vault to Oracle Wallet cannot be performed using the API or OCI Console—it is only supported through the dbaascli tde fileToHsm command. Additionally, switching between Azure Key Vault and OCI Vault or Oracle Key Vault (OKV) are not supported.

To rotate the Azure key vault encryption key of a container database (CDB), use this procedure.

  1. Open the navigation menu. Click Oracle AI Database, then click Oracle Exadata Database Service on Exascale Infrastructure.
  2. Choose your Compartment.

    A list of VM Clusters is displayed for the chosen Compartment.

  3. In the list of VM Clusters, click the name of the VM cluster that contains the database that you want to rotate encryption keys.
  4. Click Container Databases.
  5. Click the name of the database that you want to rotate encryption keys.

    The Database Details page displays information about the selected database.

  6. In the Encryption section, verify that the Key Management is set to Azure Key Vault, and then click the Rotate link.
  7. On the resulting Rotate Key dialog, click Rotate to confirm the action.

Note:

Key rotation must be performed through the OCI interface. Rotating the key directly from the Azure interface has no effect on the database.

To rotate the Azure key vault encryption key of a pluggable database (PDB), use this procedure.

  1. Open the navigation menu. Click Oracle AI Database, then click Oracle Exadata Database Service on Exascale Infrastructure.
  2. Choose your Compartment.

    A list of VM Clusters is displayed for the chosen Compartment.

  3. In the list of VM clusters, click the name of the VM cluster that contains the PDB you want to start, and then click its name to display the details page.
  4. Under Container Databases, find the database containing the PDB you want to rotate encryption keys.
  5. Click the name of the database to view the Database Details page.
  6. Click Pluggable Databases in the Resources section of the page.

    A list of existing PDBs in this database is displayed.

  7. Click the name of the PDB that you want to rotate encryption keys.

    The pluggable details page is displayed.

  8. In the Encryption section displays that the Key management is set as Azure Key Vault.
  9. Click the Rotate link.
  10. On the resulting Rotate Key dialog, click Rotate to confirm the action.

For information about using the API and signing requests, see REST APIs and Security Credentials. For information about SDKs, see Software Development Kits and Command Line Interface.

Use these API operations to manage Azure Key Vault integration for Exadata Database Service on Exascale Infrastructure@Azure.

Table 5-1 API operation to manage Azure Key Vault integration for Exadata Database Service on Exascale Infrastructure@Azure

API Description
createOracleDbAzureConnector Captures Azure-specific details from the customer and automates the installation of the Arc Agent on the VM Cluster.
deleteOracleDbAzureConnector Deletes the Azure Connector resource and uninstalls the Arc Agent from the VM Cluster.
getOracleDbAzureConnector Fetches the details of a specific Azure Connector resource.
listOracleDbAzureConnectors Lists Azure Connector resources based on the specified filters.
CreateMultiCloudResourceDiscovery Creates a new multi-cloud resource discovery resource.
GetMultiCloudResourceDiscovery Retrieves details of a specific multi-cloud resource discovery resource.
ListMultiCloudResourceDiscoveries Retrieves a list of all multi-cloud resource discovery resources.
CreateOracleDbAzureVaultAssociation Creates a new association between an Oracle DB and an Azure vault.
GetOracleDbAzureVaultAssociation Retrieves details of a specific Oracle DB Azure vault association.
ListOracleDbAzureVaultAssociations Retrieves a list of all Oracle DB Azure vault associations.
createExadbVMCluster Creates a VM cluster.
getExadbVmCluster Gets information about the specified VM cluster.
listExadbVmClusters Gets a list of the VM clusters in the specified compartment.
deleteExadbVMCluster Deletes the specified VM cluster.
CreateDatabase Creates a new database in the specified Database Home. If the database version is provided, it must match the version of the Database Home.
CreateDatabaseFromBackup

Details for creating a database by restoring from a database backup.

Warning: Oracle recommends that you avoid using any confidential information when you supply string values using the API.

MigrateVaultKey Changes encryption key management from customer-managed, using the Vault service, to Oracle-managed.
RotateVaultKey Creates a new version of an existing Vault service key.
RestoreDatabase Restores a Database based on the request parameters you provide.

Parent topic: Azure Key Vault Integration for Exadata Database Service on Exascale Infrastructure@Azure

Updating the Multicloud PKCS#11 Driver

Note:

The PKCS#11 driver for Azure is installed automatically when Azure key management is enabled on a VM cluster. To verify that the driver is installed and check its version, run the following command:

rpm -qa | grep pkcs

This command lists the PKCS package installed on the VM cluster. Only one PKCS#11 driver can be active at a time, corresponding to either Azure, Google Cloud, or AWS.

Example output:

pkcs-multicloud-driver-maz-0.2-250814.1708.x86_64

This confirms that the pkcs-multicloud-driver-maz package is installed, along with its version and architecture.

The PKCS#11 driver can be updated using either a rolling or non-rolling mechanism, depending on customer preference.

In rolling mode, the update is applied to one VM at a time, and the databases on that VM are restarted before proceeding to the next. In non-rolling mode, all databases in the cluster are shut down, the update is applied across all nodes, and the databases are then brought back online. Users must be aware of the dbaastools version in use, as subsequent steps, specifically step 3 in both scenarios, require different actions depending on the version, particularly when updating the PKCS#11 driver.

The version of dbaastools can be determined by running the following command: 

/var/opt/oracle/dbaascli/dbaascli admin showLatestStackVersion

Rolling update

On each Guest VM, apply the PKCS#11 driver update as follows (one node at a time):

  1. Shutdown the database instances that are using the Azure KMS.

    All databases that use the Azure KMS for master encryption keys (MEK) must be stopped before updating the driver. Use:

    srvctl stop instance -d <db_unique_name> -i <instance_name> [-o <stop_option>]
    • -d <db_unique_name>: The unique name of the database (same as DB_UNIQUE_NAME in the database).
    • -i <instance_name>: The name of the instance to stop, for example, orcl1.

    For details on additional options, refer to the SRVCTL command-line help or reference manual.

  2. Verify that the databases have been shut down.

    Ensure that all database instances that are using the Azure KMS have been stopped before proceeding.

  3. Update the RPM.

    As the root user, run the following command (for dbaastools 25.4.1 and later): 

    /var/opt/oracle/dbaascli/dbaascli admin updateMCKMS --keystoreProvider AZURE --nodeList <node> --databasesStopped

    This command downloads and installs the latest RPM on the specified node.

  4. Verify driver installation.

    Run the following command as the root user: 

    /bin/rpm -qa | grep -i pkcs-multicloud-driver
  5. Start the database instances.

    After the driver update, restart the database instances using:

    <oracle_home>/bin/srvctl start instance -node "<node>"

Non-Rolling update

In non-rolling mode, all databases on the cluster are stopped before applying the PKCS#11 driver update.

  1. Stop databases using the Azure KMS.

    Stop all databases that use the Azure KMS for master encryption keys (MEK) before updating the driver:

    dbaascli database stop [--dbname <value>]
  2. Verify that the databases have been shut down.

    Ensure that all databases using the Azure KMS have been stopped before proceeding.

  3. Upgrade the RPM.

    As the root user, run the following command (for dbaastools 25.4.1 and later): 

    /var/opt/oracle/dbaascli/dbaascli admin updateMCKMS --keystoreProvider AZURE --databasesStopped

    This command downloads and installs the latest RPM.

  4. Verify driver installation.

    Run the following command as the root user: 

    /bin/rpm -qa | grep -i pkcs-multicloud-driver
  5. Restart the databases.

    Once the driver has been updated, restart the databases:

    dbaascli database start [--dbname <value>]

Parent topic: Azure Key Vault Integration for Exadata Database Service on Exascale Infrastructure@Azure

Google Cloud Key Management Integration for Exadata Database Service on Exascale Infrastructure@Google Cloud

Exadata Database Service on Exascale Infrastructure@Google Cloud now supports integration with Google Cloud Platform's Key Management Service (KMS).

This enhancement allows users to manage Transparent Data Encryption (TDE) master encryption keys (MEKs) using GCP Customer-Managed Encryption Keys (CMEKs).

Previously, Transparent Data Encryption (TDE) master encryption keys (MEKs) could only be stored in a file-based Oracle Wallet, Oracle Cloud Infrastructure (OCI) Vault, or Oracle Key Vault (OKV). With this update, users can now store and manage MEKs directly in GCP KMS, providing improved key lifecycle control and alignment with organization-specific security policies.

This integration enables applications, Google Cloud services, and databases to benefit from a centralized key management solution that offers enhanced security and simplified key lifecycle management.

Parent topic: How-to Guides

Prerequisites

Before configuring GCP Customer Managed Encryption Keys (CMEK) as the key management service for your databases, ensure the following prerequisites are met.

  1. Provision a VM Cluster using the Google Cloud console. See Provisioning a VM Cluster for Google Cloud for step-by-step instructions.
  2. Review the Identity Connector connection to ensure it is correctly configured and active. For more information, see Verify the Default Identity Connector Attached to the VM Cluster.
  3. Prerequisites for Configuring GCP Customer Managed Encryption Keys (CMEK) at the VM Cluster Level.

    To enable Google Cloud Platform (GCP) Customer Managed Encryption Keys (CMEK) for databases deployed with Exadata Database Service on Exascale Infrastructure@Google Cloud, you must configure CMEK as the key management option at the VM cluster level. Once CMEK is enabled, all database encryption and decryption operations will use the specified GCP-managed key.

    Before enabling CMEK, ensure that:
    • The required GCP key rings and encryption keys are already created in GCP.
    • These keys are mirrored as anchor resources in Oracle Cloud Infrastructure (OCI), ensuring synchronization between GCP and OCI.
    • The anchor resources are in place for database provisioning and for managing the encryption key lifecycle, including key rotation, revocation, and auditing.
  4. IAM Policy Requirements for Accessing GCP Key Resources.

    The database uses the cluster resource principal to securely retrieve GCP key resources. To enable this functionality, you must define the appropriate IAM policies in your OCI tenancy.

    Read-Only Access to Oracle GCP Keys:
    Allow any-user to read oracle-db-gcp-keys in compartment id <your-compartment-OCID> 
where all { request.principal.type = 'exadbvmcluster',}

    This policy grants read-only access to GCP key resources for the VM cluster resource principal.

  5. Required Google Cloud Services Connectivity GCP CMEK Integration.

    Google Cloud VPCs typically include default routes to the services listed below. Ensure that no firewall egress rules block access to these endpoints.

    • https://iamcredentials.googleapis.com/
    • https://sts.googleapis.com/
    • https://cloudkms.googleapis.com/

Parent topic: Google Cloud Key Management Integration for Exadata Database Service on Exascale Infrastructure@Google Cloud

Using the Console to Manage GCP KMS Integration for Exadata Database Service on Exascale Infrastructure@Google Cloud

Learn how to manage GCP KMS integration for Exadata Database Service on Exascale Infrastructure@Google Cloud.

Parent topic: Google Cloud Key Management Integration for Exadata Database Service on Exascale Infrastructure@Google Cloud

To view the details of an identity connector attached to a VM cluster, use this procedure.

  1. Open the navigation menu. Click Oracle AI Database, then click Oracle Exadata Database Service on Exascale Infrastructure.

    The VM clusters page is selected by default.

  2. From the list of VM Clusters, select the cluster of your choice.
  3. On the resulting VM Cluster Details page, in the Multicloud Information section, confirm that the Identity connector field displays the identity connector attached to this VM cluster.
  4. Click the name of the Identity Connector to view its details.

    You will be redirected to the Database Multicloud Integrations portal.

To create a key ring, use this procedure.

  1. Open the Google Cloud Console, navigate to the Key Management page.
  2. Click Create key ring.
  3. Provide the following details:
    • Name: Enter a descriptive name for the key ring.
    • Location: Select a location for your key ring.
      Important:
      • Key rings with the same name can exist in different locations, so you must always specify the location.
      • Choose a location close to the resources you want to protect.
      • For Customer Managed Encryption Keys, ensure the key ring is in the same location as the resources that will use it.

      Choosing a location for your Key Ring:

      When creating a key ring in Google Cloud Key Management Service (KMS), selecting the right location is crucial. Your choice affects where your cryptographic keys are stored and how they're replicated. For more information, see Cloud KMS locations.

      • Region:
        • Data is stored in a specific geographic region.
        • Keys remain within the boundaries of this single region.
        • Ideal for:
          • Low-latency applications
          • Compliance with data residency requirements
          • Region-specific workloads
      • Multi-region:
        • Data is replicated across multiple regions within a larger geographical area.
        • Google manages distribution and replication automatically.
        • You cannot select individual data centers or regions.
        • Ideal for:
          • High availability
          • Resilient, fault-tolerant applications
          • Services serving a wide regional area
      • Global:
        • A special type of multi-region.
        • Keys are distributed across Google data centers worldwide.
        • Location selection and control are not available.
        • Ideal for:
          • Applications with global users
          • Use cases needing maximum redundancy and reach
  4. Click Create.

Once the key ring is created, you can begin creating and managing encryption keys within it.

To create a raw symmetric encryption key in the specified key ring and location, use this procedure.

  1. Open the Google Cloud Console, navigate to the Key Management page.
  2. Click the name of the key ring where you want to create the key.
  3. Click Create key.
  4. Provide the following details:
    • Key name: Enter a descriptive name for your key.
    • Protection level: Choose Software or HSM (Hardware Security Module).

      The protection level of a key can't be changed after the key is created. For more information, see Protection levels.

    • Key material: Select Generate key or Import key.

      Generate key material in Cloud KMS or import key material that is maintained outside of Google Cloud. For more information, see Customer-managed encryption keys (CMEK).

    • Purpose and Algorithm:

      For more information, see Key purposes and algorithms.

      • Set Purpose to Raw encryption/decryption.
      • For Algorithm, select AES-256-CBC.
  5. Click Create.

After creation, you can use this key for cryptographic operations that require AES-CBC encryption and decryption.

To allow a key to be discoverable in Oracle Cloud Infrastructure (OCI), use this procedure.

  1. In Google Cloud KMS, select the key you want to make discoverable.
  2. Navigate to the Permissions tab and click Add principal.
  3. In the New principals field, enter the service account associated with your Workload Resource Service Agent.

    Note:

    You can find this service account on the Identity Connector details page, under the GCP Information section. Look for the Workload resource service agent and note its ID — this is the required service account.

  4. Under Assign roles, add a role of your choice.

    Note:

    Create a custom role with the following minimum permissions and assign it to the key ring of your choice.

    These permissions together allow OCI to:

    • Discover KMS resources like key rings and keys.
    • Access metadata about keys and their versions.
    • Use the keys for cryptographic operations (encryption/decryption).
    • Create key versions.

    Minimum Required Permissions:

    • cloudkms.cryptoKeyVersions.get

      Allows retrieval of metadata for a specific key version.

    • cloudkms.cryptoKeyVersions.manageRawAesCbcKeys

      Enables management of raw AES-CBC key material (import, rotation, and so on).

    • cloudkms.cryptoKeyVersions.create

      Allows creation of new key versions within a key.

    • cloudkms.cryptoKeyVersions.list

      Lists all versions of a given key.

    • cloudkms.cryptoKeyVersions.useToDecrypt

      Grants permission to use a key version for decrypting data.

    • cloudkms.cryptoKeyVersions.useToEncrypt

      Grants permission to use a key version for encrypting data.

    • cloudkms.cryptoKeys.get

      Allows retrieval of metadata for a key.

    • cloudkms.cryptoKeys.list

      Lists all keys within a key ring.

    • cloudkms.keyRings.get

      Allows retrieval of metadata for a key ring.

    • cloudkms.locations.get

      Retrieves information about supported key locations.

  5. Click Save to apply the changes.
  6. Click Refresh to confirm that the updated permissions have taken effect.

To enable Google Cloud Customer Managed Encryption Keys (CMEK) for your VM cluster, you must first register the GCP Key Ring in OCI.

Note:

Before proceeding, ensure that the permissions outlined in Grant Permissions in Google Cloud KMS for Key Discovery by Oracle Cloud Infrastructure (OCI) have been granted.

  1. In the Database Multicloud Integrations portal, navigate to: Google Cloud Integration > GCP Key Rings.
  2. Click GCP Key Ring,
  3. Click Register GCP key rings
  4. On the resulting Register GCP key rings page, provide the following details:
    • Compartment: Select the compartment where the VM cluster resides.
    • Identity Connector: Choose the Identity Connector attached to the VM cluster.
    • Key Ring: Enter the name of the GCP key ring to register.

      To discover all available key rings through a single identity connector, you must grant the following permissions to that identity connector. These permissions should be assigned at the appropriate project or folder level to ensure the connector can access all key rings across the intended scope.

      • cloudkms.keyRings.list

        Allows listing all key rings within a project.

      • cloudkms.locations.get

        Allows retrieving metadata for a specific key ring.

  5. Click Discover to verify if the key ring exists in GCP.

    If successful, the key ring’s details will be displayed.

    Note:

    Only key rings can be registered — not individual keys. All supported keys associated with a registered key ring will be available, provided the required permissions are in place.

  6. Click Register.

To enable GCP CMEK for your VM Cluster, use this procedure.

Note:

When you provision an Exadata VM Cluster, GCP CMEK is disabled by default.

  1. Open the navigation menu. Click Oracle AI Database, then click Oracle Exadata Database Service on Exascale Infrastructure.

    The VM clusters page is selected by default.

  2. From the list of VM Clusters, select the cluster you want to configure.
  3. On the VM Cluster Details page, scroll to the Multicloud Information section and click Enable next to GCP CMEK.
  4. To disable GCP CMEK, click Disable.
Create a Database and Use GCP Customer-Managed Encryption Key (CMEK) as the Key Management Solution

This topic describes only the steps for creating a database and using GCP Customer-managed encryption key (CMEK) as the key management solution.

For the generic database creation procedure, see To Create a Database in an Existing Oracle Exadata Database Service on Exascale Infrastructure VM Cluster.

Prerequisites

  • Enable Google Cloud Key Management at the VM cluster level.
  • Register the GCP key rings in OCI.

Steps

If Google Cloud Key Management is enabled at the VM cluster, you will have two key management options: Oracle Wallet and GCP Customer Managed Encryption Key.

  1. In the Encryption section, choose GCP Customer Managed Encryption Key.
  2. Select a registered Key ring available in your compartment.

    Note:

  3. Select the key within the selected key ring in your compartment.

To change encryption keys between different encryption methods, use this procedure.

Note:

  • You cannot migrate from GCP Customer Managed Encryption Key to Oracle Wallet.
  • Your database will experience a brief downtime while the key management configuration is being updated.
  1. Navigate to your database details page in the OCI console.
  2. In the Encryption section, verify that Key management is set to Oracle Wallet, and then click the Change link.
  3. Enter the following information on the Change key management page.
    1. Select your Key management as GCP Customer Managed Encryption Key from the drop-down list.
    2. Select the compartment you are using, and then choose the Key Ring available in that compartment.
    3. Next, select the Key compartment you are using, and then choose the desired Key from the drop-down list.
    4. Click Save changes.

To rotate the GCP Customer Managed Encryption Key of a container database (CDB), use this procedure.

  1. Open the navigation menu. Click Oracle AI Database, then click Oracle Exadata Database Service on Exascale Infrastructure.
  2. Choose your Compartment.

    A list of VM Clusters is displayed for the chosen Compartment.

  3. In the list of VM Clusters, click the name of the VM cluster that contains the database that you want to rotate encryption keys.
  4. Click Container Databases.
  5. Click the name of the database that you want to rotate encryption keys.

    The Database Details page displays information about the selected database.

  6. In the Encryption section, verify that the Key Management is set to GCP Customer Managed Encryption Key, and then click the Rotate link.
  7. On the resulting Rotate Key dialog, click Rotate to confirm the action.

To rotate the GCP Customer Managed Encryption Key of a pluggable database (PDB), use this procedure.

  1. Open the navigation menu. Click Oracle AI Database, then click Oracle Exadata Database Service on Exascale Infrastructure.
  2. Choose your Compartment.

    A list of VM Clusters is displayed for the chosen Compartment.

  3. In the list of VM clusters, click the name of the VM cluster that contains the PDB you want to start, and then click its name to display the details page.
  4. Under Container Databases, find the database containing the PDB you want to rotate encryption keys.
  5. Click the name of the database to view the Database Details page.
  6. Click Pluggable Databases in the Resources section of the page.

    A list of existing PDBs in this database is displayed.

  7. Click the name of the PDB that you want to rotate encryption keys.

    The pluggable details page is displayed.

  8. In the Encryption section displays that the Key management is set as GCP Customer Managed Encryption Key.
  9. Click the Rotate link.
  10. On the resulting Rotate Key dialog, click Rotate to confirm the action.

For information about using the API and signing requests, see REST APIs and Security Credentials. For information about SDKs, see Software Development Kits and Command Line Interface.

The following resources will be made available to customers through OCI SDK, CLI, and Terraform. These APIs will be used by customers who wish to integrate Exascale Infrastructure on Exadata with Google Cloud Services.

Table 5-2 OracleDbGcpIdentityConnectors

API Description
ListOracleDbGcpIdentityConnectors Lists all GCP Identity Connector resources based on the specified filters.
GetOracleDbGcpIdentityConnector Retrieves detailed information about a specific GCP Identity Connector resource.
CreateOracleDbGcpIdentityConnector Creates a new GCP Identity Connector resource for the specified ExaDB-D VM Cluster.
UpdateOracleDbGcpIdentityConnector Updates the configuration details of an existing GCP Identity Connector resource.
ChangeOracleDbGcpIdentityConnectorCompartment Moves the GCP Identity Connector resource to a different compartment.
DeleteOracleDbGcpIdentityConnector Deletes the specified GCP Identity Connector resource.

Table 5-3 OracleDbGcpKeyRings

API Description
ListOracleDbGcpKeyRings Lists all GCP Key Ring resources based on the specified filters.
CreateOracleDbGcpKeyRing Creates a new GCP Key Ring resource.
ChangeOracleDbGcpKeyRingCompartment Moves the GCP Key Ring resource to a different compartment.
RefreshOracleDbGcpKeyRing Refreshes the details of a GCP Key Ring resource.
GetOracleDbGcpKeyRing Retrieves detailed information about a specific GCP Key Ring resource.
UpdateOracleDbGcpKeyRing Updates the configuration details of an existing GCP Key Ring resource.
DeleteOracleDbGcpKeyRing Deletes the specified GCP Key Ring resource.

Table 5-4 OracleDbGcpKeyKeys

API Description
ListOracleDbGcpKeys Lists all GCP Key Ring resources based on the specified filters.
GetOracleDbGcpKey Retrieves detailed information about a specific GCP Key resource.

Parent topic: Google Cloud Key Management Integration for Exadata Database Service on Exascale Infrastructure@Google Cloud

Updating the Multicloud PKCS#11 Driver

Note:

The PKCS#11 driver for Google Cloud is installed automatically when Google Cloud Key Management is enabled on a VM cluster. To verify that the driver is installed and check its version, run the following command:

rpm -qa | grep pkcs

This command lists the PKCS package installed on the VM cluster. Only one PKCS#11 driver can be active at a time, corresponding to either Azure, Google Cloud, or AWS.

Example output:

pkcs-multicloud-driver-gcp-0.1-250723.0511.x86_64

This confirms that the pkcs-multicloud-driver-gcp package is installed, along with its version and architecture.

The PKCS#11 driver can be updated using either a rolling or non-rolling mechanism, depending on customer preference.

In rolling mode, the update is applied to one VM at a time, and the databases on that VM are restarted before proceeding to the next. In non-rolling mode, all databases in the cluster are shut down, the update is applied across all nodes, and the databases are then brought back online. Users must be aware of the dbaastools version in use, as subsequent steps, specifically step 3 in both scenarios, require

The version of dbaastools can be determined by running the following command: 

/var/opt/oracle/dbaascli/dbaascli admin showLatestStackVersion

Rolling update

On each Guest VM, apply the PKCS#11 driver update as follows (one VM at a time):

  1. Shutdown the database instances that are using the Google Cloud KMS.

    All databases that use the Google Cloud KMS for master encryption keys (MEK) must be stopped before updating the driver. Use:

    srvctl stop instance -d <db_unique_name> -i <instance_name> [-o <stop_option>]
    • -d <db_unique_name>: The unique name of the database (same as DB_UNIQUE_NAME in the database).
    • -i <instance_name>: The name of the instance to stop, for example, orcl1.

    For details on additional options, refer to the SRVCTL command-line help or reference manual.

  2. Verify that the databases have been shut down.

    Ensure that all database instances that are using the Google Cloud KMS have been stopped before proceeding.

  3. Upgrade the RPM.

    As the root user, run the following command (for dbaastools 25.4.1 and later): 

    /var/opt/oracle/dbaascli/dbaascli admin updateMCKMS --keystoreProvider GOOGLE --nodeList <node> --databasesStopped

    This command downloads and installs the latest RPM on the specified node.

  4. Verify driver installation.

    Run the following command as the root user: 

    /bin/rpm -qa | grep -i pkcs-multicloud-driver
  5. Start the database instances.

    After the driver update, restart the database instances using:

    <oracle_home>/bin/srvctl start instance -node "<node>"

Non-Rolling update

In non-rolling mode, all databases on the cluster are stopped before applying the PKCS#11 driver update.

  1. Stop databases using the Google Cloud KMS.

    Stop all databases that use the Google Cloud KMS for master encryption keys (MEK) before updating the driver:

    dbaascli database stop [--dbname <value>]
  2. Verify that the databases have been shut down.

    Ensure that all databases using the Google Cloud KMS have been stopped before proceeding.

  3. Update the RPM.

    As the root user, run the following command (for dbaastools 25.4.1 and later): 

    /var/opt/oracle/dbaascli/dbaascli admin updateMCKMS --keystoreProvider GOOGLE --databasesStopped

    This command downloads and installs the latest RPM.

  4. Verify driver installation.

    Run the following command as the root user: 

    /bin/rpm -qa | grep -i pkcs-multicloud-driver
  5. Restart the databases

    Once the driver has been updated, restart the databases:

    dbaascli database start [--dbname <value>]

Parent topic: Google Cloud Key Management Integration for Exadata Database Service on Exascale Infrastructure@Google Cloud