OCI Key Vault for Oracle E-Business Suite on OCI

Contents

Terminology note

In everyday conversation, “OCI Key Vault” is often shorthand for OCI Vault. Oracle’s current services actually separate two capabilities: OCI Key Management stores and manages encryption keys, while Secret Management stores application secrets such as passwords, certificates, SSH keys, and authentication tokens. Throughout this guide, “OCI Key Vault” is the umbrella term — and the exact service is named whenever the distinction matters.1 2

00Executive summary

Oracle E-Business Suite deployments on OCI typically split the load balancer, application tier, and database tier into distinct network segments — which raises an obvious question: where should all the credentials, certificates, keys, and integration secrets actually live?

Oracle’s reference topology supports private application and database subnets, an optional bastion host, and logical host names that reduce reconfiguration during failover.3 The stronger pattern is to treat OCI Vault and Secret Management as the controlled security plane for EBS-related credentials, and to grant the application tier access through OCI workload identity rather than long-lived user API keys.

◆What a well-designed implementation does

Keeps secrets in a dedicated security compartment.
Encrypts each secret with a symmetric master key in the same vault.
Grants read access only to the EBS nodes or automation identities that need it.
Uses dynamic groups and instance principals for Compute-based nodes.
Retrieves secrets at runtime or during controlled deployment steps.
Rotates secrets with an overlap window and a rollback plan.
Re-creates the security configuration in the DR region.
Monitors access, failed retrievals, version changes, and rotation events.

The result is a smaller blast radius, clearer ownership, and a repeatable security model for both production and non-production EBS environments.

01Why secrets management matters for EBS on OCI

Oracle EBS is a multi-tier enterprise application. The application tier holds web and middle-tier services; the database tier holds the Oracle Database services that store business data. Oracle’s OCI deployment guidance recommends separating these tiers and using logical host names to make movement, failover, and reconfiguration easier.

Those tiers and the surrounding platform commonly need access to a wide range of security material:

Secret or security object	Typical consumer	Why centralize it
Database account credentials	EBS admin scripts, monitoring, deployment automation	Prevent password values from being copied into scripts and runbooks
Integration credentials & tokens	REST/SOAP integrations, schedulers, middleware, external systems	Support controlled rotation without editing every consumer manually
TLS private keys & certificates	Load balancer, web tier, integration endpoints	Provide an auditable lifecycle for certificate material
SSH keys / bootstrap credentials	Provisioning and controlled administration	Reduce unmanaged key copies and simplify revocation
Backup / replication credentials	Backup jobs and DR automation	Keep recovery credentials separate from ordinary application credentials
Wallet passwords / keystore material	Database and middleware security tooling	Limit access to the processes that actually require it
Encryption keys	OCI services and selected application integrations	Separate key custody from application administration

OCI Secret Management supports secrets such as passwords, certificates, SSH keys, and authentication tokens. When a secret is created, OCI encrypts the imported content with a symmetric encryption key in the selected vault; asymmetric keys cannot be used to create secrets.

The key point is scope. OCI Vault should hold the security material EBS and its automation need — but it is not a universal replacement for every EBS credential store or application configuration mechanism. Validate each credential flow against the EBS release, the certified integration pattern, and the operational support model.

02OCI Vault, Key Management & Oracle Key Vault — use the right product

Three names are easy to confuse. Getting the distinction right up front saves a great deal of rework later.

OCI Vault & Key Management

OCI Key Management is the OCI service for centralized management and control of encryption keys. It supports symmetric and asymmetric key types, key versions, key rotation, and multiple custody options — including key material generated in OCI, imported key material, and external key-management patterns. OCI documents HSM-backed options for protecting keys.

OCI Secret Management

Secret Management is the service for storing and retrieving secret values. A secret is encrypted with a master encryption key and can have multiple versions. OCI also supports optional cross-region replication and configurable rotation and expiry rules, subject to the target integration and regional capabilities.

Oracle Key Vault

Oracle Key Vault is a separate Oracle product: a security appliance/software platform designed to centrally manage Oracle wallets, Java keystores, certificates, passwords, and other security objects. It can also be deployed as a VM in OCI.

For most EBS-on-OCI platform designs:

Use OCI Vault / Key Management when OCI-native services and application integrations need centrally managed encryption keys.
Use OCI Secret Management for passwords, tokens, certificates, and other runtime secret values.
Consider Oracle Key Vault when the requirement is specifically centralized enterprise keystore and wallet management across Oracle Database, middleware, and other endpoints.

