Integrating OpenStack Barbican with Thales Luna Network HSM for Encrypted Storage (Part 5/5)

---

This blog is part of the VTPP (VNET Threat Perception Platform) project, a three-year programme co-funded by the European Commission under the DIGITAL-ECCC-2022-CYBER-03 call. The project covers DDoS mitigation with FastNetMon, vulnerability scanning with OpenVAS, custom AI/ML detection plugins for Zeek, HSM-backed key management, RPKI validation and a Krill CA, and a full-scale deployment of Security Onion as the IDS/SIEM/NSM backbone.

---

Introduction

Data security is one of the most critical requirements for modern cloud platforms. Organizations operating private or hybrid clouds increasingly require encryption of data at rest-that is, protection of data stored in the storage layers. In an OpenStack environment, one of the most common scenarios is the encryption of Cinder volumes, which are then attached to virtual machines.

Encrypting the data itself, however, is not enough. A key consideration is the secure storage and management of encryption keys. Storing cryptographic material directly in software or in databases poses a security risk and can also be problematic from a compliance standpoint, with regard to requirements such as PCI DSS, GDPR, or internal security policies.

This is precisely why OpenStack offers the Barbican service, which acts as a centralized Key Management Service (KMS). Barbican enables the secure management of secrets, certificates, and cryptographic keys. For an even higher level of protection, Barbican can be integrated with a Hardware Security Module (HSM).

The following article describes the integration of OpenStack Barbican with the Thales Luna Network HSM, with the goal of enabling the creation of encrypted Cinder volumes in an environment that uses an LVM backend.

Solution Architecture

The proposed architecture comprises the following components:

• OpenStack Barbican
• OpenStack Cinder
• LVM backend
• Linux dm-crypt/LUKS
• Thales Luna Network HSM

The process works as follows:

• A user or administrator creates an encrypted volume type.
• When the volume is created, Cinder requests an encryption key from Barbican.
• Barbican uses the PKCS#11 plugin to generate the key in the Luna HSM.
• Cinder then uses the retrieved key to initialize LUKS encryption.
• Data stored on the LVM volume is transparently encrypted.

As a result, the encryption keys themselves are securely generated in the HSM and subsequently stored (wrapped) securely in the OpenStack database.

Environment Prerequisites

Before you begin the configuration, you need to have the following in place:

• A functioning OpenStack deployment
• A deployed Barbican service
• Cinder configured with an LVM backend
• An accessible Thales Luna Network HSM
• The Luna Client software installed
• Network connectivity between the Barbican node and the HSM appliance
• A partition and a crypto officer user created in the Luna HSM

For the remainder of this article, we assume a simple deployment:

• The controller node hosts Barbican
• The storage node uses the LVM backend
• The HSM communicates over the PKCS#11 interface

Installing the Luna Client

On the server where Barbican runs, you need to install the Luna Client package provided by the HSM vendor.

After installation, register the HSM server:

vtl addServer -n <HSM_IP>

Next, create the client registration on the HSM side and verify that the partition is reachable:

lunacm
lunacm:> slot list

The output should display the available partitions and their status.

It is also important to verify that the PKCS#11 library is working:

/usr/safenet/lunaclient/bin/cmu list

Configuring the Barbican PKCS#11 Plugin

Barbican supports several backends for key management. The PKCS#11 plugin is used for integration with an HSM.

The most important configuration resides in the following file:

/etc/barbican/barbican.conf

A sample configuration is shown below. It is important to set slot_id, login, mkek_label, and the HMAC label correctly.

[secretstore]
enable_multiple_secret_stores = True
stores_lookup_suffix = luna
namespace = barbican.secretstore.plugin
 
[secretstore:luna]
secret_store_plugin = store_crypto
crypto_plugin = p11_crypto
global_default = True
 
[p11_crypto_plugin]
library_path = '/usr/safenet/lunaclient/lib/libCryptoki2_64.so'
slot_id = 0
login = 'PARTITION_CO_SECRET'
encryption_mechanism = CKM_AES_GCM
mkek_label = 'os01_mkek'
hmac_label = 'os01_hmac'
hmac_key_type = CKK_GENERIC_SECRET
hmac_keygen_mechanism = CKM_GENERIC_SECRET_KEY_GEN
hmac_mechanism = CKM_SHA256_HMAC
key_wrap_mechanism = CKM_AES_KEY_WRAP_KWP
aes_gcm_generate_iv = False

Next, create the master key objects directly in the HSM:

/opt/stack/data/venv/bin/barbican-manage hsm gen_mkek --library-path \
    '/usr/safenet/lunaclient/lib/libCryptoki2_64.so' --passphrase 'PARTITION_CO_SECRET' \
    --slot-id 0 --label 'os01_mkek' --length 32

The HMAC key is created in a similar way:

/opt/stack/data/venv/bin/barbican-manage hsm gen_hmac --library-path \
    '/usr/safenet/lunaclient/lib/libCryptoki2_64.so' --passphrase 'PARTITION_CO_SECRET' \
    --slot-id 0 --label 'os01_hmac' --length 32

After updating the configuration, restart the Barbican services:

systemctl restart openstack-barbican-api
systemctl restart openstack-barbican-worker

Configuring Cinder Encrypted Volumes

