Export Mode

Luna export mode does not allow replicating private keys in member HSMs. Hence, SafeNet IDPrime Virtual Server does not support HSM HA mode directly, if HSM partitions are in Export mode. To achieve this, migrate Tenant keys among all the member HSMs.

The SafeNet IDPrime Virtual Server with HSM in export mode is configured with the following mandatory configurations:

1. HSM partition must be in Key export mode.

2. The configuration in SafeNet IDPrime Virtual Server for the parameter, Export Mode (-k) is set to True during the tenant creation.

Perform the following to configure and achieve the HA in export mode with kubernetes:

• Preparing the Master-Worker Nodes Environment in Kubernetes

• Deploying IDPrime Virtual Server on Worker Nodes

• Creating a tenant

• Migrating Keys to Available HSM Partitions

• Verifying the HA Environment

Preparing the Master-Worker Nodes Environment in Kubernetes

For HA, setup a multi-node cluster wherein each node is registered with a different HSM partition. The setup has a master node to manage the cluster, and worker nodes to run the IDPV Server.

The multi-node cluster is prepared by using Kops for setup on AWS or Kubeadm for setup on-premises.

Installation of Kubernetes and its cluster preparation is not included in this guide.

Deploying IDPrime Virtual Server on Worker Nodes

Since pods are required on every worker node, you must perform separate deployments for each node of the cluster. The deployment steps are similar to those described in Deploying IDPrime Virtual Server in Kubernetes, along with node-specific modifications in the Kubernetes-Deployment.yml file.

Before beginning the deployment it is expected that each node’s HSM client is configured with available HSM partitions. When the configuration is done, HSM pem files is located inside /usr/safenet/hsm/.

1. Create folders in the filesystem of a common host machine for keeping the configuration files per node. This host can be an external storage or it can be the machine controlling the cluster, which is a master node.

   For example, create a folder on the master node with config and hsm folders in it, then add the IDPV configuration files and HSM files required for IDPV deployment.

   The config folder should have the following files:

   • appsettings.yml
     • Point the same mysql server as pointed by other nodes.
     • Update HSM partition serial, dedicated for that node.
     • Change ServerPublicURL, to access the WebAPI from that node.
   • log4net.config
   • policy-configuration.json
   • idp-configuration.json
   • sws-configuration.json
   • IngrianNAE.properties

   The hsm folder should have the following files:

   • <Client Certificate>.pem
   • <Client Certificate>Key.pem
   • CAFile.pem
   • Chrystoki.pem

2. Repeat step 1 for all available nodes in the cluster.

3. Create hsm configmaps for each node with the path as given in step 1.

   

   Where: * <configmapName> is a name that distinguishes this configmap for that node. * <nodepath> is the path of the node folder on the common host machine’s filesystem.

   1. Generate secret of application related configuration file for that node as per the process defined in step 2 of Deploying IDPrime Virtual Server in Kubernetes section.

   2. Label nodes with specific value to distinguish them in deployment, and to update the value of the NodeSelector in the deployment file.

   3. Update Kubernetes-Deployment.yml for each node with different container name/labels, configmaps, config files secret, nodeSelector created for that node. After this step, multiple copies of deployment files for different nodes are created.

   4. Apply updated Kubernetes-Deployment.yml files for each node.

Now, every node in the cluster is ready with the POD(s) running an IDPV container.

• If the IDPV database already exists (due to any reason), and it is required to create a new deployment for specific node. Then the newly created POD(s) have permission error while accessing the database.
To solve this issue, it is required to give permission to the POD IP address on the database.
• The POD(s) are deleted and recreated, and it can pick random host part of the IP address.
Then it is required to give permission to <Network Part>: * : *
For example:
If POD IP address 10.32.8.2, it is required to give permission to 10.32. * . *
• CREATE USER 'idprimevirtualuser'@'10.32.*.*' IDENTIFIED BY <DB-Password>;
• GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, REFERENCES, INDEX, ALTER ON IDPrimeVirtualServer.* TO 'idprimevirtualuser'@'10.32.*.*;
• flush privileges;

Creating a Tenant

Perform the following steps when the setup is complete:

1. Choose a node.

2. Run a pod and connect to a shell in the pod using exec.

3. Create a tenant.

Once a tenant is created its keys will be stored in the registered HSM partition.

Migrating Keys to Available HSM Partitions

This section describes how to migrate keys from one partition to all other partitions, which are registered with cluster node(s).

Following are the migration steps between two partitions, assuming that the keys are in slot 0 and are being migrated to a partition in slot 1.

