Managing Vault Secrets
Create and manage vault secrets, secret tags, and secret rules.
Oracle Cloud Infrastructure Secret Management lets you to effortlessly protect sensitive data such as API keys, passwords, and encryption keys by using secrets. It offers a robust solution to create, store, manage, and access these secrets securely. The centralized storage it provides leverages the hardware security modules (HSMs) and granular access control to safegaurd the security and integrity of critical information. Use OCI Secret Management to eliminate embedding secrets directly in applications and reduce the attack surface and strengthen an application's overall security.
Automatic Secret Generation and Rotation
Automatic Secret Generation and Automatic Secret Rotation features in OCI Secret Management eliminates the manual burden of using scripts to manage the secrets creation and rotation. Using the OCI Console and APIs, efficiently create and manage a secret's lifecycle from creation to rotation and deletion thereby enhancing security and operational efficiency.
With Automatic Secret Generation, let OCI Secret Management to automatically generate secrets on your behalf with a few simple steps. Automatic Secret Generation supports three types of secret generation types such as passwords, SSH keys, and random bytes. For more information, see Creating a Secret in a Vault.
With Automatic Secret Rotation, enable auto rotation of secrets to set up secrets rotation interval from one month to 12 months and periodically rotate the secrets. This feature integrates with Autonomous Database (ADB) and OCI Functions to seamlessly rotate secrets used in ADB or a function code. When Automatic Secret Rotation is enabled, the applications begin using the new secret immediately. In OCI Functions, you can easily rotate any credential and execute code as part of the rotation process. Automatic rotation is also available for manually created secrets. To rotate secrets of your database using the pre-built functions in OCI Functions, see Database Secret Rotation without Wallet Function and Database Secret Rotation with Wallet Function.
Secret Versions and Rotation States
Learn about vault secret versions, rotation states, and the impact of secret version limitation.
Understanding vault secret versions and rotation states will help you track and manage secret contents to stay in compliance with any limits, rotation or other rules, or regulations.
For a basic definition of secret concepts, including secret versions and rotation states, see Key and Secret Management Concepts. For information about working with secret versions, see Managing Vault Secrets.
Rotation States
Secret versions can have more than one rotation state at a time. Where only one secret version exists, such as when you first create a secret, the secret version is automatically marked as both 'current' and the 'latest'. The 'latest' version of a secret contains the secret contents that were last uploaded to the vault, in case you want to keep track of that.
When you rotate a secret to upload new secret contents, you can mark it as 'pending'. Marking a secret version's rotation state as 'pending' lets you upload the secret contents to the vault without immediately putting them into active use. You can continue using the 'current' secret version until you're ready to promote a pending secret version to 'current' status. This typically happens after you have rotated credentials on the target resource or service first. You don't want to unexpectedly change a secret version. Changing what secret version is current prevents the application that needs it from retrieving the expected secret version from the vault.
For the purposes of rolling back to a previous version easily, such as when you've made a mistake in updating the secret contents or when you've restored a backup of an older resource and need to resume using older secret contents, secret versions can also be marked as 'previous.' A secret version marked as 'previous' was previously a secret version marked as 'current.' To roll back to a previous version, you update the secret to specify the secret version number you want.
As long as a secret version hasn't been deleted, you can update the secret to use that past secret version. When you update the secret, the secret version number you choose gets marked as 'current.' This has the same effect as promoting a secret version to 'current.'
You can only delete secret versions that have been marked as 'deprecated.' A deprecated secret version is one that's not marked as 'current,' 'pending,' or 'previous.' This helps to prevent circumstances where you might delete a secret version that you need later (for example, when restoring a database you backed up previously). A secret version that's marked as anything other than 'deprecated' can be marked as 'current' to return it to active use.
Version Limitation
The limits on secret versions applies to both a secret's versions that are in use and versions that are deprecated, including those that have been scheduled for deletion. For information about limits on the number of versions for a given secret and for secret versions in a tenancy, see Service Limits.
Before You Begin
Before you begin, we recommend that you first read Secret Rules and Secret Versions and Rotation States to better understand the implications of working with rules, secret versions, and secret version rotation states.
Required IAM Policy
To use Oracle Cloud Infrastructure, you must be granted security access in a policy by an administrator. This access is required whether you're using the Console or the REST API with an SDK, CLI, or other tool. If you get a message that you don’t have permission or are unauthorized, verify with your administrator what type of access you have and which compartment to work in.
For administrators:
- The policy Let security admins manage vaults, keys, and secrets lets the specified group do everything with vaults, keys, and secrets.
- The policy Create a policy to enable encryption keys lets the specified group do everything with secrets in a specific vault.
- The policy Let users read, update, and rotate all secrets lets the specified group read, update, and rotate all secrets in any vault in the tenancy.
- For more information about permissions or if you need to write more restrictive policies for secrets, see Details for the Vault Service.
If you're new to policies, see Getting Started with Policies and Common Policies.
Tagging Resources
Apply tags to your resources to help organize them according to your business needs. Apply tags at the time you create a resource, or update the resource later with the wanted tags. For general information about applying tags, see Resource Tags.
Monitoring Resources
You can monitor the health, capacity, and performance of your Oracle Cloud Infrastructure resources by using metrics, alarms, and notifications. For more information, see Monitoring and Notifications.
Moving Resources to a Different Compartment
You can move secrets from one compartment to another. After you move a secret to a new compartment, inherent policies apply immediately and affect access to the secret and secret versions. Moving a secret doesn't affect access to the vault that a secret is associated with. Similarly, you can move a vault from one compartment to another independently of moving any of its secrets. For more information, see Managing Compartments.