Clusters

Luna Network HSM 7 now allows you to store your cryptographic objects in an encrypted cluster within the appliance memory. This process uses Scalable Key Storage to encrypt the cluster and the SMK is shared with all member HSMs. The cluster contains keyrings, which are analogous to application partitions and can be accessed by a client in much the same way, by connecting to any member appliance. Keys are retrieved from the cluster, decrypted within the secure confines of the HSM, and used by the HSM for cryptographic operations. This configuration allows you to store many more keys than you can normally store within HSM partitions. The management of backup and restore operations is greatly simplified; the HSM administrator can back up the full content of a cluster, at scheduled intervals or on demand.

A cluster can consist of one Luna Network HSM 7 member appliance, or multiple appliances that share the contents of the cluster. Adding multiple members to a cluster improves performance, and provides redundancy and failover for your client applications. Thales recommends a maximum of 4 members per cluster.

Up to 3500 keyrings can be created on the cluster. Each Luna HSM Client can manage up to 3500 keyrings, which can be spread across multiple clusters. Using lnh_cluster-1.0.4 or older, keyrings can contain up to 256 objects; newer versions do not have this limitation.

Thales is pleased to announce that Clusters, designed to reduce operation cost and maximize the return on investment of a fleet of HSMs, are fully supported for new production deployments and migration from Luna application partitions. Thales requires minimum Luna Appliance Software 7.8.5 with the lnh_cluster-1.0.4 package, Luna HSM Firmware 7.8.4, and Luna HSM Client 10.7.2 to use clusters in production environments, or minimum Luna Appliance Software 7.9.0 with the lnh_cluster-1.0.5 package, Luna HSM Firmware 7.8.4, and Luna HSM Client 10.8.0 to migrate keys from Luna application partitions.

This section will guide you through key concepts and procedures required to set up, manage, and use your Luna Network HSM 7 cluster.

The Cluster Partition

The cluster uses Scalable Key Storage (SKS) to secure keyrings and objects. The cluster partition is a V1 application partition (see V0 and V1 Partitions) on the Luna Network HSM 7 that stores the cluster's SKS Master Key (SMK). The cluster SMK encrypts all keyrings and their objects in the cluster. When an object is required for a cryptographic operation, it is retrieved from the cluster and inserted into the cluster partition, where it is decrypted with the cluster SMK, and the operation is performed in the partition's secure environment.

New member appliances that join the cluster import the cluster SMK to a V1 partition on their local crypto module. This allows each member to have read-write access to objects on the shared cluster.

Client-Cluster Connections

Each Luna HSM Client that runs applications using objects on the cluster directs its traffic to a specified cluster member. The LNHClientRegistration script is provided with the client software for this purpose. The member specified when running the client registration script acts as the first point of contact between that client and the cluster; all client application requests are directed to that member, and then load-balanced to other cluster members.

Refer to Cluster-Client Connections for guidelines on using the LNHClientRegistration script.

Synchronization and Load-Balancing

Keyrings and their contents are synchronized across all members of the cluster, so any member can be queried by client applications for cryptographic operations. Appliance user accounts are also synchronized via the cluster, so users with admin, operator, and monitor privileges can log in to any member. In a cluster with two or more members, the users/roles configuration stored in the cluster are taken as the authority -- if an appliance with custom users/roles joins the cluster, they are overwritten by the users/roles stored in the cluster. This ensures that all cluster members have the same authorized users, and that those users can log in to any individual cluster member.

Client operations are load-balanced across the cluster members to optimize performance and availability. Load-balancing can be customized by moving members between Affinity Groups as described below.

The Primary Member

The Luna Network HSM 7 appliance where the cluster is created becomes the primary cluster member. The primary member always has read-write privileges to the cluster; other members have read-write privileges as long as they maintain a network connection to the primary member. If a member's connection to the primary member is disrupted, that member becomes read-only until the connection is re-established. New and existing client sessions become read-only. This applies to connections between the primary and the other members, and is not affected by the client; if a member becomes read-only, the client will not fail over to another member for operations requiring write privileges; these operations will fail. This is necessary to prevent objects stored on the cluster from becoming de-synchronized between members.

You can manually promote a member to primary at any time, as long as that member has read-write privileges at the time of promotion. If the primary cluster member loses connectivity to the cluster, all other members become read-only until it is reconnected. If the primary member is unrecoverable, you must manually remove it from the cluster, at which time another member will automatically be promoted to primary, and the cluster members regain read-write privileges.