Rule of thumb

These products can complement one another, but they solve different problems. Do not select Oracle Key Vault merely because the word “key” appears in the requirement.

03Reference architecture for EBS on OCI

Internet / Corporate Users

OCI Load Balancer tier

EBS Application Tier

private subnet · 2+ nodes

Optional Bastion

admin access path

OCI Workload Identity

dynamic group + instance principal

Secret Management API

Security Compartment

vault · master key · secrets

DR Security Compartment

vault / secret replica · DR key

Database Tier on OCI

Figure 1 — A reference security layout for an Oracle EBS deployment on OCI.

Oracle’s EBS topology guidance describes a load-balancer tier, application tier, and database tier, with the application tier in a separate subnet and private load balancers available for internal endpoints. It also describes an optional bastion host for controlled access to private instances.

Recommended compartment model

ebs-prod-app — application Compute instances and application configuration.
ebs-prod-db — database resources.
ebs-prod-security — vaults, keys, and secrets.
ebs-prod-network — VCN, subnets, gateways, NSGs, and load balancers.
Separate compartments for non-production and DR.

The exact hierarchy can differ by enterprise landing-zone standards. The important control is to keep vault resources in a compartment with tighter administrative membership than the EBS application resources.

Vault type and custody

Select the vault type and key-custody model based on the threat model, compliance requirements, performance needs, and cost. OCI documents differences in storage isolation, access to management and encryption operations, scalability, backup behavior, and pricing across vault types. Vault type cannot be changed after creation.

For a production EBS environment, document:

Who can administer the vault.
Who can use keys for cryptographic operations.
Who can read secret values.
Whether key material must be HSM-protected.
Whether imported or externally managed keys are required.
How production and non-production keys are kept separate.

04Step-by-step implementation

Step 1 — Define the secret inventory

Create an inventory before creating resources. For each item, record its name and business purpose, owning team, consumer workload, environment, rotation interval, recovery priority, the value type (password, token, certificate, private key, or opaque byte string), and whether the consumer supports hot reload, restart-based rotation, or dual credentials.

Use names that identify purpose without exposing the value. Oracle explicitly advises avoiding confidential information in secret names and descriptions.

naming-convention

# pattern
ebs/<environment>/<system>/<purpose>

# examples
ebs/prod/db/apps-password
ebs/prod/integration/payables-token
ebs/prod/web/tls-private-key
ebs/prod/backup/object-storage-credential

Step 2 — Create the vault and master encryption key

Create a vault in the security compartment, then create a symmetric master encryption key for secrets. OCI Secret Management requires a symmetric key in the same vault when creating a secret. For production, consider separate keys for application secrets, backup and recovery secrets, certificate/private-key material, and non-production environments.

This separation makes incident response and scheduled rotation more precise — and avoids turning one key into a single administrative choke point. If automatic key rotation is enabled, confirm the vault type and key state support the chosen configuration. OCI documents automatic rotation for keys in virtual private vaults, with configurable intervals from 60 to 365 days.

Step 3 — Create secrets with deliberate versioning

Create one secret per independently rotated value. Avoid stuffing an entire configuration file into a single large secret unless the consumer genuinely requires an atomic bundle. OCI supports manual creation and automatic generation for supported formats; the documented maximum bundle size is 25 KB, and secret content sent through APIs or CLI must be base64-encoded.

A good secret payload is minimal, explicitly versioned by OCI, free of unrelated values, and structured only when the consumer benefits from a structured object. For a certificate bundle, store the certificate and private key together only if the consuming integration requires it; otherwise keep them as separate secrets with independent ownership and rotation.

Step 4 — Create a dynamic group for the application tier

Compute instances can call OCI services without embedding a user’s API signing key. OCI dynamic groups let instances act as principal actors, and instance-principal authentication is supported by the OCI SDKs, CLI, and Terraform.

A typical dynamic-group rule should match only the intended EBS application instances:

A dedicated application compartment.
A dedicated defined tag such as role=ebs-app.
An explicit list of instance OCIDs for the most restrictive model.
A combination of compartment and tag conditions.

Treat the rule like code

Avoid a rule that includes every instance in the tenancy. The dynamic group is a security boundary; its matching rule deserves the same review as production code.

