Configuring KMS-based encryption on an OpenShift cluster

InfoScale in containerized environments provides data-at-rest encryption for volumes and disk groups using an external Key Management Server (KMS). To enable this, administrators must establish a secure connection using a custom CA certificate, typically generated via tools like cfssl. This process involves creating a specific namespace and Kubernetes secret containing the CA, TLS certificate, and private key, which must be deployed on all involved clusters, including those configured for disaster recovery.

Once the CA infrastructure is established, InfoScale must be configured to communicate with a KMIP-compliant KMS. This requires deploying an infoscale-kmip-encrypt secret with server connection details and manually registering client certificates on the KMS to authorize the InfoScale cluster. For high-availability or multi-site configurations, client certificates from each site must be registered and grouped within the KMS to ensure consistent encryption management across the environment.

Maintenance of this security architecture requires proactive certificate management, as external CA certificates remain valid for 12 months, with renewal procedures recommended starting in the eighth month. Furthermore, client REST certificates must be renewed and re-uploaded to the KMS every three months to maintain continuous encryption. Failure to perform these renewals or update certificates after cluster reconfigurations will interrupt encryption services.