More Info:
Boot volumes should be encrypted using Customer-Managed Keys (CMKs) to ensure operating system level data at rest is secured with keys controlled exclusively by your organizations security administratorsRisk Level
HighAddress
Compliance, SecurityCompliance 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
- HITRUST CSF
- ISO/IEC 27017
- ISO/IEC 27018
- ISO/IEC 27701
- KSA PDPL
- MAS Technology Risk Management (Singapore)
- MITRE ATT&CK (Cloud)
- NIS2 Directive
- NIST
- NIST CSF
- NIST SP 800-171
- NYDFS 23 NYCRR 500
- PCI
- SOC2
- SWIFT Customer Security Controls Framework
- Sarbanes-Oxley IT General Controls
- Securities and Exchange Board of India (SEBI) - Cloud Security Adoption Framework
- UK NCSC Cyber Assessment Framework
Triage and Remediation
- Remediation
Remediation
Using Console
Using Console
Here’s how to remediate “Boot Volumes Should Be Encrypted with Customer‑Managed Keys (CMKs)” using the OCI Console.
If you share your tenancy structure and how you’re monitoring (OCI Cloud Guard, Security Zones, or third-party CSPM), I can give a minimal, tailored checklist to verify this at scale.
1. Create a Vault and a Customer-Managed Key (CMK)
- In the OCI Console, open the navigation menu.
- Go to Identity & Security → Vault.
- Choose the compartment where you want the vault.
- Click Create vault:
- Name: e.g.,
boot-volume-vault - Vault type: Default or Virtual Private
- Click Create vault.
- Name: e.g.,
- After the vault is active, click it.
- Go to Master Encryption Keys → Create key:
- Protection mode: HSM or Software (per your policy)
- Key shape: key algorithm and length (e.g., AES-256)
- Name: e.g.,
boot-volume-cmk - Click Create key.
2. Ensure Block Storage Can Use the Key
If needed, add a policy so Block Volume can use the key (in the tenancy root or relevant compartment):- Go to Identity & Security → Policies.
- Choose the compartment where you manage policies (often root).
- Click Create policy or edit an existing one.
-
Add a statement like (adjust compartments/OCID as needed):
- Save the policy.
3. Use CMK for New Boot Volumes (Going Forward)
For all new compute instances / boot volumes:- Go to Compute → Instances → Create instance.
- Configure instance details as usual.
- In the Boot volume section:
- Expand Show advanced options.
- For Encryption, choose Encrypt using customer-managed keys.
- Select the Vault and Key you created (
boot-volume-vault/boot-volume-cmk).
- Complete instance creation.
4. Migrate Existing Boot Volumes to CMK Encryption
You cannot just “flip” the key on an existing boot volume; you must create a new boot volume encrypted with the CMK and then move the workload.4.1. Create a Backup of the Existing Boot Volume
- Go to Compute → Instances.
- Click the instance whose boot volume isn’t using a CMK.
- Under Resources, click Boot volume to open it (or note the boot volume name, then go to Block Storage → Boot volumes and open it).
- In the boot volume page, click Create backup:
- Name: e.g.,
bv-backup-cmk-migration-<date> - Click Create backup.
- Name: e.g.,
- Wait until the backup is in Available state.
4.2. Create a New Boot Volume from the Backup with CMK
- Go to Block Storage → Boot volume backups.
- Open the backup you just created.
- Click Create boot volume.
- In the dialog:
- Select Compartment (same as instance, typically).
- Under Encryption, choose Encrypt using customer-managed keys.
- Select your Vault and Key (
boot-volume-cmk).
- Click Create boot volume and wait until it becomes Available.
4.3. Replace the Old Boot Volume on the Instance
This requires some downtime.- Go to Compute → Instances and open the instance.
- Click Stop (graceful shutdown) and wait until the instance state is Stopped.
- Under Resources → Boot volume attachments, note the current attachment, then Detach the existing boot volume.
- Click Attach boot volume:
- Select the new CMK-encrypted boot volume.
- Attachment type: Paravirtualized or iSCSI as before.
- Device path: leave default unless you have a specific requirement.
- Save/attach it.
- Alternative:
- From Block Storage → Boot volumes, locate the new CMK-encrypted boot volume.
- Click Create instance from this boot volume.
- Configure the new instance to match the old one (shape, VCN/subnet, etc.).
- Redirect traffic (update DNS, load balancer backend set, or IPs) from old instance to new instance.
- Decommission the old instance and its non‑CMK boot volume when confirmed.
5. Clean Up and Confirm Compliance
- Once the instance is confirmed working on the new CMK-encrypted boot volume, delete the old non‑CMK boot volume and any unnecessary backups.
- To confirm:
- Go to Block Storage → Boot volumes, open the volume.
- Check the Encryption section; it should show the Customer-managed key and its OCID.
- Re-run your OCI Security/Compliance/Monitoring check (e.g., Cloud Guard target or external CSPM tool) and verify that:
- “Boot Volumes Should Be Encrypted with Customer-Managed Keys” is now passing for the compartment/tenancy.
If you share your tenancy structure and how you’re monitoring (OCI Cloud Guard, Security Zones, or third-party CSPM), I can give a minimal, tailored checklist to verify this at scale.
Using CLI
Using CLI
Below is a concise, step-by-step way to remediate “OCI Storage Boot Volumes Should Be Encrypted With Customer-Managed Keys” using the OCI CLI.Assumptions:
Note the If a suitable key exists, note its From the output, note
If using CLI to create the policy:Replace
For a given instance, get its boot volume attachment:From the output, note
This will re-encrypt the boot volume with the specified KMS CMK.Repeat for each non-compliant boot volume.
For instance configurations (used by Instance Pools), include
If it returns your
This sequence (create/identify CMK → grant Block Storage access → update boot-volume
- You already have
ociCLI configured with appropriate permissions. - You have (or will create) a Vault and a Key in OCI KMS.
1. Create (or identify) a Customer-Managed KMS Key
1.1 Find your vault
id of the vault you want to use.1.2 List keys in that vault
id (<KEY_OCID>).1.3 (Optional) Create a new key
"id" → this is your <KEY_OCID>.2. Ensure IAM Policy Lets Block Storage Use the Key
Create a policy in the key’s compartment (or root) so Block Volume service can use it:Example policy statement:<COMPARTMENT_NAME> accordingly.3. Identify Boot Volumes to Fix
List instances (optional):"bootVolumeId" → <BOOT_VOLUME_OCID>.You can also list all boot volumes directly:4. Reconfigure Boot Volume to Use Customer-Managed Key
You can update the boot volume to use the CMK:5. (Optional) Set CMK at Instance Launch / Instance Configuration
For new instances (to prevent future drift), use--kms-key-id at launch:kmsKeyId under instanceDetails -> blockVolumes or launchDetails depending on your template.6. Verify Encryption Status
Check the boot volume details:<KEY_OCID>, the boot volume is now encrypted with a customer-managed key.This sequence (create/identify CMK → grant Block Storage access → update boot-volume
kms-key-id) is what remediates the “OCI Storage Boot Volumes Should Be Encrypted With Customer-Managed Keys” finding using OCI CLI.Using Python
Using Python
Below is a step‑by‑step approach and example Python code to:
- Monitor OCI boot volumes for non‑compliance (not using customer-managed keys).
- Remediate by updating the boot volume to use a customer-managed KMS key (where supported).
1. Prerequisites
-
OCI CLI config set up on the machine where you’ll run Python:
~/.oci/configwith a profile that has:tenancyuserfingerprintkey_fileregion
-
Permissions for the principal used by the SDK:
- To manage block volumes and KMS keys:
- Adjust
SecOpsto your group and scoping as needed.
- To manage block volumes and KMS keys:
-
Customer‑Managed KMS Key already created in OCI Vault:
- Get the OCID of the key:
kms_key_id = "ocid1.key.oc1...." - Ensure the key is in the same region as your boot volumes.
- Get the OCID of the key:
2. High-Level Steps
- Identify compartments you want to monitor.
- For each compartment:
- List boot volumes.
- Check each boot volume’s
kms_key_id.
- Monitoring:
- Log/report volumes where
kms_key_idisNoneor not equal to your required key.
- Log/report volumes where
- Remediation:
- Call
UpdateBootVolumewithkms_key_idset to your customer-managed key. - Optionally, tag or log what was changed.
- Call
3. Python Example: Monitor & Remediate Boot Volume Encryption
Install SDK (if not already):3.1. Configuration
Adjust these values in the code:PROFILE_NAME– OCI CLI profile to use.TARGET_COMPARTMENT_IDS– list of compartment OCIDs to scan, or use the tenancy and list all.REQUIRED_KMS_KEY_ID– OCID of your customer-managed key.
3.2. Script
4. How to Use for “Monitoring” Only
- Keep
DRY_RUN = True. - Run on a schedule (e.g., cron or CI pipeline).
- Redirect output to logs or integrate with your logging/alerting:
- Parse the
Non-compliant boot volumes foundcount. - Trigger alerts when > 0.
- Parse the
5. To Enable Automatic Remediation
- Set
DRY_RUN = False. - Ensure IAM policies allow:
updateon boot volumes.useon the KMS key.
- Optionally:
- Add tagging in
UpdateBootVolumeDetailsto mark remediated resources.
- Add tagging in
Using Terraform
Using Terraform
OCID_OF_COMPARTMENT_FOR_KMS_VAULTwith the OCID of the compartment where the vault should live.OCID_OF_COMPARTMENT_FOR_KMS_KEYwith the OCID of the compartment for the key.AVAILABILITY_DOMAIN_NAMEwith the target availability domain (e.g.,"kIdk:PHX-AD-1").OCID_OF_BOOT_VOLUME_COMPARTMENTwith the boot volume’s compartment OCID.- Optional
source_details.idwith the OCID of the existing boot volume or backup you want to base this on.
kms_key_id on an existing oci_core_boot_volume typically forces replacement of the boot volume; this can cause an outage and data loss if you don’t coordinate creating/attaching a new boot volume and updating any instances that use it.Verification with terraform plan should show the boot volume either:- being newly created with
kms_key_id = oci_kms_key.BOOT_VOLUME_CMK.id, or - being replaced with the new resource having that
kms_key_idargument set.

