OCI Vault and Key Management

Encrypting data is the easy part. OCI encrypts most things by default, and turning it on for the rest is rarely the hard work. The hard work is the keys. A key that anyone can use protects nothing. A key you lose can take your data with it. A key you never rotate becomes a long lived risk. OCI Vault is the service that holds keys and secrets and lets you manage them properly, and getting key management right is what turns encryption from a checkbox into real protection.

Vault does two related jobs. It manages encryption keys, the cryptographic material that protects your data, and it manages secrets, the passwords, tokens, and credentials your applications need but should never hold in plain text. Both jobs come down to the same principle, which is that sensitive material should live in one controlled place with tight access and a clear record of use, not scattered through configuration files and scripts where it leaks.

Keys and secrets, and why they differ

A key is used to encrypt and decrypt data. You rarely see the key itself. You reference it, and the platform uses it on your behalf to protect a database, a volume, or a bucket. A secret is a value your application reads directly, a database password or an API token, which the application then uses to authenticate somewhere. The distinction matters because the operational patterns differ. Keys are rotated and their use is governed by policy. Secrets are retrieved at runtime and need to be rotated without breaking the applications that depend on them.

Both belong in Vault rather than in your code or configuration. The moment a credential lives in a file in a repository or an unencrypted variable, it is one mistake away from exposure. Centralising them in Vault means access is controlled by the same identity model described in our IAM policies guide, and every use is recorded for the audit trail covered in our audit and logging guide.

Oracle managed versus customer managed keys

The first real decision is who controls the key. With Oracle managed keys, the platform handles the key material for you, which is simple and removes operational burden. With customer managed keys, you create and control the key in Vault, which gives you authority over its lifecycle, its rotation, and the ability to disable it. Many compliance requirements and many security postures call for customer managed keys precisely because that control is the point.

A sensible default is to use customer managed keys for anything sensitive or regulated, and to reserve Oracle managed keys for workloads where the simplicity is worth more than the control. This tiering matches the broader approach in our data encryption guide, where the question is always proportionate to the value of what is being protected.

Operating keys without painting yourself into a corner

The danger with customer managed keys is the same danger as with any powerful control, which is that you can hurt yourself with it. If you disable or delete a key that is protecting live data, that data becomes unreadable. So key operations need discipline. Rotation should be planned and tested so it does not break dependent workloads. Deletion should be rare, deliberate, and preceded by certainty that nothing depends on the key. Access to manage keys should be tightly held, separate from access to use them.

Secrets in practice

For secrets, the win is removing credentials from places they should never be. Instead of a database password sitting in an application configuration file, the application retrieves it from Vault at runtime using its own identity. That means the password can be rotated centrally without redeploying the application, and there is no plain text credential to leak. It also means the access to that secret is governed and recorded, so you know which workload read which secret and when.

The pattern works best when applications authenticate to Vault using workload identity rather than yet another stored credential, which avoids the bootstrapping problem of needing a secret to get a secret. This connects to the identity design in our identity domains guide and is part of what makes a zero trust posture practical.

Vaults, key types, and where they live

A practical question that comes up early is how many vaults to create and where to put them. The instinct to centralise everything in one vault is understandable, but it concentrates risk and access in a single place, while creating a vault for every tiny purpose fragments management and makes the picture hard to reason about. A workable middle ground is to align vaults with meaningful boundaries in your estate, such as separating production from non production and separating workloads that have genuinely different access requirements. That way the right to use the keys for a sensitive production workload can be held by a different set of people than the keys for a development environment, which is the separation that limits the blast radius if any one set of credentials is compromised.

There is also a choice between standard key storage and higher assurance storage backed by dedicated hardware, where the latter offers stronger isolation for the most sensitive material at a higher cost. The right answer is proportionate, as it is throughout security: reserve the higher assurance option for the keys protecting your most valuable or most regulated data, and use standard storage where the additional isolation would not change your risk meaningfully. Making that decision deliberately, rather than defaulting everything to one extreme, is what keeps both your security and your spend sensible, and it is the same proportionality that runs through our optimization work.

Bringing it together

Vault is where the real security work of encryption happens, because encryption only protects data when the keys behind it are controlled, rotated, and recoverable. Centralise keys and secrets, choose customer managed keys for sensitive data, separate the right to manage a key from the right to use it, plan rotation, and treat deletion with great care. Pull credentials out of code and into Vault so they are governed and recorded rather than scattered and leaking. The encryption side sits in our data encryption guide, the wider model is in our complete security guide, and our IAM and security practice builds and operates this for clients.