Clusters

Luna Network HSM 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 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, and each keyring can contain up to 256 objects. Each Luna HSM Client can manage up to 3500 keyrings, which can be spread across multiple clusters.

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

The SKS Master Key

Objects on the cluster are encrypted by a master key, which is created and stored on a V1 application partition on the primary cluster member. New members that join the cluster import the same SMK to a V1 partition on their local HSM. This allows each member to have read-write access to objects on the shared cluster. Refer to Scalable Key Storage for more information.

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 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 HSMs 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. When one or more members of the preferred group become available again, you must restart your client application to move operations back to the preferred 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 Authentication

Each keyring 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

Unlike standard Luna partitions, role separation between the KRSO and KRCO roles is not enforced. Separation is enforced, however, between the keyring roles and the cluster security officer (PO of the partition where the cluster's SMK is stored).

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

When Luna Network HSM is configured as a cluster, the entire contents of the cluster can be backed up to the 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.