OCI Vault: Secrets and Key Management for Apps

Ask a team where their application credentials live and you rarely get one answer. Some are in environment variables set by a pipeline. Some are in a configuration file that was committed to the repository three years ago and never quite removed from history. None of this is unusual, and none of it survives contact with an auditor. The fix on Oracle Cloud Infrastructure is OCI Vault, and the good news is that the service is inexpensive, well integrated with the rest of the platform, and far simpler to adopt than most teams expect.

This article is the security layer of our series on application development and serverless on OCI. We will cover what Vault holds and how its two halves differ, the vault types and their tradeoffs, how keys and secrets are versioned and rotated, the consumption patterns that keep credentials out of code, the IAM policies that enforce least privilege, and the mistakes we keep finding in reviews.

The two things Vault holds

OCI Vault is really two services behind one name, and confusing them is the most common source of muddled designs. The first half is key management: Vault creates and stores master encryption keys, performs cryptographic operations with them, and lets other OCI services encrypt their data under keys you control. The keys themselves are the product; the data they protect lives elsewhere. The second half is secrets management: Vault stores arbitrary sensitive values, passwords, tokens, certificates, connection strings, and serves them to authorised callers on request. Here the stored value is the product, and Vault encrypts it at rest using one of the keys from the first half.

The distinction matters because the two halves have different consumers. Keys are mostly consumed by OCI services and by platform teams: an Object Storage bucket encrypted under a customer managed key, a block volume, a database. Secrets are mostly consumed by applications: a microservice that needs a database password at startup. Application teams spend ninety percent of their Vault time on the secrets side, but they inherit decisions made on the keys side, so it pays to understand both.

Vault types and protection modes

When you create a vault you choose between two types, and the choice is permanent for that vault. A default vault shares an underlying hardware security module partition with other tenants, with strict logical isolation between them. A virtual private vault gives you a dedicated HSM partition all to yourself, with higher operation limits and the ability to back up and restore the entire vault as a unit. Independently of vault type, each key carries a protection mode: HSM keys are generated inside the hardware module and can never leave it in plaintext, while software keys are held on encrypted infrastructure outside the HSM, cost nothing, and can be exported in wrapped form if you ever need them elsewhere.

Our advice is blunt: start with a default vault. The shared partition still keeps HSM keys inside certified hardware, satisfies the large majority of compliance regimes, and costs close to nothing. A virtual private vault is a five figure annual commitment that earns its keep only when a regulator or a contract explicitly demands dedicated hardware isolation, or when your cryptographic operation volume genuinely exceeds shared limits. Buying one because it sounds more secure is the most expensive form of reassurance on the platform.

Key management concepts that matter to app teams

A master encryption key in Vault is not used to encrypt your data directly. Vault uses envelope encryption: the service that holds your data generates a local data encryption key, encrypts the data with it, then asks Vault to wrap that data key under your master key. The wrapped data key is stored alongside the data; the master key never leaves the vault. Decryption reverses the dance. The practical consequence is that rotating a master key is cheap, because nothing rewraps terabytes of data, only the small data keys are affected going forward.

Rotation creates a new key version. Old versions remain available so previously wrapped data keys still unwrap, while new operations use the latest version. A sensible rotation policy, annual for most keys, quarterly for the sensitive ones, costs almost nothing and closes a finding before an auditor opens it. The payoff for managing your own keys is control over the blast radius: a long list of OCI services can encrypt with customer managed keys, including Object Storage buckets, block and boot volumes, file storage, Autonomous Database, streaming, and the Kubernetes secrets store in OKE. Disable or schedule deletion of the key and everything encrypted under it becomes unreadable, which is a powerful control and an equally powerful foot gun, so guard key administration tightly.

Secrets management in practice

A secret in Vault is a named, versioned container for a sensitive value. Applications retrieve a secret bundle, which is the value plus metadata such as the version number and stage. Versions move through rotation states: the version applications normally read is marked current, a newly staged value can sit as pending before promotion, and the superseded value remains as previous so that consumers caught mid rotation can still authenticate. This three stage model is what makes zero downtime credential rotation possible: update the target system and the secret in a coordinated sequence, and clients on either side of the cutover keep working.

Vault can generate secret content for you, which removes humans from the password creation business entirely: nobody types it, nobody knows it, nobody can leak it over a screen share. For rotation, Vault supports scheduled rotation policies and can drive the actual change through a rotation function, a small piece of code in OCI Functions that updates the credential at the target, database, third party API, whatever, and promotes the new secret version.

How applications should consume secrets

The consumption pattern matters as much as the storage. The first rule is that the application should authenticate to Vault using an identity the platform gives it, not a credential someone provisioned. On compute instances that means instance principals; in Functions and OKE workloads it means resource principals. Either way, the running workload proves who it is to IAM without any API key existing, which means there is no bootstrap secret to protect, the turtles stop somewhere solid.

The second rule is to fetch at startup and cache in memory. Calling Vault on every request adds latency and burns request quota for no benefit; reading the secret bundle once at initialisation, caching it, and refreshing on a timer or on an authentication failure gives you fresh credentials with negligible runtime cost. The third rule is absolute: secrets never travel inside container images, and they never sit as plaintext environment variables in pipeline configuration files. Both are one accidental grant away from disclosure. The artifact should contain a reference to the secret, its OCID, and nothing more.

