EJBCA Configdump in Kubernetes

ENTERPRISE

The following sections oulines how to customize the EJBCA Helm chart and configure Kubernetes resources to streamline the setup and replication of EJBCA environments using automation.

Introduction

File-based configuration and automation can initially seem challenging, but you can simplify the process by manually configuring an EJBCA setup through the EJBCA user interface and exporting the settings as YAML configuration dumps. You can then substitute environment-specific values, such as passwords for cryptographic tokens, before importing the configuration during EJBCA installation.

Using configuration dumps for automation helps synchronize environments. You can manually prepare an EJBCA setup in a development environment and then easily replicate it in staging or production environments, reducing errors and effort.

Automate EJBCA Certificate Authority (CA) deployment

Most manual steps involved in deploying a CA in Kubernetes can be automated using configuration dumps. Note that you still need to manually enroll the super administrator and server certificates.

Automate EJBCA Registration Authority (RA) or Validation Authority (VA) deployment

Using configuration dumps to deploy new RA or VA peer instances simplifies the process of setting up peer connections. While server certificate enrollment must be done manually, other configuration steps involved in deploying an RA or VA in Kubernetes can be automated.

Once you have enrolled and created Kubernetes secrets for the server certificates peers (as described in Deploy RA and VA in Kubernetes), the RA or VA deployment can be completed in two steps:

• Import a configuration dump during the RA or VA installation.

• Import another configuration dump to the CA instance to configure the communication to the peer.

For information on steps required to configure the peer instances, see Deploy EJBCA as RA with automation and Deploy EJBCA as VA with automation. These examples assume that the RA instance is configured before the VA instance, which simplifies the configuration by allowing the setup of Remote Authentication just once. However, note that it is not mandatory to configure the RA before the VA; the instances can be set up independently.

Configure ConfigDump in Helm chart

Kubernetes Secrets and ConfigMaps help manage sensitive and non-sensitive data separately:

• A Kubernetes Secret is an object that contains a small amount of sensitive data such as a password, a token, or a key. Using a Secret means that you do not need to include confidential data in your application code.

• A ConfigMap is an API object used to store non-confidential data in key-value pairs. A ConfigMap allows you to decouple environment-specific configuration from your container images so that your applications are easily portable.

Secrets and ConfigMaps are similar, but Secrets are specifically intended to hold confidential data. For more information, refer to the Kubernetes documentation topics Secrets and ConfigMaps.

The following sections explain how to handle confidential data by creating Secrets for the EJBCA crypto token passwords for multiple environments, configuring the Helm chart values.yaml files, and using a ConfigMap to import non-sensitive environment-specific configuration.

Separate confidential data

The following shows an example configuration dump file for a crypto token in EJBCA, which holds the key pairs of a CA and is protected by a password. The Authentication Code password is confidential and may differ between environments such as development and test.

{
  "crypto-tokens": {
      "CaToken001": {
        "Object Type": "Crypto Token",
        "Version": 2,
        "Name": "CaToken001",
        "Used": true,
        "PKCS11 Library": "/opt/keyfactor/p11proxy-client/p11proxy-client.so",
        "PKCS11 Reference Type": "SLOT_LABEL",
        "PKCS11 Reference": "CA_SLOT",
        "PKCS11 Attribute File": "",
        "Key Pair Info": [],
        "Authentication Code": "supersecretpassword",
        "Type": "Pkcs11NgCryptoToken",
        "Active": true,
        "Auto Activation": true
      }
   }
}

Create a Secret with this information for each environment and configure the values.yaml for the corresponding Helm release accordingly. The rest of the configuration dump can be imported as a Kubernetes ConfigMap.

Create and configure a secret

To create a Kubernetes Secret with multiple values and then import the secrets by modifying the Helm chart values.yaml file:

1. Create a secret with multiple values, following this example command:

   BASH

   kubectl create secret generic configdump-secrets \
         --from-literal=CA_TOKEN_PASS=foo123 \
         --from-literal=OTHER_TOKEN_PASS=bar123

2. Configure the secret in the Helm chart values.yaml:

   YAML

   ejbca:
     envFrom:
       - secretRef:
           name: configdump-secrets

Specify an external ConfigMap

Create a ConfigMap similar to the example below. Note that ${CA_TOKEN_PASS} will be replaced with the secret value provided (in this example, "foo123").

apiVersion: v1
kind: ConfigMap
metadata:
  name: ejbca-init-configmap
data:
  configdump.json: |
    {
      "crypto-tokens": {
        "CaToken001": {
          "Object Type": "Crypto Token",
          "Version": 2,
          "Name": "CaToken001",
          "Used": true,
          "PKCS11 Library": "/opt/keyfactor/p11proxy-client/p11proxy-client.so",
          "PKCS11 Reference Type": "SLOT_LABEL",
          "PKCS11 Reference": "CA_SLOT",
          "PKCS11 Attribute File": "",
          "Key Pair Info": [],
          "Authentication Code": "${CA_TOKEN_PASS}",
          "Type": "Pkcs11NgCryptoToken",
          "Active": true,
          "Auto Activation": true
        }
      }
    }

In the values.yaml, specify both the ConfigMap and the corresponding Secret:

ejbca:
  envFrom:
    - secretRef:
        name: configdump-secrets
  configdumpImport:
    enabled: true
    initialize: true
    configMapName: ejbca-init-configmap
    configMapKey: configdump.json

Specify an inline ConfigMap

Alternatively, you can specify the ConfigMap directly in values.yaml.

ejbca:
  envFrom:
    - secretRef:
        name: configdump-secrets
  configdumpImport:
    enabled: true
    initialize: true
    inlineConfigdump: |
      {
        "crypto-tokens": {
          "CaToken001": {
            "Object Type": "Crypto Token",
            "Version": 2,
            "Name": "CaToken001",
            "Used": true,
            "PKCS11 Library": "/opt/keyfactor/p11proxy-client/p11proxy-client.so",
            "PKCS11 Reference Type": "SLOT_LABEL",
            "PKCS11 Reference": "CA_SLOT",
            "PKCS11 Attribute File": "",
            "Key Pair Info": [],
            "Authentication Code": "${CA_TOKEN_PASS}",
            "Type": "Pkcs11NgCryptoToken",
            "Active": true,
            "Auto Activation": true
          }
        }
      }

By following these steps, you can effectively automate the configuration and deployment of EJBCA instances using Helm charts, ensuring a consistent and error-free setup across different environments.