OCI Secret Management FAQ

General

What is Oracle Cloud Infrastructure Secret Management?

OCI Secret Management is a managed service that securely stores, retrieves, rotates, and manages secrets—sensitive information such as passwords, API keys, tokens—that are used across your applications and cloud environments. Secrets are encrypted at rest, versioned, and accessible through APIs, SDKs, CLI, and the OCI Console.

What problems does OCI Secret Management solve?

OCI Secret Management eliminates the need to store credentials in source code, configuration files, or external stores. The service facilitates centrally managed access control, automatic versioning, secure secret distribution, and consistent auditability across Oracle Cloud applications.

Service capabilities

What types of secrets can I store?

You can store any sensitive text or binary payload that applications need to operate securely, including:

• Database passwords
• Access tokens
• API keys for third-party services
• Secure Shell (SSH) private keys
• Application configuration secrets
• OAuth2 or JWT signing credentials

How are secrets protected?

All secrets are encrypted using keys that reside in OCI Vault. Vaults use FIPS-validated hardware security modules (HSMs) or software-based protection depending on the key's protection mode. Encryption, decryption, access control, and audit logging are fully managed by OCI.

Can I store secrets across compartments and regions?

Yes. You can organize secrets within compartments and manage them globally across multiple regions. Replication is supported at the secret level. When enabled, all versions and metadata of a secret are asynchronously copied to the target region.

What are the default limits for OCI Secret Management?

You can have 5,000 secrets in a tenancy spread across a single or multiple vaults. Additionally, you can have 30 secret versions in active use and 30 versions pending deletion for each secret.

Access and permissions

How do I control who can access my secrets?

Access is governed via OCI IAM policies. You can grant fine-grained permissions such as:

• Read secrets
• Inspect secrets
• Use secrets
• Manage secrets

You can also scope access by compartments, groups, dynamic groups, and resource types to align with your security model.

Can applications use secrets without exposing them to users?

Yes. Applications authenticate through resource principals or instance principals and retrieve secrets programmatically without embedding credentials in code.

Rotation and lifecycle

What IAM policies are required for secret rotation?

To enable secret rotation in OCI, you must allow groups or dynamic groups to manage secret families, use vaults, and use keys in the relevant compartment. For more guidance, see the OCI IAM policy reference documentation.

Does OCI Secret Management support automatic rotation?

Yes. Secrets can be rotated manually or through automation, either by integrating with OCI Functions, using external rotation workflows, or calling APIs to create new versions and update references.

What happens when I delete a secret?

When you delete a secret, you’ll trigger a designated retention period from 24 hours up to 30 days during which the secret cannot be used, but you can still cancel the deletion if needed. After that time, the secret will be permanently deleted and cannot be recovered.

Is it possible to prevent secrets from being reused or to set an expiry?

Yes, you can configure rules to prevent the reuse of previous secret values and set an expiration date for secrets to help enforce regular rotation and strong security practices.

How do applications update after a secret is rotated?

Applications should always reference a stable secret OCID. When a new version is created, the OCID remains unchanged. Only the version pointer updates. This allows seamless rotation with minimal downtime.

Can I delete old secret versions?

Yes. Deprecated secret versions can be scheduled for deletion.

Cross-region replication

What is cross-region replication?

Cross-region replication allows you to automatically copy secrets from a primary region to one or more secondary regions. This enables high availability, regional failover, and consistent secret access for globally distributed applications.

How does replication work?

Replication is configured at the secret level. All secrets and their versions in a replicated vault are asynchronously copied to the target region. Updates in the primary region propagate to replicas without manual intervention.

How many regions can I replicate my secrets to?

You can replicate secrets to three regions.

Does replication impact pricing?

OCI Secret Management is a free service, but pricing for target vault/keys may apply. Please consult OCI Key Management Service pricing for more information.

What happens if the primary region is unavailable?

Applications can continue retrieving secrets from replica regions. Once the primary region is restored, the system resumes normal synchronization.

Does replication include secret versions?

Yes. Every secret version is replicated. When a new version is created or rotated, the change propagates across regions.

Secret auto-generation

What is secret auto-generation?

Auto-generation allows OCI to create a secret value for you using strong cryptographic randomness. This avoids manual creation errors and helps ensure consistent security hygiene.

Can I customize the generated secret?

Yes. You can specify length, complexity requirements, allowed characters, and other constraints depending on your application needs.

Does auto-generation work across compartments or regions?

Generation happens in the region where the secret is created. If vault replication is enabled, the generated secret will propagate to other regions.

Secret auto-rotation

What is automatic secret rotation?

Auto-rotation enables OCI to automatically create a new version of a secret based on a rotation schedule or event trigger. This helps eliminate stale credentials and reduces operational overhead.

Do applications need to change after rotation?

No. Applications reference the same secret OCID. When auto-rotation creates a new version, the OCID remains stable, so no configuration changes are required.

What happens to older versions after rotation?

They remain accessible unless explicitly deleted. You can disable older versions, set deletion schedules, or keep them for rollback/audit purposes.

Can auto-rotation happen across multiple regions?

Rotation always occurs in the primary region. If vault replication is enabled, the updated secret is replicated to secondary regions.