Key Management
Key Management Service is an OCI service that stores and manages keys for secure access to resources.
The Oracle Cloud Infrastructure (OCI) Key Management Service (KMS) is a cloud-based service that provides centralized management and control of encryption keys for data stored in OCI.
OCI KMS has the following capabilities:
- Simplifies key management by centrally storing and managing encryption keys.
- Protect data at rest and in transit by supporting various encryption key types, including symmetric keys and, asymmetric keys.
- Address security and compliance requirements by giving you more control for Bring Your Own Keys (BYOK) to OCI, create them in OCI, or Hold Your Own Keys (HYOK) external to OCI. You can also use FIPS 140-2 Level 3-certified hardware security modules (HSMs) to store and protect your encryption keys.
- Integrate encryption with other OCI services such as storage, database, Fusion Applications for protecting data stored in these services.
Key and Secret Management Concepts
Understand Vault and key management concepts for accessing and managing Vault, keys, and Secrets.
- Vaults
- Vaults are logical entities where Vault service creates and durably stores vault keys and secrets. The type of vault you have determines features and functionality such as degrees of storage isolation, access to management and encryption, scalability, and the ability to back up. The type of vault you have also affects pricing. You cannot change a vault's type after you create the vault.
- Keys
- Keys are logical entities that represent one or more key versions, each of which contains cryptographic material. A vault key's cryptographic material is generated for a specific algorithm that lets you use the key for encryption or in digital signing. When used for encryption, a key or key pair encrypts and decrypts data, protecting the data where the data is stored or while the data is in transit. With an AES symmetric key, the same key encrypts and decrypts data. With an RSA asymmetric key, the public key encrypts data and the private key decrypts data.
- Key Versions & Rotations
- Each vault master encryption key is automatically assigned a key version. When you rotate a key, the Vault service generates a new key version. The Vault service can generate the key material for the new key version or you can import your own key material.
- Automatic Key Rotation
-
OCI Key Management Service enables you to automatically schedule key rotation. A rotation schedule defines the frequency of rotation for an encryption key (in Enabled state) and the start date of the rotation schedule. When you schedule automatic rotation, you can define the key rotation schedule ranging between 60 days and 365 days. KMS supports automatic key rotation for both HSM and software keys and this applicable for both symmetric and asymmetric keys.Note
This feature is available only for private vaults.Salient features of automatic key rotation are:- Allows you to enable or update auto key rotation schedules for keys.
- Ability to track automatic key rotation activities such as auto rotation status, periodic key rotation update, last successful rotation status, or next rotation start date at the granularity of a Key.
- Ability to rotate keys on-demand (manual operation) irrespective of auto key rotation is enabled or disabled.
- Send event notification when key rotation fails because of issues such as tenant capacity limitation, key or vault in incorrect state and so forth.
Auto rotation event notification:KMS sends out auto ley rotation status notification. To receive these notifications, you must configure the OCI Events service. After every key rotation, KMS sends out a notification about the rotation status and error messages, if any. The OCI Events service allows you to attach an Oracle function to run any custom logic for re-encrypting data with a new key version followed by the deletion of old key version or distributing the public portion of asymmetric keys for sigining or verifying data.
- HARDWARE SECURITY MODULES
- When you create an AES symmetric master encryption key with the protection mode set to HSM, the Vault service stores the key version within a hardware security module (HSM) to provide a layer of physical security. (When you create a secret, secret versions are base64-encoded and encrypted by a master encryption key, but are not stored within the HSM.) After you create the resources, the service maintains copies of any given key version or secret version within the service infrastructure to provide resilience against hardware failures. Key versions of HSM-protected keys are not otherwise stored anywhere else and cannot be exported from an HSM.
- ENVELOPE ENCRYPTION
- The data encryption key used to encrypt your data is, itself, encrypted with a master encryption key. This concept is known as envelope encryption. Oracle Cloud Infrastructure services do not have access to the plaintext data without interacting with the Vault service and without access to the master encryption key that is protected by Oracle Cloud Infrastructure Identity and Access Management (IAM). For decryption purposes, integrated services like Object Storage, Block Volume, and File Storage store only the encrypted form of the data encryption key.
- SECRETS
- Secrets are credentials such as passwords, certificates, SSH keys, or authentication tokens that you use with Oracle Cloud Infrastructure services. Storing secrets in a vault provides greater security than you might achieve storing them elsewhere, such as in code or configuration files. You can retrieve secrets from the Vault service when you need them to access resources or other services.
- SECRET VERSIONS
- Each secret is automatically assigned a secret version. When you rotate secret, you provide new secret contents to the Vault service to generate a new secret version. Periodically rotating secret contents reduces the impact in case a secret is exposed. A secret’s unique, Oracle-assigned identifier, called an Oracle Cloud ID (OCID), remains the same across rotations, but the secret version lets the Vault service rotate secret contents to meet any rules or compliance requirements you might have. Although you can't use an older secret version's contents after you rotate it if you have a rule configured preventing secret reuse, the secret version remains available and is marked with a rotation state other than "current". For more information about secret versions and their rotation states, see Secret Versions and Rotation States.
- SECRET BUNDLES
- A vault secret bundle consists of the secret contents, properties of the secret and secret version (such as version number or rotation state), and user-provided contextual metadata for the secret. When you rotate a secret, you create a new secret version, which also includes a new secret bundle version.
Regions and Availability Domains
The Vault service is available in all Oracle Cloud Infrastructure commercial regions. See About Regions and Availability Domains for the list of available regions, along with associated locations, region identifiers, region keys, and availability domains.
Unlike some Oracle Cloud Infrastructure services, however, the Vault service does not have one regional endpoint for all API operations. The service has one regional endpoint for the provisioning service that handles create, update, and list operations for vaults. For create, update, and list operations for keys, service endpoints are distributed across multiple independent clusters. Service endpoints for secrets are distributed further still across different independent clusters.
Because the Vault service has public endpoints, you can directly use data encryption keys generated by the service for cryptographic operations in your applications. However, if you want to use master encryption keys with a service that has integrated with Vault, you can do so only when the service and the vault that holds the key both exist within the same region. Different endpoints exist for key management operations, key cryptographic operations, secret management operations, and secret retrieval operations. For more information, see Oracle Cloud Infrastructure API Documentation
The Vault service maintains copies of vaults and their contents to durably persist them and to make it possible for the Vault service to produce keys or secrets upon request, even when an availability domain is unavailable. This replication is independent of any cross-region replication that a customer might configure.
For regions with multiple availability domains, the Vault service maintains copies of encryption keys across all availability domains within the region. Regions with multiple availability domains have one rack for each availability domain, which means that the replication happens across three total racks in these regions, where each rack belongs to a different availability domain. In regions with a single availability domain, the Vault service maintains encryption key copies across fault domains.
For secrets, in regions with multiple availability domains, the Vault service distributes secret copies across two different availability domains. In regions with a single availability domain, the Vault service distributes the copies across two different fault domains.
Every availability domain has three fault domains. Fault domains help provide high availability and fault tolerance by making it possible for the Vault service to distribute resources across different physical hardware within a given availability domain. The physical hardware itself also has independent and redundant power supplies that prevent a power outage in one fault domain from affecting other fault domains.
All of this makes it possible for the Vault service to produce keys and secrets upon request, even when an availability domain is unavailable in a region with multiple availability domains or when a fault domain is unavailable in a region with a single availability domain.
Private Access to Vault
The Vault service supports private access from Oracle Cloud Infrastructure resources in a virtual cloud network (VCN) through a service gateway. Setting up and using a service gateway on a VCN lets resources (such as the instances that your encrypted volumes are attached to) access public Oracle Cloud Infrastructure services such as the Vault service without exposing them to the public internet. No internet gateway is required and resources can be in a private subnet and use only private IP addresses. For more information, see Access to Oracle Services: Service Gateway.
Resource Identifiers
The Vault service supports vaults, keys, and secrets as Oracle Cloud Infrastructure resources. Most types of Oracle Cloud Infrastructure resources have a unique, Oracle-assigned identifier called an Oracle Cloud ID (OCID). For information about the OCID format and other ways to identify your resources, see Resource Identifiers., see Resource Identifiers.
Ways to Access Oracle Cloud Infrastructure
You can access the Oracle Cloud Infrastructure by entering your cloud account.
You can access Oracle Cloud Infrastructure (OCI) by using the Console (a browser-based interface), REST API, or OCI CLI. Instructions for using the Console, API, and CLI are included in topics throughout this documentation. For a list of available SDKs, see Software Development Kits and Command Line Interface.
To access the Console, you must use a supported browser. To go to the Console sign-in page, open the navigation menu at the top of this page and click Infrastructure Console. You are prompted to enter your cloud tenant, your user name, and your password.
Authentication and Authorization
Each service in Oracle Cloud Infrastructure integrates with IAM for authentication and authorization, for all interfaces (the Console, SDK or CLI, and REST API).
An administrator in your organization needs to set up groups , compartments , and policies that control which users can access which services, which resources, and the type of access. For example, the policies control who can create new users, create and manage the cloud network, launch instances, create buckets, download objects, and so on. For more information, see Getting Started with Policies. For specific details about writing policies for each of the different services, see Policy Reference.
If you're a regular user (not an administrator) who needs to use the Oracle Cloud Infrastructure resources that your company owns, contact your administrator to set up a user ID for you. The administrator can confirm which compartment or compartments you should be using.
Limits on Vault Resources
Know the Vault Service limitation and its resource usage before you begin to use them.
For a list of applicable limits and instructions for requesting a limit increase, see Service Limits. To set compartment-specific limits on a resource or resource family, administrators can use compartment quotas.
For instructions to view your usage level against the tenancy's resource limits, see Viewing Your Service Limits, Quotas, and Usage. You can also get each individual vault's usage against key limits by viewing key and key version counts in the vault details.