Step 5 — Grant least-privilege policies

Use separate policies for administrators and workloads. An illustrative workload policy:

workload-policy · IAM

Allow dynamic-group ebs-prod-app-dg to read secret-bundles
  in compartment ebs-prod-security

An illustrative key-usage policy — only if the workload must perform cryptographic operations directly:

key-usage-policy · IAM

Allow dynamic-group ebs-prod-app-dg to use keys
  in compartment ebs-prod-security

Treat these as templates, not copy-and-paste production policy. OCI’s policy reference maps operations such as GetSecret, GetSecretBundle, and key cryptographic operations to distinct permissions. Start with the narrowest resource family and compartment scope, then test the exact API calls the application uses.

Do not grant the application tier permission to create, delete, rotate, or move vault resources unless there is a documented, tightly controlled reason. In most environments: security administrators manage vaults and keys, application operators manage EBS services, the application runtime reads only the specific secret values it needs, and rotation automation is a separate identity with a separate policy.

Step 6 — Retrieve secrets with instance principals

The application or automation process should authenticate with an instance principal and retrieve the current secret version at runtime.

retrieve_secret.py

import base64
import oci

secret_id = "ocid1.secret.oc1..example"

signer = oci.auth.signers.InstancePrincipalsSecurityTokenSigner()
client = oci.secrets.SecretsClient(config={}, signer=signer)

bundle = client.get_secret_bundle(
    secret_id=secret_id,
    stage="CURRENT"
).data

encoded = bundle.secret_bundle_content.content
secret_value = base64.b64decode(encoded).decode("utf-8")

The SDK pattern follows Oracle’s documented InstancePrincipalsSecurityTokenSigner approach. The actual EBS integration should decide whether the value is consumed in memory, written to a short-lived file with restrictive permissions, or passed to a child process.

Recommended handling rules:

Never print the secret or the full API response to logs.
Never place the secret in command-line arguments where process inspection can expose it.
Keep temporary files on encrypted local storage with restrictive permissions.
Delete temporary material after use.
Cache only for the shortest practical period.
Fail closed when retrieval is unavailable — unless the operation is explicitly designed for offline recovery.
Use a secret identifier or OCID in configuration, never the secret value.

Step 7 — Integrate with EBS safely

OCI Vault does not automatically rewire every EBS credential flow. Treat integration as an adapter layer around the specific consumer:

Startup scripts that fetch a database or integration credential before a service starts.
Deployment automation that injects a value only for the duration of a change.
Scheduled jobs that retrieve a token immediately before calling an external system.
Certificate-renewal automation that updates the load balancer or web tier through a controlled release.
DR runbooks that retrieve recovery credentials only during a recovery operation.

Avoid editing EBS configuration files blindly. For each credential, document the authoritative source of truth, the retrieval mechanism, the file or process that consumes it, whether a service restart is required, the rollback procedure, and the validation test after rotation. This adapter pattern preserves the supported EBS configuration model while moving secret custody and access control into OCI.

05Rotation without downtime

Secret rotation is not complete when a new value is uploaded. It is complete only after every consumer has moved to the new version and the old value is no longer needed. Use a two-phase rotation pattern.

Phase A

Prepare

Generate or obtain the replacement credential.
Add it to the target system while the old credential stays valid.
Publish a new OCI secret version.
Confirm the consumer can retrieve the new version.
Run a connectivity or health check.

Phase B

Cut over

Switch the EBS process or integration to the new version.
Monitor application, database, and integration errors.
Revoke or disable the previous credential after the observation window.
Record the version, timestamp, operator, and validation result.

OCI supports secret versions, automatic generation for supported formats, rotation configuration for supported target systems, and expiry/reuse rules. For EBS credentials that cannot overlap, schedule a controlled maintenance window. Do not assume that changing the OCI secret alone changes the password in Oracle Database, an external endpoint, or an EBS configuration file.

06Disaster recovery and regional design

A DR design must protect both the application data and the ability to authenticate the recovery automation. At minimum, replicate the following as documented configuration:

Vault definitions.
Key definitions and custody decisions.
Secret names and ownership metadata.
Dynamic groups and matching rules.
IAM policies.
Network routes and endpoint access.
Rotation and expiry rules.
Recovery runbooks and validation scripts.

