Skip to main content

More Info:

KMS keys should not be in a pending deletion or deleted state. Deleted keys cannot decrypt previously encrypted data, potentially causing permanent data loss.

Risk Level

Medium

Address

Compliance, Security

Compliance Standards

  • APRA CPS 234 (Australia)
  • AWS Well Architected Framework
  • BSI C5 (Germany)
  • Brazil LGPD
  • CCPA / CPRA (California)
  • CIS Critical Security Controls v8
  • CMMC 2.0
  • CSA Cloud Controls Matrix v4
  • DPDPA
  • Digital Operational Resilience Act (EU)
  • Essential 8
  • HIPAA
  • ISO/IEC 27017
  • ISO/IEC 27018
  • ISO/IEC 27701
  • KSA PDPL
  • MAS Technology Risk Management (Singapore)
  • MITRE ATT&CK (Cloud)
  • NIS2 Directive
  • NIST
  • NIST SP 800-171
  • NYDFS 23 NYCRR 500
  • SWIFT Customer Security Controls Framework
  • Sarbanes-Oxley IT General Controls
  • UK NCSC Cyber Assessment Framework

Triage and Remediation

Remediation

Using Console

To remediate “OCI Encryption KMS Keys Should Not Be Pending Deletion” using the OCI Console:
  1. Sign in and go to Key Management
    • Open the OCI Console.
    • From the top-left menu, go to: Identity & Security → Vault.
    • Select the compartment where your vault is located.
  2. Open the affected Vault
    • Click the Vault that contains the KMS key in “Pending deletion” state.
    • In the vault details page, go to the Keys tab.
  3. Locate keys in Pending Deletion
    • In the keys list, look at the Lifecycle state column.
    • Identify keys with state “Pending deletion”.
  4. Cancel key deletion
    • Click the name of the affected key.
    • On the key details page, click More Actions (or the action menu) and choose Cancel Deletion (or Cancel key deletion).
    • Confirm the cancellation in the dialog.
    The key’s lifecycle state should change back to Enabled (or Active) after cancellation.
  5. Verify encryption/monitoring configurations
    • Go to the OCI services using KMS (Block Volumes, Object Storage, Databases, Logging/Monitoring resources, etc.).
    • For critical resources, confirm:
      • They reference the restored key (if they were already using it), or
      • They use a different active key if you truly intend to decommission this one later.
  6. (Optional) Plan proper key rotation/deletion
    • If a key still needs to be retired:
      • Create a new key in the same vault.
      • Update all dependent resources to use the new key.
      • Only after confirming no dependencies, schedule the old key for deletion again.
This clears the “Pending Deletion” state for KMS keys required for OCI Encryption Monitoring and prevents service disruption.
Below are the concrete remediation steps using the OCI CLI to handle KMS keys that are in PENDING_DELETION and should not be.

1. Prerequisites

  1. Make sure OCI CLI is installed and configured:
  2. Ensure you have:
    • Permissions on the Vault and Keys (policy allowing MANAGE keys / MANAGE vaults as appropriate).
    • The compartment OCID where the vault/keys live.

2. Identify KMS Keys in PENDING_DELETION

First, list all keys in a given compartment and filter on PENDING_DELETION.If you know the vault OCID:
If you have multiple vaults and want to check all of them in a compartment:
Note the Key OCIDs you want to rescue.

3. Cancel Deletion for Keys That Should Not Be Deleted

For each key in PENDING_DELETION that you want to keep:
Explanation of --endpoint:
  • KMS operations require the vault management endpoint, not the generic region endpoint.
  • The above command dynamically fetches it from the vault.
You can confirm:
Lifecycle state should move from PENDING_DELETION to ENABLED or DISABLED depending on previous state.

4. Bulk Remediation (Optional)

To automatically cancel deletion for all keys in PENDING_DELETION in a compartment:
Use this only if you are sure every PENDING_DELETION key should be rescued.

5. (Optional) Monitoring via CLI Script

To periodically check and alert on keys in PENDING_DELETION using a simple CLI script (for cron or an automation server):
You can then:
  • Run via cron and alert if OUTPUT is non-empty.
  • Or parse OUTPUT and integrate with your monitoring system.

If you share whether you want automatic cancellation vs just detection/alerting, I can refine the exact CLI/cron or shell script pattern.
Below is how to (1) detect KMS keys in PENDING_DELETION state and (2) optionally cancel their deletion, using Python and the OCI SDK.

1. Prerequisites

  1. Install OCI Python SDK:
  2. Configure OCI CLI config (if not already):
    This creates ~/.oci/config with:
    • tenancy
    • user
    • fingerprint
    • key_file
    • region
  3. Ensure the user has permissions like:
    (You only need manage if you want to cancel deletion.)

2. Python: List Keys Pending Deletion (Monitoring)

This script lists all KMS keys in PENDING_DELETION in a given compartment and vault. You can wire it to cron / a scheduler or a monitoring system.
Use this for monitoring:
  • Feed output to a log/alerting system (e.g., send email/Slack if list not empty).
  • Run periodically (cron, OCI Functions, etc.).

3. Python: Cancel Deletion for Keys (Remediation)

If you want to automatically remediate by cancelling deletion for all such keys:

  1. Monitoring script: Run periodically to detect keys in PENDING_DELETION.
  2. Alert first: Prefer to notify a security/ops team rather than auto-restore, for change control.
  3. Optional auto-remediation: Use the cancel_key_deletion script in a controlled environment, with logging and approvals if required.
If you share your vault/compartment structure, I can adapt the code to loop through all vaults and compartments automatically.
terraform plan will only show normal create/update/destroy operations for oci_kms_key resources that Terraform already manages; it will not (and cannot) show cancellation of a pending key deletion, since that operation is not exposed via the Terraform provider.