EJBCA Helm Chart Building Blocks 

ENTERPRISE

EJBCA is a Public Key Infrastructure (PKI) solution that can be deployed in Kubernetes environments using Helm. The EJBCA Helm chart simplifies deployment, configuration, and scaling, allowing security engineers and DevOps teams to set up PKI services efficiently. 

This guide explores the key capabilities of the EJBCA Enterprise Helm chart and provides a structured breakdown of its configuration, including database connectivity, HSM integration (P11NG), proxy settings, auto-scaling, and security measures. 

Deployment Architecture with Helm 

Helm Chart Composition 

The EJBCA Helm chart defines a modular and flexible deployment structure, enabling: 

• Clustered deployment: Multiple EJBCA instances operating with a replicated database and Hardware Security Modules (HSMs). 

• Scalability & redundancy: Load balancing across multiple pods for high availability. 

• External access: Configurable ingress and load balancing options. 

A single Helm release can deploy a fully operational EJBCA cluster, reducing operational overhead and ensuring consistency. 

EJBCA Configuration Parameters 

The ejbca section in values.yaml is used to configure properties used inside EJBCA. By leveraging environment variables or file mounts (for example, ConfigMap or Secret), configurations can be dynamically adjusted without modifying container images. 

These properties include:

• Database configuration properties, such as JDBC URL, username, and password.

• Configuration for signed tamper-proof audit logging and database integrity.

• ConfigDump for deployment automation.

Additional configuration properties can be found in values.yaml or in the EJBCA Helm Deployment Parameters section of the EJBCA Container Set documentation

As a rule of thumb, consider whether the property will be used by EJBCA application itself. If so, it may be relevant to include the property in the ejbca section of the values.yaml configuration file.

Example Configuration in values.yaml

ejbca:​
  importEjbcaConfFiles: false​
  ejbcaConfFilesSecret: ejbca-conf​
  ​
  configdumpImport:​
    enabled: false​

  env:​
    LOG_AUDIT_TO_DB: true​
    DATABASE_JDBC_URL: "jdbc:mariadb://….."​
    DATABASE_USER: ejbcauser​
  envRaw:​
    - name: DATABASE_PASSWORD​
      valueFrom:​
        secretKeyRef:​
          name: mariadb-passwords​
          key: mariadb-password​

By properly configuring the ejbca section in values.yaml, you can ensure that EJBCA operates with the correct settings while maintaining flexibility. For a complete list of configurable properties, refer to the EJBCA Helm Deployment Parameters section of the EJBCA Container Set documentation or inspect the values.yaml file.

Helm and Hardware Security Module (HSM) Integration 

EJBCA can integrate with networked Hardware Security Modules (HSMs) for secure key storage. 

Each supported HSM vendor requires a different set of parameters to be configured. All HSM configurations can be managed through the Helm chart, following a consistent pattern.

Key configuration points:

• The HSM IP Address must be specified.

• HSM client credentials are securely stored as Kubernetes Secrets. 

• Additional parameters may be required, provided either as environment variables or via a Kubernetes ConfigMap.

 Example: Luna HSM Integration

The following provides an example with Luna HSM.  

• The HSM IP address is configured using the by SERVER_NAME environment variable.

• TLS credentials are managed through:

  • A Kubernetes Secret containing the client TLS private key.

  • A ConfigMap containing the client TLS certificate.

Example Configuration in values.yaml

ejbca:​
  initContainers:​
    - name: hsm-driver-init​
      image: primekey/…/hsm-driver-luna7:10.5.1​
      #...​
  sidecarContainers:​
    - name: hsm​
      image: primekey/…/hsm-driver-luna7:10.5.1​
      env:​
        - name: SERVER_NAME​
          value: "192.168.1.25"​
      volumeMounts:​
        - name: hsm-luna-configmap-servercert​
          #...​
        - name: hsm-luna-configmap-client-cert​
          #...​
        - name: hsm-luna-secret-client-key​
          #...​
  volumes:​
    #...​
  volumeMounts:​

​For more information, refer to the EJBCA Container Set HSM Integration documentation.

Secure Communication to EJBCA

This section covers how to configure encryption in transit inside Kubernetes and externally. You can ensure end-to-end TLS encryption to EJBCA pod by terminating TLS at the proxy sidecars. This applies to both ClusterIP and LoadBalancer services, which handle cluster internal and external communication respectively.

TLS credentials, including the server certificate, private key, and trusted CA certificates, can be configured in the sidecar sections in the values.yaml configuration file.

Proxy Configuration

EJBCA supports two primary proxy configurations: NGINX and HTTPD. Only one of these proxies can be used at a time. Each proxy is configured within values.yaml under its respective section (nginx or httpd).

Key points to note:

• Each proxy allows TLS credential management using Kubernetes Secrets, for example, secretInternalNginxCert

• A service is automatically created with the name {helm-release-name}-nginx or {helm-release-name}-httpd.

• The default host name used for external cluster communication is configurable via the host property.

