Auto-Encrypted DiskPools with KMS Integration

Explore this Page

• Overview
• Requirements
• Enable the External Secrets Dependency
• Configuring KMS Integration
• Link DataCore Puls8 to Your KMS
• Create an Auto-Encrypted DiskPool with KMS
• Using a New KMS Post-Installation
• Enabling KMS Post-Install for Existing DPC
• Disabling KMS Post-Installation for Existing DPC
• DPC with Local Storage Devices
• KMS Secret Naming Conventions
• Best Practices
• Benefits of Auto-Encrypted DiskPools with KMS Integration

Overview

The Auto-Encrypted DiskPools feature in DataCore Puls8 simplifies and secures storage encryption by automatically generating and backing up encryption keys.

With Key Management System (KMS) integration, DataCore Puls8 securely backs up these encryption keys to your organization’s KMS through the External Secrets Operator (ESO).

This automation eliminates manual key creation and reduces the risk of data loss from misplaced or unmanaged encryption keys.

Using KMS-backed DiskPools ensures consistent encryption management, secure key recovery, and enterprise-grade protection of persistent data.

This document explains how to:

• Enable KMS integration in DataCore Puls8
• Configure and link to your KMS provider
• Create auto-encrypted DiskPools with KMS backup
• Manage KMS settings post-installation

Requirements

Before configuring KMS integration, ensure the following requirements are met:

• DataCore Puls8 Installation: DataCore Puls8 must be installed on your Kubernetes cluster with Replicated PV Mayastor enabled. Refer to the Installing DataCore Puls8 documentation for installation steps.
• Helm CLI Access: You must have helm installed and configured with sufficient permissions to upgrade and modify DataCore Puls8 Helm chart values.
• ESO: The ESO must be available or installable in your cluster, as it facilitates KMS communication.

Enable the External Secrets Dependency

To enable KMS support, you must first enable the external-secrets dependency within the DataCore Puls8 Helm chart. This is controlled by the external-secrets.enabled Helm variable.

Example: Enable During Installation

helm install puls8 -n puls8 --create-namespace oci://docker.io/datacoresoftware/puls8 \
  --version <version> \
  --set external-secrets.enabled=true

Example: Enable Post Installation

helm upgrade puls8 -n puls8 --reset-then-reuse-values --version <current-version> \
  --set external-secrets.enabled=true

Ensure that the <current-version> is specified accurately. Omitting it will upgrade DataCore Puls8 to the latest version.

Configuring KMS Integration

You can configure additional Helm parameters to customize KMS integration behavior:

• Cluster Name: Use kms.clusterName to assign a cluster identifier, helping you distinguish secrets across multiple DataCore Puls8 clusters in your KMS. You can also control the secret naming structure by setting the kms.secretNameFormat variable to specify the separator (for example, / or —), depending on your KMS provider’s requirements.
• Annotations: Add metadata to secrets stored in KMS using the kms.annotations dictionary.

The supported separator format may vary depending on the KMS provider. DataCore has validated the following providers and configurations:

Other KMS providers may require specific naming formats or API compatibility adjustments. Contact DataCore Support if you plan to integrate with an unlisted or custom KMS provider for validation guidance.

Link DataCore Puls8 to Your KMS

Define a SecretStore CR provided by the ESO to connect DataCore Puls8 to your KMS. This CR holds the connection details to your external KMS.

Refer to the official External Secrets Operator documentation for supported KMS providers and connection syntax.

Create an Auto-Encrypted DiskPool with KMS

Once DataCore Puls8 is linked to your KMS, you can create an auto-encrypted DiskPool.

When encryption is enabled, DataCore Puls8 automatically generates keys, stores them locally, and synchronizes them with your KMS provider.

apiVersion: puls8.datacore.com/v1beta1
kind: DiskPoolClaim
metadata:
  name: dpc-1
  namespace: puls8
spec:
  encryption:
    enabled: true
  nodeName: kind-worker
  source:
    disk:
      uri: /dev/disk/by-id/xxxxx

The DiskPoolClaim (DPC) will not be created until the encryption secrets are successfully backed up to the linked KMS.

When the DPC is deleted, its corresponding encryption secrets are also removed from the KMS.

Using a New KMS Post-Installation

If you are switching to a different KMS provider after DataCore Puls8 installation and already have a SecretStore configured, you can modify the existing SecretStore to connect with the new KMS provider.

After the modification, the existing secrets are synchronized automatically within the refresh period (default: 6 hours). You can adjust this synchronization interval by modifying the Helm variable:

--set kms.eso.refreshPeriod=<duration>

To force immediate resynchronization:

kubectl -n puls8 annotate ps force-sync=$(date +%s) --all --overwrite

If you want to use a different SecretStore, modify the Helm variable as shown below:

kms.eso.secretStore.name=<new-secretstore-name>

