Rules for Secrets
Support for secrets is not available in Oracle Cloud Infrastructure Government Cloud realms.
This topic explains how the rules you configure for secrets govern their usage. Configuring rules for secrets can help you meet compliance requirements. For information about how to configure or view rules, see Managing Secrets.
When you create a secret, you can configure the following types of rules:
- Secret Reuse Rule. This type of rule prevents the reuse of secret contents across different versions of a secret.
- Secret Expiry Rule. This type of rule restricts how long the secret contents of a particular secret version can remain in use. This rule can also block the retrieval of secret contents for a secret or secret version past the configured expiration date.
You might want to configure either or both of these secret rules to establish best practices around security. You can improve your security posture by acting on secrets that don’t adhere to the rules or, in the case of expiry rules, are in danger of violating them in due time.
Secrets are protected at rest with the encryption guarantees of a Federal Information Processing Standards (FIPS) 140-2 Security Level 3 security certification-compliant hardware security module (HSM) that backs the vault where the secret is created and stored. However, while in application memory, a secret could be compromised. Preventing the reuse of secret contents by multiple secret versions serves to limit the scope of affected resources in the event of a security breach involving the stored credentials. When only one resource uses the secret contents of a secret version, that resource is the only one that can be impacted. You can deprecate a secret version and then delete it if you find out you can no longer safely use its secret contents. You can choose whether secret reuse rules apply even to deleted secret versions.
Similarly, configuring an expiry rule to specify a time range for how long a secret version can exist also helps limit the impact of a potential security breach. The longer that a set of credentials are used, the more time an attacker has to try to access or decipher them. Frequently updating a secret with new secret contents helps keep credentials safer from users with malicious intent. Or, it at least makes shorter the period of time during which compromised credentials can unknowingly be used or disseminated. You can configure a secret version to expire after 1 to 90 days, but the secret can also have an absolute expiration date and time ranging from 1 to 365 days after its creation date. You can configure either of these values or both. You can also decide whether the secret contents are blocked past the expiration date.
The timer for a secret’s expiry rule resets according to the configured interval. No mechanism exists to update the secret contents. You must rotate the secret version manually.