See Promoting a Member to Primary.

In the example below, member D has lost connectivity to the primary cluster member. Thus, Client B can perform only operations that do not require write privileges, until member D re-establishes a connection to the primary member, or Client B's traffic is directed to a different member.

Affinity Groups

Luna Network HSM 7s within a cluster can be added to an affinity group. Operations from a connected client application are load-balanced between members of the same group only. This allows you to use the other members, which can be at a remote location with greater latency, as backup or standby members for a specific client. If all members of a client's preferred group are unavailable, operations then fail over to other members of the cluster. The state of keyrings and objects stored on them is always synchronized across all members of the cluster, regardless of group. You can create up to 64 affinity groups in a cluster.

New members are added to the local group by default and can be moved to another group (see Moving a Member to a Different Affinity Group).

In the example below, the groups are configured so that Client A sends operation requests to cluster member C, (which are load-balanced between members A and C) and Client B sends operation requests to cluster member D (which are load-balanced between members B and D). Each group acts as a standby group for the other.

Keyring Roles and Identity Modes

Each keyring on a cluster has two roles that are analogous to the Partition Security Officer and Crypto Officer roles on a standard Luna partition. They are referred to here as:

>Keyring Security Officer (KRSO): initially set by the Partition Security Officer for the partition that created the cluster

>Keyring Crypto Officer (KRCO): performs cryptographic operations on the keyring

Using Luna Appliance Software 7.9.0 or newer with lnh_cluster-1.0.5 or newer, you can configure the cluster in one of the following identity modes:

>Single-Identity Mode (default): In this mode, the KRSO and KRCO roles on each keyring are intended to be held by the same individual, and use the same password. When the password for one role is changed, the change is applied to the other role as well.

>Dual-Identity Mode: In this mode, the KRSO and KRCO roles on each keyring use separate passwords, and this separation is enforced using the same rules as standard Luna application partitions. This mode is required if you are migrating keys from standard Luna partitions to keyrings.

Consider this distinction before configuring your cluster; you may not switch from one mode to another without resetting the cluster to factory conditions. If you are using Luna Appliance Software 7.8.5 with lnh_cluster-1.0.4 or older, only single-identity mode is available.

Separation is always enforced between the keyring roles and the cluster security officer (PO of the partition where the cluster's SMK is stored).

Client Assignment Modes

Keyrings are assigned to registered clients so they can be accessed by LunaCM or your client applications. If you have many keyrings or clients, it may be convenient to assign keyrings only to the clients that will use them; only keyrings assigned to a client are visible as slots in LunaCM and can be queried by applications on that client. Client applications must always provide the correct KRCO credential to access objects on any keyring.

Using Luna Appliance Software 7.9.0 or newer with lnh_cluster-1.0.5 or newer, you can configure the cluster in one of the following keyring assignment modes:

>Auto-Assignment Mode (default): In this mode, keyrings are automatically assigned to all registered clients; all keyrings on the cluster are visible in LunaCM on any registered client.

>Manual Assignment Mode: In this mode, keyrings must be manually assigned to or unassigned from registered clients. Clients are only able to see keyrings which have been assigned to them. Keyrings can be assigned to multiple clients.

Consider this distinction before configuring your cluster; while you may switch from one mode to the other at any time, keyring assignments are preserved. If you originally configured auto-assignment mode and switch to manual assignment, it may be inconvenient to manually unassign many keyrings from individual clients. If you are using Luna Appliance Software 7.8.5 with lnh_cluster-1.0.4 or older, only auto-assignment mode is available.

Keyring Object Attributes

Keyrings can be used much like standard Luna partitions to create and store cryptographic objects, and perform operations using those objects. The following attributes may be set on keyring objects:

>CKA_LABEL

>CKA_ECDSA_PARAMS

>CKA_EC_POINT

>CKA_TOKEN

>CKA_VALUE

>CKA_KEY_TYPE

>CKA_CLASS

>CKA_UNWRAP

>CKA_SIGN

>CKA_DECRYPT

>CKA_ID

>CKA_MODULUS

>CKA_WRAP

>CKA_PUBLIC_EXPONENT

Cluster Backup/Restore

The entire contents of the cluster can be backed up to the Luna Network HSM 7 appliance in an encrypted file, accessible to the admin user. You can perform backups on demand, or schedule periodic backups and determine how many to store before the oldest ones are overwritten. You can restore the entire cluster from a backup at any time. See Cluster Backup and Restore for procedures.