On the Cinder side, you need to enable the integration with Barbican.

In the configuration file:

/etc/cinder/cinder.conf

set the following:

[key_manager]
# fixed_key = aecaeD7ezahChooshaiGh3eengaigh9ke9iezei9oocieChaechee7xaiy0oo9wi
backend = barbican

The fixed_key option belongs to the legacy ConfKeyManager and is left commented out here. It is only relevant when migrating volumes that were previously encrypted with the ConfKeyManager to Barbican; for a fresh, HSM-backed deployment it should remain disabled so that Barbican is used as the sole key manager.

Next, create the encrypted volume type:

openstack volume type create --encryption-provider nova.volume.encryptors.luks.LuksEncryptor \
    --encryption-cipher aes-xts-plain64 --encryption-key-size 256 \
    --encryption-control-location front-end LUKSEncrypted

From this point on, all volumes created with the LUKSEncrypted type will be encrypted automatically.

Note: Barbican restricts secret creation to users who hold the creator role. The Cinder service user must therefore be granted this role, or volume creation will fail with an error such as “Secret creation attempt not allowed – please review your user/project privileges.” Assign the role and restart the Cinder services:

openstack role add --project service --user cinder creator

Verifying Functionality

Create a test volume:

openstack volume create --size 1 --type LUKSEncrypted vol-enc

After attaching the volume to an instance, you can verify the use of dm-crypt on the storage node:

cryptsetup luksDump /dev/stack-volumes-lvmdriver-1/volume-c7cfbebf-06ed-415f-911b-31c7864e1d28

The volume details view shows the encrypted and encryption_key_id fields:

openstack volume show 215eb825-843c-4840-931d-8e9c461eb4e5
openstack secret get d12d22ca-f3a5-40e3-9696-52e386861efa

With the correct configuration, the volume will be mapped through the LUKS layer.

You can likewise verify the created objects directly in the Luna HSM audit logs.

Security and Operational Considerations

For a production deployment, it is worth considering several areas:

• High availability-Barbican can run across multiple instances. The Thales Luna Network HSM supports HA groups, which provides redundancy for cryptographic operations.
• HSM backup-Cryptographic keys stored in the HSM must be backed up using vendor-supported mechanisms. Losing an HSM without a backup can mean irreversible loss of access to your data.
• Monitoring-It is recommended that you monitor HSM availability, partition status, certificate expiration, the number of open sessions, and audit logs.
• Performance-Using an HSM introduces a slight overhead when working with keys; the data encryption itself, however, continues to be performed by the Linux dm-crypt layer on the storage node.

Benefits of the Solution

Integrating Barbican with the Luna Network HSM delivers several practical benefits:

• Centralized management of encryption keys
• Separation of cryptographic operations from the cloud infrastructure
• Improved security for data stored on the storage layer
• Easier fulfillment of compliance requirements

Summary

This article walked through a complete, working integration of OpenStack Barbican with a Thales Luna Network HSM, with the goal of providing hardware-backed key management for encrypted Cinder volumes. The result is an environment in which data at rest is protected by LUKS encryption while the cryptographic keys that make that protection meaningful are anchored in a dedicated, tamper-resistant device rather than in software or a database.

The solution rests on a clear separation of responsibilities across the stack. Cinder and Nova consume keys through Barbican without ever needing to know how those keys are protected. Barbican, acting as the centralized Key Management Service, delegates its cryptographic operations to the HSM through the PKCS#11 plugin and the Luna Client library. The Luna Network HSM generates and guards the master key material, and the storage node performs the actual bulk encryption locally with dm-crypt/LUKS. Each layer does one job, which keeps the design both auditable and operationally manageable.

A key point worth restating is the two-tier key hierarchy illustrated in Figure 2. The master keys – the MKEK and the HMAC key – never leave the HSM. Barbican generates per-project key encryption keys (pKEKs), has the HSM wrap them under the MKEK, and stores only the wrapped pKEKs in its database alongside the pKEK-encrypted secrets. Individual secrets, such as the symmetric key for a Cinder volume, are encrypted with the cached pKEK in software, so steady-state operations do not require a network round-trip to the HSM for every secret. This design balances strong key protection against the throughput a busy cloud demands.

From a deployment perspective, the moving parts that most often determine success are the ones that are easy to overlook: correct registration and certificate exchange between the Luna Client and the appliance, a properly initialized partition with the MKEK and HMAC objects in place, the matching labels and slot identifier in the Barbican configuration, and the creator role granted to the Cinder service so that it is permitted to store secrets. When these align, creating an encrypted volume becomes transparent to the end user, and verification with cryptsetup confirms that the LUKS layer is active on the storage node.

Before promoting the setup to production, revisit the operational considerations covered earlier: configure the HSM in a high-availability group, back up the cryptographic material through vendor-supported mechanisms, monitor partition health and certificate expiry, and account for the modest latency the HSM adds to key operations. With those safeguards in place, the integration provides a solid, compliance-friendly foundation for encrypting block storage in an OpenStack cloud – one that keeps the trust anchored in hardware while leaving day-to-day workflows unchanged.

---

Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union or the European Cybersecurity Competence Centre. Neither the European Union nor the granting authority can be held responsible for them.

---