IAM patterns for least privilege

Vault is only as good as the policies around it, and OCI gives you the right primitives. Secrets support free form grouping, and policy statements can scope access to specific secrets or to a compartment that holds one application's secrets. The pattern we deploy is one compartment or one clearly named secret set per application, a dynamic group matching that application's workloads, and a policy that grants the dynamic group read on secret family in that scope and nothing else. Reading a secret bundle requires only read; the verbs use, manage, and anything touching keys stay with the platform team. The wrong pattern, and we see it constantly, is a single broad policy letting all instances in the tenancy read all secrets, which converts any compromised workload into a master key for the estate.

Integration across the application stack

Vault touches every layer of a modern OCI application platform. On OKE, two patterns dominate. The External Secrets Operator syncs Vault secrets into native Kubernetes secrets on a schedule, which suits teams that want standard Kubernetes consumption with Vault as the source of truth. The Secrets Store CSI driver pattern instead mounts secrets into pods as files at startup, never materialising them as Kubernetes objects at all, which auditors tend to prefer. Either is dramatically better than secrets pasted into manifests.

In Functions, resource principals plus a Vault read at cold start is the canonical pattern, and it keeps function configuration limited to harmless settings. In build pipelines, the OCI DevOps service resolves Vault references in build specifications at run time, so the pipeline definition in version control carries OCIDs rather than values, and the build agent fetches the real credential only for the moments it needs it. At the edge, API Gateway leans on Vault for the certificates and client credentials behind custom domains and upstream authentication. The common thread is that every layer can reference a secret by identity rather than by value, and once the whole stack works that way, leaking a credential requires deliberate effort instead of routine carelessness.

Auditing, replication, and the impossibility of fast deletion

Every cryptographic operation against a key and every read of a secret lands in the OCI Audit log automatically, with the identity, the resource, and the timestamp. This is the quiet superpower of centralising credentials: the question every incident responder asks, who accessed this credential and when, has an answer that takes one query instead of one forensic engagement. Route those audit events to your monitoring stack and alert on anomalies.

For resilience, Vault supports replication of vaults to another region, keeping keys and secrets available to a disaster recovery site, and virtual private vaults add full backup and restore through Object Storage. Plan the cross region story before you need it: a failover application that cannot read its secrets is not failed over, it is merely relocated. Note that vault OCIDs differ across regions, so applications should resolve secret references through configuration rather than hardcoding a single region's identifiers.

Deletion deserves its own paragraph, because Vault refuses to do it quickly and that is a feature. Vaults, keys, and secrets are deleted by scheduling, with a waiting period of days, seven by default for vaults and keys, before the deletion becomes real, and during the window the action can be cancelled. There is no button that destroys a key immediately, because a key destroyed in anger or by a compromised account would render every byte encrypted under it permanently unreadable. The waiting period is the platform protecting you from your worst day.

What it costs

The cost model is friendlier than most teams assume. Default vaults are free to create, software protected keys are free, and a monthly allowance covers your first HSM key versions before a small per version charge applies. Secrets are effectively free at modest scale, with generous limits on the number of secrets and on retrieval requests before any charge appears; for the typical application estate the secrets bill rounds to zero. The one number that demands a decision is the virtual private vault, which is a significant fixed monthly commitment whether you store one key or a thousand. Everything else in Vault is cheap enough that cost is never a valid reason to leave credentials unmanaged.

Common mistakes

Four failures account for most of what we find in security reviews. First, one giant vault for the whole tenancy, where every team's keys and secrets share a single policy boundary, making least privilege impossible. Vaults are cheap; create them per environment and per domain. Second, secrets in build specs, plaintext values committed to version control because the pipeline needed them and the deadline was near. Third, no rotation policy, where the vault becomes a beautifully audited museum of five year old passwords. Storage without rotation captures perhaps half the value. Fourth, granting manage keys to application principals, usually from a policy written in haste, which hands workloads the power to disable or schedule deletion of the keys protecting the entire estate. Applications read secrets; humans and break glass processes manage keys; the verbs exist precisely so you can keep those worlds apart. Our OCI security practice spends a remarkable share of its time fixing exactly these four.

A seven step path from scattered credentials to Vault

Moving an existing application estate onto Vault backed secrets is less a project than a sequence of habits. This is the order we run it in.

Bringing it together

OCI Vault is one of those services where the engineering effort is modest and the payoff compounds. Keys give you control over how the platform encrypts your data; secrets give your applications a single, audited, rotatable source for every credential they hold; resource principals remove the bootstrap problem that undermines secret stores elsewhere. The teams that struggle are not fighting the service, they are fighting their own habits: credentials in images, policies written too broadly, rotation deferred forever. Fix the habits, keep the layout boring, and Vault quietly becomes the part of your security posture you never think about. If you want a second pair of eyes on your vault layout, IAM policies, or rotation design, that is core work for our security team, and it usually starts with a short assessment of where the credentials actually live today.