Prepare HSM prerequisites

Create Kubernetes resources that provide HSM configuration, credentials, and persistent storage for Red Hat Trusted Artifact Signer (RHTAS) components to communicate with your Hardware Security Module.

Before you begin

  • Cluster administrator access to the OpenShift cluster.
  • The RHTAS Operator is installed.
  • HSM vendor documentation for your specific HSM model.
  • For network-attached HSMs, network connectivity from the OpenShift cluster to the HSM.

Procedure

  1. Create a ConfigMap containing your HSM’s configuration file:
    1. For SoftHSM, save the following configuration to a file named softhsm-config.yaml: 
      apiVersion: v1
kind: ConfigMap
metadata:
  name: softhsm-config
  namespace: trusted-artifact-signer
data:
  softhsm2.conf: |
    directories.tokendir = /var/run/hsm-tokens
    objectstore.backend = file
    log.level = INFO

      For production HSMs, replace the softhsm2.conf section with your vendor-specific configuration file:

      • For Thales Luna HSM: Chrystoki.conf
      • For Google Cloud HSM: kmsp11.yaml
      • For AWS CloudHSM: HSM configuration as documented by AWS
    2. Apply the ConfigMap to your cluster: 
      $ oc apply -f HSM_CONFIG_FILE -n NAMESPACE

      The following example shows how to apply the SoftHSM configuration:

      $ oc apply -f softhsm-config.yaml -n trusted-artifact-signer

      where:

      HSM_CONFIG_FILE
      The file containing your HSM ConfigMap definition.
      NAMESPACE
      The namespace where RHTAS is installed.
  2. Create a Secret containing the HSM user PIN: 
    $ oc create secret generic hsm-credentials \
  --from-literal=pin=YOUR_HSM_PIN \
  -n trusted-artifact-signer

    Replace YOUR_HSM_PIN with your actual HSM user PIN.

  3. Optional: For network-attached HSMs that require mutual TLS authentication, create Secrets containing the required certificates: 
    $ oc create secret generic hsm-client-cert \
  --from-file=client.crt=/path/to/client.crt \
  --from-file=client.key=/path/to/client.key \
  -n trusted-artifact-signer
  4. Create PersistentVolumeClaims for HSM token storage:
    Note

    PersistentVolumeClaims are required for SoftHSM because token data must persist across pod restarts. For network-attached HSMs such as Thales Luna or AWS CloudHSM, PVCs are typically not needed because the HSM maintains state independently.
    1. Create the Fulcio HSM tokens PVC: 
      apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: hsm-tokens-pvc
  namespace: trusted-artifact-signer
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100Mi
    2. Create the CTLog HSM tokens PVC: 
      apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ctlog-hsm-tokens-pvc
  namespace: trusted-artifact-signer
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100Mi
    3. Apply both PVCs: 
      $ oc apply -f fulcio-hsm-pvc.yaml -n trusted-artifact-signer
$ oc apply -f ctlog-hsm-pvc.yaml -n trusted-artifact-signer

      Each RHTAS component requires its own PVC because each maintains a separate HSM token store.