Thales Luna integration in Kubernetes

Enterprise

The Thales Luna HSM sidecar container enables integrating the application container to a network attached Thales Luna. The following covers how to set up the integration in Kubernetes.

For more general information on the HSM integration with PKCS#11, see HSM Integration.

Prerequisites

Before using this container, you need the following:

• Luna7 net-HSM with fully configured secured network access. The EJBCA deployment will be configured with:

  • The IP address/hostname of the HSM

  • server.pem certificate

• Administrative access on the HSM for registering a client and assigning partitions to the client.

• The P11 Proxy must have network access to the HSM service (security groups, network ACLs, etc)

• An existing key pair credential for the client, i.e. the HSM driver container, to communicate with the HSM.

HSM driver container deployment parameters

The following lists parameters for the HSM sidecar container.

Environment variables

The following environment variables configure the HSM sidecar container with the Helm chart in the hsm.luna section.

Volume mounts

The volume mount parameters are mandatory and need only be configured in the HSM sidecar container. These mounts are defined via the Helm chart under the hsm.luna section, using a combination of ConfigMap and Secret resources.

You can verify the configuration by checking the corresponding files inside the container after deployment.

Prepare HSM configuration

Configure the server certificate and client credentials:

1. Create a Kubernetes secret with the client private key to communicate with the HSM.

   • The file name inside the secret must be dockerlunaclientKey.pem.

   • Replace <namespace> with your deployment's namespace.

   • The name of this secret must be referenced later in the Helm values.yaml.

     Bash

     kubectl create secret generic hsm-luna-secret-client-key \
          -n cadeploymentnamespace --from-file=dockerlunaclientKey.pem=dockerlunaclientKey.pem
     

2. Create a Kubernetes ConfigMap to configure the HSM server certificate and client certificate.

   • The HSM server certificate and client certificate values in the values.yaml may be adjusted in the next section.

Example (certificate contents truncated):

apiVersion: v1
kind: ConfigMap
metadata:
  name: hsm-luna-configmap
data:
  server.pem: |
    -----BEGIN CERTIFICATE-----
    MIIDOTCCAiGgAwIBAgIBADANBgkqhkiG9w0BAQsFADBgMQswCQYDVQQGEwJDQTEQ
    .....truncated.....
    OaIJWeLzCzXw4bzKbl5VvfwXmrTyCh0wHgN+E1VOhv8s2HhA3/Mzujb1VhPDCT0Z
    LP1EfFulatVU0dtbQg==
    -----END CERTIFICATE-----
  dockerlunaclient.pem: |
    -----BEGIN CERTIFICATE-----
    MIIDMzCCAhugAwIBAgIBADANBgkqhkiG9w0BAQsFADBdMQswCQYDVQQGEwJDQTEQ
    .....truncated.....
    xP96D2AMJN/9/rPHLHEJqETdYBvZYwdzyqB9GinxwuxlCfkrolx+ETyk16wK63m1
    dABXXPaeLg==
    -----END CERTIFICATE-----

Configure Deployment

The following example shows how to customize the EJBCA deployment using Helm. The values.yaml file provided with the Helm chart describes a test deployment and does not include:

The following provides an example of customizing the deployment using Helm. Note that the Helm chart values file values.yaml describes an example test deployment and does not include:

• Database connection.

• imagePullSecrets that may be required for your environment.

• TLS connection required after deployment and CA creation.

Adjust the HSM server environment variable (server_name) and configure any required secrets for your environment.

#imagePullSecrets: []
ejbca:
  env:
    TLS_SETUP_ENABLED: "later"
    LOG_AUDIT_TO_DB: true
#################### HSM configuration - start ####################
hsm:
  enabled: true
  luna:
    enabled: true
    server_name: "192.168.30.106"
    credentials:
      certificates:
        configMap: "hsm-luna-configmap"
      privateKey:
        secret: "hsm-luna-secret-client-key"
#################### HSM configuration - end ####################
podSecurityContext:
  fsGroup: 10001
