Overview

Data security in Oracle Container Engine for Kubernetes (OKE) involves two distinct protection surfaces: data at rest (stored on persistent volumes) and data in transit (moving between compute instances and storage services). OKE integrates with two primary storage services — OCI Block Volume and OCI File Storage — each offering configurable encryption options for both surfaces.

This document provides a structured reference for configuring encryption in both services, covering the relevant properties, their interactions, IAM policy requirements, and step-by-step provisioning workflows for Kubernetes Persistent Volume Claims (PVCs).

Block Volume Encryption

All OCI Block Volumes and their backups are encrypted at rest by default using AES-256 encryption. Unless overridden, Oracle provides and manages the encryption keys. Operators may substitute their own keys using the OCI Vault service, and may additionally enable encryption for data moving between instances and block volumes over OCI’s internal network.

Encryption Configuration Properties

Block volume encryption in OKE is governed by three properties, each set at a different layer of the Kubernetes and OCI configuration stack:

Figure 1 — Block Volume Encryption: Configuration Properties

Property	Set In	Allowed Values
kms-key-id	Kubernetes StorageClass definition	OCID of a Vault master encryption key, or omitted (Oracle-managed)
attachment-type	Kubernetes StorageClass definition	paravirtualized  |  iSCSI
isPVEncryptionInTransitEnabled	Node pool configuration	true  |  false  (via CLI, API, or OCI Console)

kms-key-id

Set in the Kubernetes StorageClass definition. Provide the OCID of a master encryption key from the OCI Vault service to use customer-managed encryption. If omitted, Oracle-managed keys are used automatically.

attachment-type

Set in the Kubernetes StorageClass definition. Controls how the block volume is attached to the compute instance. Valid values are paravirtualized and iSCSI. This choice has a direct effect on in-transit encryption availability — in-transit encryption is only supported with paravirtualized attachments.

isPVEncryptionInTransitEnabled

Set at the node pool level, not in the StorageClass. Enables or disables in-transit encryption for all PVCs on that node pool. This property can be configured via the OCI CLI, REST API, or the OCI Console (navigate to the node pool → Edit → Boot Volume section → Use In-Transit Encryption checkbox).

Encryption Behavior Matrix

The combination of these three properties determines the resulting encryption behaviour. The following matrix documents all valid and invalid combinations:

Figure 2 — Block Volume Encryption: Property Interaction Matrix

In-Transit Enabled	Attachment Type	kms-key-id	Data at REST Encryption	In-Transit Encryption
true	paravirtualized	OCID of user-managed key	User-managed key	User-managed key
true	paravirtualized	Not set	Oracle-managed key	Oracle-managed key
true	iSCSI	OCID set  OR  not set	ERROR	ERROR — use paravirtualized with in-transit enabled
false	paravirtualized	OCID of user-managed key	User-managed key	Not available
false	paravirtualized	Not set	Oracle-managed key	Not available
false	iSCSI	OCID of user-managed key	User-managed key	Not available
false	iSCSI	Not set	Oracle-managed key	Not available

Critical Rule In-transit encryption (isPVEncryptionInTransitEnabled = true) requires attachment-type to be set to paravirtualized. Specifying iSCSI with in-transit encryption enabled will result in an error regardless of whether a kms-key-id is provided. Whenever in-transit encryption is not enabled (false), no in-transit encryption is available for either attachment type.

PVC Provisioning Paths

Depending on whether Oracle-managed or customer-managed encryption keys are required, the PVC provisioning workflow differs. The table below summarises the key steps and differences between the two paths:

Figure 3 — Block Volume PVC Provisioning: Oracle-Managed vs. Customer-Managed Keys

Step / Property	Oracle-Managed Keys	User-Managed Keys (Vault)
Pre-requisite	None	Create master encryption key in OCI Vault + configure IAM policy
StorageClass provisioner	blockvolume.csi.oraclecloud.com	blockvolume.csi.oraclecloud.com
attachment-type	paravirtualized	paravirtualized
kms-key-id	Omit — Oracle keys used automatically	Set to OCID of Vault master encryption key
isPVEncryptionInTransitEnabled	Set to true on each node pool (CLI / API / Console)	Set to true on each node pool (CLI / API / Console)

Path A — Oracle-Managed Keys

This is the simpler path and requires no pre-configuration in OCI Vault.

1. Define a Kubernetes StorageClass with provisioner: blockvolume.csi.oraclecloud.com and attachment-type: paravirtualized. Do not include a kms-key-id entry.
2. Create a PVC referencing the StorageClass.
3. On each relevant node pool, enable isPVEncryptionInTransitEnabled via CLI, API, or Console.

# Example StorageClass (Oracle-managed keys) apiVersion: storage.k8s.io/v1 kind: StorageClass metadata:   name: oci-bv-oracle-managed provisioner: blockvolume.csi.oraclecloud.com parameters:   attachment-type: paravirtualized reclaimPolicy: Delete volumeBindingMode: WaitForFirstConsumer

Path B — Customer-Managed Keys (OCI Vault)

This path requires upfront configuration of an encryption key in OCI Vault and an appropriate IAM policy before provisioning the PVC.

• Create a master encryption key in OCI Vault, or obtain the OCID of an existing key.
• Create an IAM policy granting the OKE cluster access to the master encryption key.
• Define a Kubernetes StorageClass with provisioner: blockvolume.csi.oraclecloud.com, attachment-type: paravirtualized, and kms-key-id set to the OCID of the Vault key.
• Create a PVC referencing the StorageClass.
• On each relevant node pool, enable isPVEncryptionInTransitEnabled.