1. Create an RSA/Asymmetric public/private key-pair in the new partition for use in the wrap/unwrap process.

   Import this public key from the new partition to the existing one to wrap the tenant keys.

   When a key is imported into the existing partition, the wrap attribute of the RSA public key is dropped and must be re-instated.

   1. Create RSA asymmetric key pair in the new partition.

      

   2. Check generated keys.

      

      The values for the handles listed above are only for reference.

   3. Check the attributes of generated keys.

      

      

   4. Export the public key from the new partition to the existing partition.

      

      

   5. Import the public key into the existing partition.

      

   6. Check the attributes of the imported key in the existing partition.

      

   7. Set the wrap attribute of the imported public key.

   8. Log in to the existing partition with the CKDEMO utility.

      

   9. Update the public key template to set the wrap attribute.

      

      

2. Use the imported public key from step 1 to wrap both of the symmetric tenant keys stored in the existing partition. Be sure to rename each key immediately after it is wrapped.

   1. Use the Imported public key to wrap both of the symmetric tenant keys.

      

      

      Where:

      • Handle of wrapping key = handle of imported public key to wrap

      • Handle of key to wrap = symmetric tenant key

   2. Once the symmetric key is wrapped, exit the CKDEMO and rename it.

   3. Log in to CKDEMO, and repeat the wrapping process for another symmetric tenant key and rename it.

      

   4. Log in to CKDEMO, and repeat the whole wrapping process for another symmetric tenant key and rename it.

      

3. Use one of the symmetric tenant keys to wrap the asymmetric tenant keys stored in the existing partition. Be sure to rename each key immediately after it is wrapped.

   1. Use the symmetric tenant key to wrap asymmetric tenant keys.

   2. Log in to CKDEMO, and wrap the asymmetric tenant keys with any one symmetric key.

      

      Where:

      • Handle of wrapping key = handle of any one symmetric key

      • Handle of key to wrap = handle of symmetric tenant key

   3. Once the asymmetric tenant key is wrapped, exit CKDEMO and rename it.

      

   4. Repeat the wrapping process for other asymmetric tenant keys and rename them.

      

4. Export the public tenant keys (public part of the asymmetric tenant keys) from the existing partition and import them into the new partition.

   1. Export the public asymmetric tenant keys from the existing partition.

      

   2. Import the exported keys to the new partition.

      

5. Use the private part of the RSA key-pair generated in step 1 to unwrap the wrapped symmetric tenant keys in the new partition.

   1. Unwrap the wrapped symmetric tenant keys in the new partition.

   2. Log in to CKDEMO and perform the following steps:

      

      Where:

      • Handle of unwrapping key = handle of the RSA private key generated for unwrapping in step 1.

      • Filename with key to unwrap = name of the file of wrapped symmetric tenant key, created in step 2.

   3. Repeat the above process with any other symmetric tenant keys.

6. Use the unwrapped symmetric key in the new partition to unwrap the wrapped asymmetric tenant keys.

   1. Unwrap the wrapped asymmetric tenant keys in the new partition.

      

      Set the attributes to the values in the existing partition, corresponding to that key.

      Where:

      • Handle of unwrapping key = handle of symmetric tenant key in the new partition, with which this key was being wrapped in existing partition in earlier step 2.

      • Filename with key to unwrap = name of the file being created after renaming the wrapped asymmetric tenant key, created in step 3.

   2. Repeat the above steps to unwrap another asymmetric tenant key.

7. Rename the tenant keys label in the new partition to that of the source partition.

   Once all of the keys are moved and unwrapped in the new partition, check the attributes of all the keys to identify their handles and then update their labels as per the source.

   

Verifying the HA Environment

Once the keys are migrated to all of the registered partitions for different nodes of the cluster, you can verify whether the created tenant with the existing partition is accessible via other partitions.

Perform following steps to verify if the IDPV container is accessible from POD(s) created on other nodes:

1. Run POD then connect to a shell in it using exec.

2. Check if IDPV WebAPI is accessible by doing curl http://<webapiAddr>/index.html inside the POD.

3. Expose the container outside the POD via creating service using NodePort.

4. Access the IDPV WebAPI url from node’s browser.

5. In the Tenant section, access /IDPrimeVirtual/V1/Tenants/{tenantId} by providing the Tenant Id.

   If migration is successful, tenant details are displayed.

6. Test the access of IDPV WebAPI url from outside the cluster, by accessing http://<NodeIP:NodePort>/index.html from local machine’s browser.

7. If the cluster is exposed to nginx or any other load balancer, then it can be accessed by http://<loadbalancerIP>/index.html.