# Ingress or LoadBalancer configuration skipped

Configure a custom Chrystoki.conf

Alternatively, instead of specifying server_name, you can provide a custom Chrystoki.conf file. To do this, create a Kubernetes secret containing the file.

The file name inside the secret must be Chrystoki.conf.

Replace <namespace> with the namespace in which EJBCA is deployed. The name of the secret must be specified in the Helm values.yaml file, as shown below.

kubectl create secret generic -n <namespace> hsm-luna-chrystoki \
    --from-file=Chrystoki.conf=Chrystoki.conf

Then, in your values.yaml file, specify custom_chrystoki_conf_secret instead of server_name:

#imagePullSecrets: []
ejbca:
  env:
    TLS_SETUP_ENABLED: "later"
    LOG_AUDIT_TO_DB: true
#################### HSM configuration - start ####################
hsm:
  enabled: true
  luna:
    enabled: true
    custom_chrystoki_conf_secret: hsm-luna-chrystoki
    credentials:
      certificates:
        configMap: "hsm-luna-configmap"
      privateKey:
        secret: "hsm-luna-secret-client-key"
#################### HSM configuration - end ####################
podSecurityContext:
  fsGroup: 10001
# Ingress or LoadBalancer configuration skipped

Configure High Availability (HA)

The HA group must be created in advance on a registered Luna client. This ensures that the group members share the required key material and internal HA master key. The sidecar uses an existing HA group; it does not create the group. For more information, refer to Thales documentation Setting Up an HA Group.

The sidecar can use a Thales Luna HA group without any changes to the deployment parameters. The environment variables, volume mounts, and crypto token configuration steps are the same as for a single-HSM integration. The HA configuration is defined entirely in the injected Chrystoki.conf.

Add the following three sections to the Chrystoki.conf file you provide, in addition to the LunaSA Client section that points to the Luna servers:

VirtualToken = {
  VirtualToken00Label   = <GROUP_LABEL>;      # becomes the slot label EJBCA connects to
  VirtualToken00SN      = <GROUP_SN>;         # HA group serial number
  VirtualToken00Members = <MEMBER_SN_1>,<MEMBER_SN_2>;   # member partition serials
  VirtualTokenActiveRecovery = activeEnhanced;
}

HAConfiguration = {
  reconnAtt = -1;
  AutoReconnectInterval = 60;
  ProbeTimeout = 0;
  haLogStatus = disabled;
}

HASynchronize = {
    <GROUP_LABEL> = 1;
}

The HA group is presented to EJBCA as a single slot with the label <GROUP_LABEL>. Create the crypto token using this slot in the same way as for the standard HSM integration.

Create and verify HSM crypto token

To create a crypto token and then test the HSM key, do the following:

1. In the EJBCA menu, click CA Functions > Crypto Tokens.

2. Click Create new and specify the following on the New Crypto Token page:

   • Name: Specify a name for the crypto token.

   • Type: Select PKCS#11 NG.

   • Auto-activation: Select use to allow EJBCA to save the password and reapply it after a restart so that the CA is always available.

   • For PKCS#11 : Reference Type, select Slot/Token Label.

   • For PKCS#11 : Reference, select one of the listed slots available in the HSM.

   • Authentication Code: Enter a password for auto-activation, the same as provided for the slot or token in the HSM.

   • Click Save to create the crypto token.

3. Once created, you can generate new key pairs or view any existing key pairs on the HSM.

4. To verify that the HSM key is operational, click Test.

Advanced deployments

The EJBCA Enterprise configuration export/import tool EJBCA ConfigDump allows you to deploy EJBCA with automation. For information on deploying EJBCA with automation, using a soft HSM integration suitable for testing, see Deploy EJBCA as CA with automation with SoftHSM2.

Thales Luna 7 HSM installations can also be automated using the EJBCA ConfigDump tool. For information on how to configure the tool in Kubernetes, see EJBCA Configdump in Kubernetes.

.