Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

Ce contenu n'est pas disponible dans la langue sélectionnée.

Chapter 5. Security considerations

5.1. FIPS Cryptography
Copier lien

The Federal Information Processing Standard Publication 140-2/140-3 (FIPS 140-2/140-3) is a standard that defines a set of security requirements for the use of cryptographic modules. Law mandates this standard for the US government agencies and contractors and is also referenced in other international and industry specific standards.

Red Hat OpenShift Data Foundation is designed for FIPS. When running Red Hat Enterprise Linux (RHEL) or Red Hat Enterprise Linux CoreOS (RHCOS) booted in FIPS mode, OpenShift Container Platform core components, including OpenShift Data Foundation, use the RHEL cryptographic libraries that have been submitted to NIST for FIPS 140-2/140-3 Validation on only the x86_64, ppc64le, and s390x architectures. For more information, see the Support for FIPS cryptography section in OpenShift documentation.

Currently, the Cryptographic Module Validation Program (CMVP) processes the cryptography modules. You can see the state of these modules at Modules in Process List. For more up-to-date information, see the Red Hat Knowledgebase solution RHEL core crypto components.

5.2. Proxy environment
Copier lien

A proxy environment is a production environment that denies direct access to the internet and provides an available HTTP or HTTPS proxy instead. Red Hat Openshift Container Platform is configured to use a proxy by modifying the proxy object for existing clusters or by configuring the proxy settings in the install-config.yaml file for new clusters.

Red Hat supports deployment of OpenShift Data Foundation in proxy environments when OpenShift Container Platform has been configured according to configuring the cluster-wide proxy.

5.3. Data encryption options
Copier lien

Encryption lets you encode your data to make it impossible to read without the required encryption keys. This mechanism protects the confidentiality of your data in the event of a physical security breach that results in a physical media to escape your custody. The per-PV encryption also provides access protection from other namespaces inside the same OpenShift Container Platform cluster. Data is encrypted when it is written to the disk, and decrypted when it is read from the disk. Working with encrypted data might incur a small penalty to performance.

Encryption is only supported for new clusters deployed using Red Hat OpenShift Data Foundation 4.6 or higher. An existing encrypted cluster that is not using an external Key Management System (KMS) cannot be migrated to use an external KMS.

Previously, HashiCorp Vault was the only supported KMS for Cluster-wide and Persistent Volume encryptions. With OpenShift Data Foundation 4.7.0 and 4.7.1, only HashiCorp Vault Key/Value (KV) secret engine API, version 1 is supported. Starting with OpenShift Data Foundation 4.7.2, HashiCorp Vault KV secret engine API, versions 1 and 2 are supported. As of OpenShift Data Foundation 4.12, Thales CipherTrust Manager has been introduced as an additional supported KMS.

Important

Red Hat works with the technology partners to provide this documentation as a service to the customers. However, Red Hat does not provide support for the Hashicorp product. For technical assistance with this product, contact Hashicorp.

5.3.1. Cluster-wide encryption
Copier lien

Red Hat OpenShift Data Foundation supports cluster-wide encryption (encryption-at-rest) for all the disks and Multicloud Object Gateway operations in the storage cluster. OpenShift Data Foundation uses Linux Unified Key System (LUKS) version 2 based encryption with a key size of 512 bits and the aes-xts-plain64 cipher where each device has a different encryption key. The keys are stored using a Kubernetes Secret or an external KMS. Both methods are mutually exclusive and you can not migrate between methods.

Encryption is disabled by default for block and file storage. You can enable encryption for the cluster at the time of deployment. The MultiCloud Object Gateway supports encryption by default. See the deployment guides for more information.

OpenShift Data Foundation supports cluster wide encryption with and without Key Management System (KMS). Cluster wide encryption with KMS is supported using the following service providers:

  • HashiCorp Vault - Tested with Version 1.9.1 and 1.21.1
  • Thales Cipher Trust Manager - Tested with Version 2.9.0+7637, crypto version: 1.5.0

Security common practices require periodic encryption key rotation. OpenShift Data Foundation automatically rotates encryption keys stored in Kubernetes Secret (non-KMS) and Vault on a weekly basis. However, key rotation for Vault KMS must be enabled after the storage cluster creation and does not happen by default. For more information refer to the deployment guides.

Note

Using KMS requires a valid Red Hat OpenShift Data Foundation Advanced subscription. To know how subscriptions for OpenShift Data Foundation work, see knowledgebase article on OpenShift Data Foundation subscriptions.

Cluster wide encryption with HashiCorp Vault KMS provides two authentication methods:

  • Token: This method allows authentication using vault tokens. A Kubernetes Secret containing the vault token is created in the openshift-storage namespace and is used for authentication. If this authentication method is selected then the administrator has to provide the vault token that provides access to the backend path in Vault, where the encryption keys are stored.
  • Kubernetes: This method allows authentication with vault using serviceaccounts. If this authentication method is selected then the administrator has to provide the name of the role configured in Vault that provides access to the backend path, where the encryption keys are stored. The value of this role is then added to the ocs-kms-connection-details config map.
Note

OpenShift Data Foundation on IBM Cloud platform supports Hyper Protect Crypto Services (HPCS) Key Management Services (KMS) as the encryption solution in addition to HashiCorp Vault KMS.