OCI supports cross-region secret replication to destination vaults, with a documented limit of up to three destination regions in the secret-creation workflow. The destination vault and encryption key must be selected for each replica.

Replication is not testing

Do not treat replication as a substitute for a real DR exercise. A quarterly test should verify each of the checks below.

The DR application instances match the dynamic-group rule.
The DR policy grants access to the replica vault.
The DR application can authenticate with instance principals.
The expected secret version is available in the destination region.
The database and integrations accept the recovered credentials.
Rotation can continue after failover.

Oracle’s EBS topology guidance emphasizes logical host names because they reduce failover reconfiguration. Apply the same principle to secret identifiers and automation: keep names stable across primary and DR, changing only region-specific resource identifiers in the deployment configuration.

07Governance, audit, and operations

Separate duties

A mature operating model separates vault and key administrators, secret owners, EBS application operators, database administrators, network administrators, and DR/continuity owners.

The core principle

The person who can deploy an EBS node should not automatically be able to read every production secret.

Tag everything that helps operations

Use defined tags for environment, application, owner, data classification, rotation class, DR tier, cost center, and decommission date. Avoid putting credentials, tokens, or other confidential values in tags, names, or descriptions.

Monitor the full lifecycle

Create alerts and operational checks for:

Failed secret retrievals.
Unexpected access from a new instance or compartment.
Secret version creation.
Secret or key expiry.
Rotation failures.
Replication lag or replica health.
Disabled or scheduled-for-deletion keys.
Application errors immediately after a rotation.

OCI documents monitoring through metrics, alarms, and notifications for OCI resources. Use those platform controls alongside EBS application logs and integration health checks.

Back up the control plane, not just the data plane

A database backup without the credentials and key-management configuration required to restore it is an incomplete recovery strategy. Store the vault design, policy source, dynamic-group rules, secret inventory, and recovery procedures in a protected, version-controlled location. Never put the secret values themselves in source control.

08Common anti-patterns to avoid

✕Hard-coding secrets in EBS scripts

This creates long-lived copies in file systems, backups, support bundles, and code repositories.

✕Using a human user’s API key on every application node

Human credentials are difficult to scope and rotate at fleet scale. Prefer instance principals for Compute-based workloads.5

✕Granting tenancy-wide read access

A single compromised node should not be able to enumerate or read unrelated application secrets.

✕Treating key rotation and secret rotation as the same event

A master encryption-key rotation protects the encryption boundary. It does not automatically change a database password, integration token, or certificate in the target system.

✕Rotating without a consumer test

A new secret version that no process can use is an outage waiting to happen. Always validate retrieval and end-to-end connectivity.

✕Mixing environments in one vault without a clear reason

Production, test, and development should have explicit isolation boundaries. Reuse only when the ownership and blast-radius analysis supports it.

✕Assuming DR “just works”

A standby application can still fail if its dynamic-group rule, policy, network path, destination vault, or replica secret is missing.

09A production-readiness checklist

Tap each item as you confirm it — the meter tracks how close you are to production-ready.

Readiness0 / 14 confirmed

The EBS release and OCI deployment pattern are supported and documented.
Vaults and keys are in a dedicated security compartment.
Production and non-production security objects are separated.
Every secret has an owner, purpose, consumer, and rotation policy.
Secret names and descriptions contain no confidential values.
EBS Compute nodes use a narrowly scoped dynamic group.
Instance-principal access works from every intended application node.
Policies permit only the required read or cryptographic operations.
Secret values never appear in logs, command lines, or source control.
Rotation has been tested with rollback.
DR vaults, replicas, policies, and matching rules are tested.
Alerts exist for retrieval failures, expiry, rotation, and replication issues.
The recovery runbook has been executed by someone other than its author.
Decommissioning steps revoke access and schedule obsolete versions/resources for deletion.

→Conclusion

For Oracle E-Business Suite hosted on OCI, OCI Vault is most valuable when it becomes part of the deployment’s operating model — not when it is bolted on as a last-minute password drawer.

Use OCI Key Management for encryption-key custody, Secret Management for runtime secret values, dynamic groups and instance principals for workload identity, and a small adapter layer to connect those controls to the EBS services and automation that actually consume the credentials.

The strongest implementation is deliberately boring: narrow policies, stable identifiers, documented ownership, predictable rotation, tested DR, and no secrets in scripts.

That is exactly what makes it resilient at enterprise scale.