Example Configuration in values.yaml

NGINX Configuration

nginx:​ 
  enabled: true​
  host: "ejbca-ca.example.org"​
  mountInternalNginxCert: true​
  secretInternalNginxCert: "internal-httpd-credential-secret-ca"

Apache HTTPD Configuration

httpd:​
  enabled: true​
  host: "ejbca-ca.example.org"​
  mountInternalHttpdCert: true​
  secretInternalHttpdCert: "internal-httpd-credential-secret-ca"​

By configuring TLS termination at the proxy sidecars, secure communication to EJBCA is ensured both within the Kubernetes cluster and externally. For additional configurations and advanced features, refer to the EJBCA Container Set Deployment documentation.

Cluster External Access

It is recommended to use a LoadBalancer service for connecting to EJBCA from outside the cluster. This can be enabled by setting the parameter service.type: LoadBalancer for both proxies.

Example Configuration in values.yaml

NGINX Configuration

nginx:​
  #...
  service:
    type: LoadBalancer

Apache HTTPD Configuration

httpd:​
  #...
  service:
    type: LoadBalancer

Ingress Configuration

Alternatively, you can use Ingress according to the following configuration example.

ingress:​
  enabled: true​
  className: "nginx"​
  annotations:​
    nginx.ingress.kubernetes.io/auth-tls-verify-client: "optional_no_ca"​
    nginx.ingress.kubernetes.io/auth-tls-secret: "ejbca-ns/ingress-trust"​
    nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream: "true"​
    nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1"​
  hosts:​
    - host: "ejbca-ca.example.org"​
      paths:​
        - path: /​
          pathType: Prefix​ 

Auto-Scaling and Performance Optimization 

EJBCA’s Helm chart supports horizontal pod auto-scaling (HPA) to optimize performance and resource usage. Auto-scaling is based on:

• CPU utilization 

• Memory consumption 

Both parameters can be configured in values.yaml to ensure efficient scaling based on workload demands.

Example Configuration based on CPU utilization

autoscaling:​
  enabled: true​
  minReplicas: 1​
  maxReplicas: 3​
  targetCPUUtilizationPercentage: 80​
resources:​
  limits:​
    cpu: 8Gi​
  requests:​
    cpu: 2Gi​

This configuration enables dynamic scaling, ensuring that EJBCA can handle workload fluctuations efficiently while optimizing resource allocation. Adjust the values based on your deployment requirements for optimal performance.

Security Hardening and Network Segmentation 

Security in EJBCA deployments can be enforced at multiple layers, including the container filesystem, runtime environment, and the Kubernetes network.

Container Security 

EJBCA and P11NG sidecars run as user 10001. This can also be explicitly enforced in the Kubernetes workload definition.

Example Configuration

podSecurityContext:​
  fsGroup: 10001​

securityContext: ​
  runAsNonRoot: true​

This configuration ensures that containers run as non-root users, reducing the risk of privilege escalation.

Network Segmentation Using Network Policies

EJBCA services can be segmented and secured using Kubernetes Network Policies, which allow you to restrict network traffic between pods and namespaces.

Typical use cases include ensuring controlled access for: 

• Restrict access to the CA from internal corporate networks.

• Enforce one-way communication from Peers (RA/VA) to the CA.

• One way communication from Peers i.e. RA/VA to CA.

•  Restrict access to EJBCA from trusted Kubernetes Namespaces and specific IP address ranges only.

Example: Restrict RA access to specific namespaces 

networkPolicy:​
  policyTypes:​
    - Ingress​
  ingress:​
    # Allow access from specific client IP ranges, ​
    # such as admin access from corporate network or devices using EST, CMP, etc.​
    - from:​
      - ipBlock:​
          cidr: 192.168.122.0/16​
      # Allow traffic from the CA namespace​
      - namespaceSelector:​
          matchLabels:​
            kubernetes.io/metadata.name: ejbca-ca​

These configurations enhance security posture by limiting unauthorized access. 

Conclusion 

The EJBCA Helm chart facilitates automated, scalable, and secure PKI deployment in Kubernetes environments. By leveraging parameterized configurations, HSM integration, auto-scaling, and network segmentation, organizations can efficiently deploy a production-ready CA/PKI faster and in a more controlled way. 

Related Content

• For a tutorial video about the key capabilities and configuration of the EJBCA Enterprise Helm chart, watch our video EJBCA Helm Chart Building Blocks.

• To explore how to deploy EJBCA using Helm in a multi-region, high-availability (HA) setup, ensuring robust certificate lifecycle management across distributed environments, see the solution area High-Availability Multi-Region PKI Deployment with EJBCA and Helm.

• To quickly get started with EJBCA in your Kubernetes cluster using Helm charts, see Get started with EJBCA using Kubernetes and Helm.

• For an overview of the EJBCA Container Set and resources that can be customized to be deployed alongside EJBCA, review the EJBCA Container Set Overview.

• For detailed setup instructions and advanced configurations, refer to the EJBCA Container Set documentation.