Important

Red Hat works with the technology partners to provide this documentation as a service to the customers. However, Red Hat does not provide support for the Hashicorp product. For technical assistance with this product, contact Hashicorp.

5.3.2. Storage class encryption
Copier lien

You can encrypt persistent volumes (block only) with storage class encryption using an external Key Management System (KMS) to store device encryption keys. Persistent volume encryption is only available for RADOS Block Device (RBD) persistent volumes. See how to create a storage class with persistent volume encryption.

Storage class encryption is supported in OpenShift Data Foundation 4.7 or higher with HashiCorp Vault KMS. Storage class encryption is supported in OpenShift Data Foundation 4.12 or higher with both HashiCorp Vault KMS and Thales CipherTrust Manager KMS.

Note

Requires a valid Red Hat OpenShift Data Foundation Advanced subscription. To know how subscriptions for OpenShift Data Foundation work, see knowledgebase article on OpenShift Data Foundation subscriptions.

5.3.3. CipherTrust manager
Copier lien

Red Hat OpenShift Data Foundation version 4.12 introduced Thales CipherTrust Manager as an additional Key Management System (KMS) provider for your deployment. Thales CipherTrust Manager provides centralized key lifecycle management. CipherTrust Manager supports Key Management Interoperability Protocol (KMIP), which enables communication between key management systems.

CipherTrust Manager is enabled during deployment.

Starting with OpenShift Data Foundation version 4.14, Red Hat Ceph Storage’s messenger version 2 protocol can be used to encrypt data in-transit. This provides an important security requirement for your infrastructure.

In‑transit encryption can be enabled during deployment while the cluster is being created, and it can also be enabled on existing clusters after deployment. For deployment‑time configuration, see the relevant deployment guide for your environment. For post‑deployment configuration, see Enabling in‑transit encryption after deployment.

The msgr2 protocol supports two connection modes:

crc

  • Provides strong initial authentication when a connection is established with cephx.
  • Provides a crc32c integrity check to protect against bit flips.
  • Does not provide protection against a malicious man-in-the-middle attack.
  • Does not prevent an eavesdropper from seeing all post-authentication traffic.

secure

  • Provides strong initial authentication when a connection is established with cephx.
  • Provides full encryption of all post-authentication traffic.
  • Provides a cryptographic integrity check.

The default mode is crc.

5.3.5. Object Storage Data encryption supportability
Copier lien

Red Hat OpenShift Data Foundation supports Server-Side Encryption (SSE) to ensure the confidentiality of data at rest. The supportability of specific SSE modes (SSE-C, SSE-S3, and SSE-KMS) varies between the Multicloud Object Gateway and the Rados Gateway.

Multicloud Object Gateway (MCG)

The Multicloud Object Gateway provides encryption at rest by default for all backing stores.

  • SSE-C: Supported. Clients can manage their own encryption keys and provide them with each read or write request (x-amz-server-side-encryption-customer-key). MCG performs the encryption and decryption, but does not store the key.
  • SSE-S3: Supported and enabled by default. MCG encrypts data by default using system-managed keys, providing behavior consistent with SSE-S3.
  • SSE-KMS: Supported. MCG integrates seamlessly with external Key Management Systems (KMS) if configured for cluster wide-encryption.

Rados Gateway (RGW)

The Rados Gateway (Ceph Object Storage) supports granular Server-Side Encryption options for S3 clients.

  • SSE-C: Supported. Clients can manage their own encryption keys and provide them with each read or write request (x-amz-server-side-encryption-customer-key). RGW performs the encryption and decryption, but does not store the key.
  • SSE-S3: Not supported.
  • SSE-KMS: Not supported.
Note

Enabling encryption with an external KMS requires a valid Red Hat OpenShift Data Foundation Advanced subscription. To know how subscriptions for OpenShift Data Foundation work, see knowledgebase article on OpenShift Data Foundation subscriptions.

5.4. Encryption in Transit
Copier lien

You need to enable IPsec so that all the network traffic between the nodes on the OVN-Kubernetes Container Network Interface (CNI) cluster network travels through an encrypted tunnel.

By default, IPsec is disabled. You can enable it either during or after installing the cluster. If you need to enable IPsec after cluster installation, you must first resize your cluster MTU to account for the overhead of the IPsec ESP IP header.

For more information on how to configure the IPsec encryption, see Configuring IPsec encryption of the Networking guide in OpenShift Container Platform documentation.

Deployment of Multicloud Object Gateway in cloud environments uses the default network configuration provided by the cloud platform. These default configurations are typically publicly accessible but require authentication. Network access to the OpenShift cluster network and applications can be restricted by applying the access control mechanisms described in the following cloud provider documentation:

5.5.1. Multicloud Object Gateway public routes
Copier lien

By default, Multicloud Object Gateway (MCG) automatically creates public routes (S3, STS, and noobaa-mgmt) to enable external access from public networks. This default behavior helps with testing and initial evaluation of the service by allowing immediate access without additional configuration.

These public routes require authentication but are accessible from outside the OpenShift cluster network. For production deployments or environments with stricter security requirements, you can disable these routes after deployment.

For information on how to disable external access routes, see Disabling Multicloud Object Gateway external service after deploying OpenShift Data Foundation.

Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2026 Red HatRetour au début