SRCmail/deploy/k8s/ca/ejbca.yaml

# EJBCA Community Edition.
#
# VERIFY THE ENV CONTRACT BEFORE YOU TRUST THIS FILE. EJBCA's container
# configuration has changed across releases, so pin a tag and check its
# documented variables rather than assuming these carry over:
#   docker run --rm keyfactor/ejbca-ce:<tag> cat /opt/keyfactor/bin/start.sh | head -60
# The shape below (external MariaDB, two ports, healthcheck path) is stable; the
# individual variable names are the part most likely to drift.
apiVersion: v1
kind: Service
metadata:
  name: ejbca
  namespace: vnc-ca
spec:
  type: ClusterIP
  selector:
    app: ejbca
  ports:
    # 8080 — plain HTTP, NO client-certificate authentication. Only the public
    # web is served here: CRL distribution and the OCSP responder. This is the
    # only port the public ingress touches.
    - name: http
      port: 8080
      targetPort: 8080
    # 8443 — HTTPS with mandatory client-certificate auth. Admin web AND the
    # REST API. Never exposed through an ingress; reachable only from inside the
    # cluster (the enrolment route) or via `kubectl port-forward` (you, doing
    # administration). See networkpolicy.yaml.
    - name: https
      port: 8443
      targetPort: 8443
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ejbca
  namespace: vnc-ca
spec:
  replicas: 1
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: ejbca
  template:
    metadata:
      labels:
        app: ejbca
    spec:
      # EJBCA needs the DB reachable before WildFly deploys its datasource.
      initContainers:
        - name: wait-for-db
          image: mariadb:11.4
          command:
            - sh
            - -c
            - |
              until mariadb-admin ping -h ejbca-db --silent; do
                echo "waiting for ejbca-db..."; sleep 3
              done
      containers:
        - name: ejbca
          # Pin an explicit tag. `latest` on a CA is how you get an unplanned
          # schema migration during an incident.
          image: keyfactor/ejbca-ce:9.1.1
          env:
            - name: DATABASE_JDBC_URL
              value: jdbc:mariadb://ejbca-db:3306/ejbca?characterEncoding=UTF-8
            - name: DATABASE_USER
              valueFrom:
                secretKeyRef: { name: ejbca-db, key: MARIADB_USER }
            - name: DATABASE_PASSWORD
              valueFrom:
                secretKeyRef: { name: ejbca-db, key: MARIADB_PASSWORD }
            # Lets EJBCA generate its own server TLS keypair on first boot. The
            # REST/admin listener is cluster-internal and authenticated by
            # CLIENT certificate, so a self-signed server cert here is fine —
            # our enrolment route pins the CA chain explicitly rather than
            # trusting the public roots. Do not "fix" this with cert-manager
            # without also updating that pin.
            - name: TLS_SETUP_ENABLED
              value: "simple"
            - name: LOG_LEVEL_APP
              value: INFO
          ports:
            - name: http
              containerPort: 8080
            - name: https
              containerPort: 8443
          # First boot builds the schema and can take minutes. A tight
          # startupProbe budget here will CrashLoop a CA that is merely slow.
          startupProbe:
            httpGet:
              path: /ejbca/publicweb/healthcheck/ejbcahealth
              port: 8080
            periodSeconds: 10
            failureThreshold: 60
          readinessProbe:
            httpGet:
              path: /ejbca/publicweb/healthcheck/ejbcahealth
              port: 8080
            periodSeconds: 15
          livenessProbe:
            httpGet:
              path: /ejbca/publicweb/healthcheck/ejbcahealth
              port: 8080
            periodSeconds: 30
            failureThreshold: 5
          resources:
            requests:
              cpu: 500m
              memory: 2Gi
            limits:
              memory: 4Gi