Overview

Oracle Cloud Infrastructure (OCI) customers often need to separate operational ownership from key ownership. A common example is an independent software vendor (ISV) that runs storage resources in its own tenancy while a customer retains control of the encryption keys in a separate tenancy.

This article describes how to configure cross-tenancy access so storage resources in one OCI tenancy can be encrypted with a Vault key that resides in another OCI tenancy. The same pattern can be used for Object Storage buckets and Block Volume resources, provided the service and key are in the same region.

Scenario

In this example:

• Company A is an ISV or service provider. They host and operate storage resources in their OCI tenancy.
• Customer B consumes services hosted by Company A and wants to retain ownership of the encryption key.
• Company A has an administrator group that manages the storage resources used for Customer B.
• Customer B creates and owns the Vault key that will be used to encrypt those storage resources.

The goal is to allow Company A’s storage administrators to associate Customer B’s Vault key with storage resources managed in Company A’s tenancy, while Customer B continues to control the key lifecycle in its own tenancy.

Reference Values

Prerequisites

1. The identity domain in Company A’s tenancy that contains the StorageAdminTeam group is replicated to the target region where access is being granted.
2. The storage resources and the Vault key are in the same OCI region. This helps avoid regional dependency and latency issues.
3. Both Company A and Customer B are subscribed to the region where the storage resources and key will be used.
4. Cross-Tenancy OCI KMS Key Access Page 14 Customer B has created the Vault key and captured the key OCID.
5. Company A has identified the compartment that contains the storage resources to be encrypted with Customer B’s key.

Policies in Company A’s Tenancy

Company A’s tenancy is the source tenancy from a cross-tenancy policy perspective. These policies endorse company A’s storage administrator group to use and associate keys in Customer B’s tenancy.

Define tenancy TenancyB as <CustomerB_Tenancy_OCID>
Endorse group StorageAdminTeam to use key-delegate in tenancy TenancyB
Endorse group StorageAdminTeam to use keys in tenancy TenancyB
Endorse group StorageAdminTeam to associate buckets in compartment <CustomerBCompartmentOCID> with keys in tenancy TenancyB
Endorse group StorageAdminTeam to associate volumes in compartment <CustomerBCompartmentOCID> with keys in tenancy TenancyB

Policies in Customer B’s Tenancy

Customer B’s tenancy is the target tenancy from a cross-tenancy policy perspective. These policies admit company A’s administrator group and allow the regional Object Storage service and block storage service to use the specified key. For example, if the resources are in the San Jose region, the Object Storage service principal is: objectstorage-us-sanjose-1

Define tenancy TenancyA as <CustomerA_Tenancy_OCID>
Define group StorageAdminTeam as <StorageAdminTeamGroupOCIDFromTenancyA>
Admit group StorageAdminTeam of tenancy TenancyA to use key-delegate in tenancy
Admit group StorageAdminTeam of tenancy TenancyA to read keys in tenancy
Allow service objectstorage-<region_identifier> to use keys in tenancy where target.key.id = '<Kms_Key_Id>'
Allow service blockstorage to use keys in tenancy where target.key.id = '<Kms_Key_Id>'
Admit group StorageAdminTeam of tenancy TenancyA to associate keys in tenancy with buckets in tenancy TenancyA
Admit group StorageAdminTeam of tenancy TenancyA to associate keys in tenancy with volumes in tenancy TenancyA

Implementation Options

After the cross-tenancy policies are in place, Company A can provide Customer B’s key OCID when creating or updating supported storage resources.

Terraform for Object Storage

The OCI Terraform provider supports the kms_key_id argument on the oci_objectstorage_bucket resource. When the policies above are configured, the value can be the OCID of the Vault key from Customer B’s tenancy.
Reference: https://registry.terraform.io/providers/oracle/oci/latest/docs/resources/objectstorage_bucket

resource "oci_objectstorage_bucket" "customer_bucket" {
    compartment_id = var.compartment_ocid
    namespace = var.object_storage_namespace
    name = var.bucket_name
    kms_key_id = var.kms_key_id
}

Terraform for Block Volumes

OCI block volume provisioning also supports specifying a KMS key OCID. With the cross-tenancy IAM policies in place, Company A can provide the key OCID from Customer B’s tenancy when provisioning encrypted volumes.
Reference: https://registry.terraform.io/providers/oracle/oci/latest/docs/data-sources/core_volumes

OCI CLI for Object Storage and Block Volume

To update an existing Object Storage bucket and Block Volume with Customer B’s KMS key, use the OCI CLI:

oci os bucket update --bucket-name "$BucketName" --kms-key-id "$Kms_Key_Id"
oci bv volume-kms-key update --volume-id "$Volume_Id" --kms-key-id "$Kms_Key_Id"
oci bv boot-volume-kms-key update --boot-volume-id "$Boot_Volume_Id" 
--kms-key-id "$Kms_Key_Id"

The command succeeds only when the endorsement and admission policies allow the caller and the regional Object Storage service to use the specified key.

Operational Notes

• Keep key ownership and storage administration responsibilities clearly separated. Customer B owns the key, while Company A operates the storage resources.
• Scope policies as narrowly as possible. Use specific compartments, groups, and key OCIDs wherever practical.
• Validate the region-specific Object Storage service principal before applying the policy.
• Test the configuration with a non-production bucket or volume before applying it to production workloads.
• Document the operational process for key rotation, key disablement, and incident response, because actions in Customer B’s tenancy can affect encrypted storage resources in Company A’s tenancy.

Summary

Cross-tenancy policies in OCI make it possible to support customer-controlled encryption keys across tenancy boundaries. With the right endorsement and admission policies, an ISV can operate storage resources in its own tenancy while allowing the customer to retain control of the KMS key used for encryption.
This design is especially useful when customers require stronger control over key ownership, compliance boundaries, or separation of duties, while still consuming a managed service hosted by another OCI customer.