# Example StorageClass (Customer-managed key from Vault) apiVersion: storage.k8s.io/v1 kind: StorageClass metadata:   name: oci-bv-customer-managed provisioner: blockvolume.csi.oraclecloud.com parameters:   attachment-type: paravirtualized   kms-key-id: ocid1.key.oc1.<region>.<vault_id>.<key_id> reclaimPolicy: Delete volumeBindingMode: WaitForFirstConsumer

File Storage Service Encryption

The OCI File Storage Service (FSS) similarly supports encryption for both data at rest and data in transit when used to back Kubernetes Persistent Volume Claims. The default behaviour encrypts data at rest using Oracle-managed keys automatically. Operators may substitute customer-managed keys from OCI Vault.

In-transit encryption, when enabled, is always performed using Oracle-managed TLS certificates — regardless of which key type is used for at-rest encryption.

  Encryption Options Summary

Figure 4 — File Storage Service: Encryption Options

Dimension	Oracle-Managed Keys	Customer-Managed Keys (Vault)
At-rest encryption	Always enabled by default	Enabled — key OCID set in StorageClass
Key source	Oracle internal keys	OCI Vault master encryption key
StorageClass param	KMS key OCID — omit	kmsKeyOCID — set to MEK OCID
IAM policy required	None	Yes — FSS service & cluster delegation policies
In-transit encryption	Optional — Oracle-managed TLS cert	Optional — Oracle-managed TLS cert
In-transit key source	Oracle TLS cert (irrespective of at-rest key choice)	Oracle TLS cert (irrespective of at-rest key choice)

IAM Policy Requirements for Customer-Managed Keys

When using customer-managed encryption keys with the File Storage Service in OKE, two IAM policies must be in place before provisioning any PVC. These policies grant the FSS service and the Kubernetes cluster the necessary permissions to access and delegate the master encryption key:

Figure 5 — File Storage Service: Required IAM Policies for Customer-Managed Keys

Policy	Purpose	Policy Statement Template
FSS Service Key Access	Allows the File Storage service principal to use the specified master encryption key.	allow service FSS <realm_key_prod> to use keys in compartment <compartment_name> where target.key.id = ‘<key_OCID>’
Cluster Key Delegation	Allows Kubernetes clusters to use key delegates within the compartment containing the master encryption key.	allow any-user to use key-delegates in compartment <compartment_name> where all {request.principal.type = ‘cluster’, target.key.id = ‘<key_OCID>’}

Note on FSS Realm The name of the File Storage service principal (e.g. FSS realm_key_prod) varies depending on the OCI realm your region belongs to. Consult the OCI Regions and Availability Domains documentation to confirm the correct service principal name for your region before writing these policies.

Provisioning a PVC on a Dynamically Created File System

When using the CSI volume plugin to dynamically create a new file system for a PVC, the encryption method is determined at file system creation time and reflected in the StorageClass definition.

Oracle-Managed Keys

No additional prerequisites are required. The file system is automatically encrypted at rest using Oracle-managed keys.

• In the OCI File Storage service console, create a new file system and select Encrypt Using Oracle-Managed Keys under the encryption settings.
• Define a Kubernetes StorageClass that does not include the kmsKeyOCID parameter. Oracle’s default encryption is applied automatically.
• Create a PVC referencing the StorageClass.

Customer-Managed Keys (OCI Vault)

Ensure that the IAM policies described in Section 3.2 are in place before proceeding.

1. In the OCI File Storage service console, create a new file system and select Encrypt Using Customer-Managed Keys. Specify the Vault compartment, Vault, master encryption key compartment, and master encryption key (MEK).
2. Define a Kubernetes StorageClass that includes the kmsKeyOCID parameter set to the OCID of the master encryption key.
3. Create a PVC referencing the StorageClass.

# Example StorageClass (FSS — Customer-managed key) apiVersion: storage.k8s.io/v1 kind: StorageClass metadata:   name: oci-fss-customer-managed provisioner: fss.csi.oraclecloud.com parameters:   kmsKeyOCID: ocid1.key.oc1.<region>.<vault_id>.<key_id> reclaimPolicy: Retain

Summary

OKE provides comprehensive encryption controls for both Block Volume and File Storage persistent volumes. The key principles to carry forward are:

• All data at rest is always encrypted — the choice is between Oracle-managed and customer-managed keys, not between encrypted and unencrypted.
• In-transit encryption for Block Volume requires both isPVEncryptionInTransitEnabled = true on the node pool AND attachment-type = paravirtualized in the StorageClass. iSCSI is incompatible with in-transit encryption.
• In-transit encryption for File Storage uses Oracle-managed TLS certificates irrespective of the at-rest key choice.
• Customer-managed keys require an OCI Vault key and correctly configured IAM policies before any PVC is provisioned.
• Revoking (unassigning) a customer-managed key from a volume reverts encryption to Oracle-managed keys automatically.

Bottom Line For most workloads, Oracle-managed encryption provides strong, zero-configuration data protection. Customer-managed keys from OCI Vault are the appropriate choice when regulatory requirements, organisational policy, or contractual obligations mandate operator control over encryption key lifecycle — including the ability to revoke access to data by deleting or disabling the key.