In this case, you do not need to manually patch the secrets. Instead, ensure that the conditions described earlier (SecretStore configuration, KMS accessibility, and permissions) are met to allow successful synchronization.

Enabling KMS Post-Install for Existing DPC

If you already created auto-encrypted DiskPools before enabling KMS, you can enable KMS integration post-install. DataCore Puls8 automatically backs up existing encryption keys to the configured KMS.

You can verify synchronization status using the following DPC conditions:

"conditions": [
                    {
                        "lastTransitionTime": "2025-09-16T16:11:12Z",
                        "message": "",
                        "observedGeneration": 1,
                        "reason": "",
                        "status": "True",
                        "type": "KmsInSync"
                    },
                    {
                        "lastTransitionTime": "2025-09-16T16:11:12Z",
                        "message": "",
                        "observedGeneration": 1,
                        "reason": "",
                        "status": "True",
                        "type": "KmsSynced"
                    }
                ]

• Monitor KmsSynced: Indicates if secrets have been pushed to KMS.
• KmsInSync: Indicates if the DPC is actively synced with KMS.

Disabling KMS Post-Installation for Existing DPC

If you no longer wish to use KMS, follow these steps to disable it safely:

1. Update the Helm Chart to use the local secrets plugin.
   Copy

   Switch DataCore Puls8 KMS Plugin to Local Secrets

   helm upgrade puls8 -n puls8 --reset-then-reuse-values --version <current-version> \
     --set kms.plugin=local

2. Verify the external-secrets objects are removed.
   Copy

   Confirm Removal of external-secrets Objects

   kubectl -n puls8 get ps
   kubectl -n puls8 get es

3. Remove the external-secrets dependency (optional).
   Copy

   Disable the external-secrets Dependency After Removing KMS

   helm upgrade puls8 -n puls8 --reset-then-reuse-values --version <current-version> \
     --set external-secrets.enabled=false

   Disabling KMS does not delete secrets already stored in the KMS.

DPC with Local Storage Devices

The DPC Custom Resource (CR) supports direct use of local block devices. When processing a DPC, the operator validates the storage device and reports any configuration or device-related errors.

kubectl -n puls8 describe dpc pool-kind-worker

Name:         pool-kind-worker
Namespace:    puls8
API Version:  puls8.datacore.com/v1beta1
Kind:         DiskPoolClaim
Spec:
  Node Name:  kind-worker
  Source:
    Disk:
      Uri:  /dev/sdo
Events:
  Type     Reason      Age    From                    Message
  ----     ------      ----   ----                    -------
  Warning  DpcDiskUri  1m26s  puls8.datacore.com/dpc  disk /dev/sdo not found on node kind-worker

If the DPC encounters errors during validation, review the operator logs or the DPC events for detailed diagnostic information.

KMS Secret Naming Conventions

When using a remote KMS provider, DataCore Puls8 follows a standardized naming format for secrets, as shown below::

puls8/$clusterName/dpc-${dpcName}[-$timestamp]
or
puls8-$clusterName-dpc-${dpcName}[-$timestamp]

Where:

• $clusterName: Short identifier for the cluster (configured using kms.salt.clusterName). Defaults to global if unspecified.
• $dpcName: Name of the DPC CR.
• $timestamp: Optional ISO 8601 timestamp (YYYYMMDD). Required for certain KMS providers such as AWS. Set using kms.salt.timestamp=true.
• separator: Determines the separator (/ or -). Defaults to /. Configurable using kms.secretNameFormat.

Google Cloud Secret Manager does not support slashes (/) in secret names. When using this KMS provider, configure the separator to use a dash (-) instead.

You can retrieve the actual secret name stored in KMS from the DPC status. For example:

kubectl -n puls8 get dpc pool-kind-worker -ojson | jq '.status.encryption.auto.spec.kmsCfg.eso.remoteSecret'

"puls8-global-dpc-pool-kind-worker"

You may also add annotations to the Kubernetes secret data using the Helm variable kms.annotations, which accepts key-value pairs in dictionary form.

Best Practices

• Always back up DiskPool encryption keys to a secure location.
• Regularly validate that your KMS synchronization is healthy.
• Use unique cluster identifiers when managing multiple DataCore Puls8 environments.
• If you need to disable KMS integration for any reason, ensure that all encryption keys are safely backed up before proceeding.
• For sensitive environments, restrict KMS access to authorized roles only.

Benefits of Auto-Encrypted DiskPools with KMS Integration

• Data Protection: Ensures that all data written to disks is encrypted by default, preventing unauthorized access even if the underlying media is compromised.
• Centralized Key Management: Integrates with enterprise-grade KMS solutions for secure, centralized control of encryption keys.
• Simplified Security Operations: Eliminates the need for manual encryption handling or custom scripting, reducing administrative overhead.
• Operational Transparency: Encryption and decryption are handled seamlessly without impacting application performance or user workflows.

Learn More

• Creating a DiskPool
• Disk Emulation
• Supportability