Tutorial - Deploy EJBCA container in MicroK8s

Learn how to deploy the EJBCA container in the Kubernetes distribution MicroK8s.

This tutorial shows you how to use Ingress for external access to EJBCA and deploy Apache HTTPD for internal services to access EJBCA. The power of EJBCA is leveraged by deploying in Kubernetes to use internally in the Kubernetes cluster as well as externally.

In this tutorial, you will learn how to:

Deploy the EJBCA container into a Kubernetes runtime
Use Ingress for external access to EJBCA
Deploy Apache HTTPD container for containers inside of the Kubernetes cluster to access EJBCA
Configure certificates issued from the EJBCA container to terminate TLS for accessing EJBCA

Prerequisites

For this tutorial, EJBCA Community Docker container version 7.11.0 was used.

Before you begin, you need MicroK8s installed and configured. To learn how to install and configure the Kubernetes distribution MicroK8s to deploy the EJBCA container, follow the tutorial Install MicroK8s to run EJBCA.
To issue TLS certificates in a later step, you need to configure EJBCA by following the previous tutorials in this tutorial series Get started with EJBCA and Istio to create a PKI Hierarchy in EJBCA, issue TLS server and client certificates with EJBCA, and create roles in EJBCA.
Additionally, you should be familiar with the YAML format and have a basic understanding of how to use the Kubernetes command line tool kubectl.

Step 1 - Create a namespace and secrets for EJBCA and MariaDB

In Kubernetes, namespaces provide a mechanism for isolating groups of resources within a single cluster and are used in environments with many users spread across multiple teams, or projects. A Kubernetes Secret is an object intended to hold confidential data and 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.

To isolate resources into a group in a Kubernetes cluster and create secrets for the database passwords, follow these steps:

SSH to the MicroK8s server.
In your terminal, enter the following to create a namespace:
CODE
```
$ kubectl create namespace ejbca-k8s
```

Create a secret for the MariaDB root password:

CODE

$ kubectl create secret generic -n ejbca-k8s mariadb-secret --from-literal=mariadb-root-password=ejbca

Create a secret for the EJBCA MariaDB user account:

CODE

$ kubectl create secret generic -n ejbca-k8s ejbca-mariadb-secret --from-literal=ejbca-db-password=ejbca

Step 2 - Create Load Balancer Ingress Service

To configure external access to EJBCA, the Metal LB load balancer is leveraged by creating an Ingress service type.

To create a load balancer Ingress service, follow these steps:

Use a text editor such as vim to create the ingress service file ingress-service.yml:
CODE
```
$ vim ingress-service.yml
```

Add the following to the file:

YML

apiVersion: v1
kind: Service
metadata:
  name: ejbca-node1
  namespace: ingress
spec:
  selector:
    name: nginx-ingress-microk8s
  type: LoadBalancer
  # loadBalancerIP is optional. MetalLB will automatically allocate an IP from its pool if not
  # specified. You can also specify one manually.
  # loadBalancerIP: x.y.z.a
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 80
    - name: https
      protocol: TCP
      port: 443
      targetPort: 443

Save and close the file:
CODE
```
:wq
```
Apply the YAML file to create the Ingress service:
CODE
```
$ kubectl apply -f ingress-service.yml
```
Check what external IP the ingress service is using:
CODE
```
$ kubectl get all,ingress -n ingress
```
Record this IP Address that can be added to the hosts file with the name ejbca-node1 for accessing the EJBCA.

Continue to the next step to create a persistent volume claim for the MariaDB database container.

Step 3 - Create a Persistent Volume Claim for the MariaDB container

To maintain the database state when the MariaDB container is stopped or upgraded, a Persistent Volume Claim (PVC) is used to store the DB data in a persistent storage location. For more information on PVCs, refer to the Kubernetes documentation topic Persistent Volumes.

To create a PVC, follow these steps:

Use a text editor such as vim to create the PVC file ejbca-pvc.yml:
CODE
```
$ vim ejbca-pvc.yml
```

Add the following to the file:

YML

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mariadb-pvc
  namespace: ejbca-k8s
spec:
  accessModes: [ReadWriteOnce]
  resources: { requests: { storage: 100M } }

Save and close the file:
CODE
```
:wq
```
Apply the YAML file to create the PVC:
CODE
```
$ kubectl apply -f ejbca-pvc.yml
```

Continue with creating the services required for accessing the database and EJBCA.

Step 4 - Create services for the database and EJBCA

EJBCA needs to connect to the MariaDB database container. A service is used to allocate an IP address and port for the connection. EJBCA requires a service for Ingress and Apache HTTPD to connect with using AJP.

To create the two services, follow these steps:

Use a text editor such as vim to create the services file ejbca-svc.yml:
CODE
```
$ vim ejbca-svc.yml
```

Add the following to the file:

YML

apiVersion: v1
kind: Service
metadata:
  name: ejbca-database-service
  namespace: ejbca-k8s
  labels:
    app: mariadb
spec:
  type: ClusterIP
  ports:
  - name: database-port
    port: 3306
    targetPort: 3306
  selector:
    app: mariadb
---
apiVersion: v1
kind: Service
metadata:
  name: ejbca-service
  namespace: ejbca-k8s
  labels:
    app: ejbca
spec:
  type: ClusterIP
  ports:
  - name: ajp
    port: 8009
    targetPort: 8009
  selector:
    app: ejbca

Save and close the file:
CODE
```
:wq
```
Apply the YAML file to create the services:
CODE
```
$ kubectl apply -f ejbca-svc.yml
```

The services are now created and you can continue to the next step to deploy the MariaDB container.

Step 5 - Create deployment for the MariaDB container

The EJBCA container supports MariaDB, Microsoft SQL Server, Oracle, and PostgreSQL databases. Deploying the EJBCA container with an external database stores the state and configuration. That means if the EJBCA container is stopped or restarted, the PKI configuration is not lost and requires everything to be configured all over again. A deployment is used to deploy the MariaDB container that will use the PVC and service created in the previous steps.

To deploy MariaDB in a container, follow these steps:

Use a text editor such as vim to create the MariaDB deployment file ejbca-db.yml:
CODE
```
$ vim ejbca-db.yml
```

Add the following to the file:

YML

apiVersion: apps/v1
kind: Deployment # what to create?
metadata:
  name: mariadb-deployment
  namespace: ejbca-k8s
  labels:
    app: mariadb
spec: # specification for deployment resource
  replicas: 1 # how many replicas of pods we want to create
  selector:
    matchLabels:
      app: mariadb
  template: # blueprint for pods
    metadata:
      labels:
        app: mariadb # service will look for this label
    spec: # specification for pods
      volumes:
        - name: datadir
          persistentVolumeClaim:
            claimName: mariadb-pvc
      containers:
      - name: mariadb
        image: mariadb:latest
        ports:
        - containerPort: 3306 #default one
        env:
        - name: MARIADB_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mariadb-secret
              key: mariadb-root-password
        - name: MARIADB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: ejbca-mariadb-secret
              key: ejbca-db-password
        - name: MARIADB_DATABASE
          value: ejbca
        - name: MARIADB_USER
          value: ejbca
        volumeMounts:
        - name: datadir
          mountPath: /var/lib/mysql/

Save and close the file:
CODE
```
:wq
```
Apply the YAML file to create the MariaDB deployment:
CODE
```
$ kubectl apply -f ejbca-db.yml
```

A deployment of MariaDB running in a container is now being deployed. Continue to the next step to deploy the EJBCA container.

Step 6 - Create deployment for the EJBCA container

As the pieces to support deploying EJBCA in Kubernetes were completed in previous steps, it's now time to create a deployment for the EJBCA container.

To deploy the EJBCA container, follow these steps:

Use a text editor such as vim to create the EJBCA deployment file ejbca-ca.yml:
CODE
```
$ vim ejbca-ca.yml
```

Add the following to the file:

YML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ejbca-deployment
  namespace: ejbca-k8s
  labels:
    app: ejbca
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ejbca
  template:
    metadata:
      labels:
        app: ejbca
    spec:
      containers:
        - name: ejbca-node1
          image: keyfactor/ejbca-ce:latest
          imagePullPolicy: Always
          resources:
            limits:
              cpu: "16"
              memory: "4096Mi"
            requests:
              cpu: 1000m
              memory: "2048Mi"
          ports:
            - containerPort: 8009
              name: ejbca-ajp
          env:
            - name: DATABASE_JDBC_URL
              value: "jdbc:mariadb://ejbca-database-service:3306/ejbca?characterEncoding=utf8"
            - name: DATABASE_USER
              value: ejbca
            - name: PROXY_AJP_BIND
              value: "0.0.0.0"  
            - name: DATABASE_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: ejbca-mariadb-secret
                  key: ejbca-db-password
            - name: LOG_AUDIT_TO_DB
              value: "true"

Save and close the file:
CODE
```
:wq
```
Apply the YAML file to create the EJBCA deployment:
CODE
```
$ kubectl apply -f ejbca-ca.yml
```

EJBCA is deploying and the next step is to configure ingress for external access to EJBCA.

Step 7 - Create Ingress for external access to EJBCA

To configure external access to EJBCA using Ingress, follow these steps:

Use a text editor such as vim to create the EJBCA Ingress file ejbca-ingress.yml
CODE
```
$ vim ejbca-ingress.yml
```

Add the following the file:

YML

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    # Use AJP with appserver
    nginx.ingress.kubernetes.io/backend-protocol: AJP
    nginx.ingress.kubernetes.io/auth-tls-verify-client: "optional_no_ca"
    nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream: "true"
  name: ejbca-node1
  namespace: ejbca-k8s
spec:
  ingressClassName: public
  rules:
  - host: ejbca-node1
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: ejbca-service
            port:
              number: 8009
  tls:
  - hosts:
    - ejbca-node1.ejbca-k8s
    secretName: tls-secret

Save and close the file:
CODE
```
:wq
```
Apply the YAML file to create the EJBCA Ingress:
CODE
```
$ kubectl apply -f ejbca-ingress.yml
```

Query the Ingress IP to use for accessing EJBCA:

CODE

$ kubectl -n ingress get services -o json | jq -r '.items[] |.status.loadBalancer?|.ingress[]?|.ip ' | cut -d : -f 2

Create a hosts file entry in /etc/hosts file or applicable file if using a none Linux OS with the IP from step 5. and the hostname ejbca-node1.ejbca-k8s, for example:
CODE
```
# Add to the hosts file:
172.16.170.187 ejbca-node1.ejbca-k8s
```

External access to EJBCA using Ingress is now configured.

Step 8 - Issue TLS certificates for EJBCA external and internal access

The following provides steps for updating the current TLS server end entity profile and certificate profile to use the Management CA and RSA key type. Once updated, two certificates will be issued to use for TLS termination to access EJBCA

Before you begin, you need to configure EJBCA by following the previous tutorials in this tutorials series, Get started with EJBCA and Istio to create a PKI Hierarchy in EJBCA, Issue TLS server and client certificates with EJBCA, and create roles in EJBCA.

To update the profiles and issue the two TLS certificates to use with the MicroK8s EJBCA deployment, follow these steps:

Log in to EJBCA and click Certificate Profiles under CA Functions.
To edit the server profile values to fit your needs, find the TLS Server Profile in the list and click Edit.
On the Edit page, update the following:
- Add RSA to the selection of Available Key Algorithms, ECDSA and RSA should both be selected.
- Select 2040 bits - 4096 bits for the Available Bit Lengths.
- Scroll down to the Available CAs and additionally select ManagementCA, so that ManagementCA and MyPKISubCA-G1 are both selected.
Click Save.
Next, to add the Management CA to the End Entity Profile, click End Entity Profiles under RA Functions.
Select TLS Server Profile, then click Edit End Entity Profile
Scroll down to the Available CAs and additionally select ManagementCA, so that ManagementCA and MyPKISubCA-G1 are both selected.
Click Save.
In EJBCA, click RA Web to access the EJBCA RA UI.
Select Make New Request from the Enroll menu.
For Certificate Type, select your TLS Server Profile.
For CA, select ManagementCA.
For Key-pair generation, select By the CA.
For Key Algorithm, select RSA 2048 bits.
Specify the following information to be used in the certificate:
- For CN, Common Name, specify a name, in this example ejbca-node1.
- For the second DNS Name in the Subject Alternative Name Attributes, specify the full cluster name ejbca-node1.ejbca-k8s.
- For Username, add ejbca-node1 to register the user under the username identical to the common name. The Username is the name that will go into the database and is often the same as the Common Name.
- For Enrollment code, enter a password twice.
- Click Download PEM to download and save the ejbca-node1.pem file.
To create a second internal certificate, scroll up and specify the following information to be used in the certificate:
- For CN, Common Name, specify a name, in this example ejbca-internal.
- For the second DNS Name in the Subject Alternative Name Attributes, specify the full cluster name ejbca-internal.ejbca-k8s.
- For Username, add ejbca-internal to register the user under the username identical to the common name. The Username is the name that will go into the database and is often the same as the Common Name.
- For Enrollment code, enter a password twice.
- Click Download PEM to download and save the ejbca-internal.pem file.

TLS certificates have been issued from the Management CA that will be used to terminate TLS to the EJBCA container. Continue to the steps below to configure these certificates to use.

Step 9 - Create Kubernetes Secret and ConfigMap for the TLS certificates

Next, the two certificates issued in the previous step must be configured to be used with Ingress and Apache HTTPD.

You will create a Kubernetes Secret and ConfigMap for the TLS certificates:

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 are similar to ConfigMaps but are specifically intended to hold confidential data. For more information, refer to the Kubernetes documentation topics Secrets and ConfigMaps.

To prepare Ingress and HTTPD to use certificates issued from EJBCA, follow these steps:

Open a new SSH session to the server.
To create the Kubernetes Secret, create three separate files for the ejbca-node1 certificate, key, and CA certificate:

Open the ejbca-node1.pem file with a text editor of your choice.

To create a server.crt file:

Use a text editor such as vim to create the server.crt file:
CODE
```
$ vim server.crt
```

Add the ejbca-node1 certificate to the file from the ejbca-node1.pem file opened in the text editor. The following shows an example certificate:

CODE

Save and close the file:
CODE
```
:wq
```

To create a server.key file:

Use a text editor such as vim to create the server.key file:
CODE
```
$ vim server.key
```

Add the ejbca-node1 private key to the file from the ejbca-node1.pem file opened in the text editor. The following shows an example private key:

CODE

Save and close the file:
CODE
```
:wq
```

To create a ca.crt file:

Use a text editor such as vim to create the ca.crt file:
CODE
```
$ vim ca.crt
```

Add the Management CA certificate to the file from the ejbca-node1.pem file opened in the text editor. The following shows an example Management CA certificate:

CODE

Save and close the file:
CODE
```
:wq
```

Create Kubernetes Secret for the ejbca-node1 certificate, key, and a secret for the CA certificate file that Ingress will use to terminate TLS to the EJBCA container:

CODE

$ kubectl create secret tls -n ejbca-k8s tls-ejbca-node1 --cert server.crt --key server.key
$ kubectl create secret generic -n ejbca-k8s mtls-trust-chain --from-file=ca.crt=ca.crt

To create the Kubernetes ConfigMap, create two separate files for the ejbca-node1 certificate and key (the CA certificate file ca.crt will be reused for the Management CA certificate).

Open the ejbca-internal.pem file with a text editor.

To create a ejbca-internal.crt file:

Use a text editor such as vim to create the ejbca-internal.crt file:
CODE
```
$ vim ejbca-internal.crt
```

Add the ejbca-internal certificate to the file from the ejbca-internal.pem file opened in the text editor. The following shows an example certificate:

CODE

Save and close the file:
CODE
```
:wq
```

To create a ejbca-internal.key file:

Use a text editor such as vim to create the ejbca-internal.key file:
CODE
```
$ vim ejbca-internal.key
```

Add the ejbca-internal private key to the file from the ejbca-internal.pem file opened in the text editor. The following shows an example private key:

CODE

Save and close the file:
CODE
```
:wq
```

Create a Kubernetes ConfigMap for the ejbca-internal certificate and key, and re-use the CA certificate file created for the Kubernetes Secret (since the certificates are issued off the same CA) to use HTTPD to terminate TLS to the EJBCA container:
CODE
```
$ kubectl -n ejbca-k8s create configmap httpd-certs-configmap --from-file=ejbca-internal.crt=ejbca-internal.crt --from-file=ejbca-internal.key=ejbca-internal.key --from-file=ca.crt=ca.crt
```

The certificates, keys, and Management CA certificate are now configured to use for TLS by Apache HTTPD and Ingress. Continue to the next step to swap the TLS certificate used by Ingress.

Step 10 - Update EJBCA Ingress configuration to use new TLS certificate

Ingress has been using a self-signed certificate for terminating TLS to access the EJBCA CA UI and RA UI. The following outlines how to update the Ingress configuration to use and trust the certificate issued from the EJBCA Management CA.

To change the TLS certificate used by Ingress to access EJBCA, follow these steps:

Use a text editor such as vim to create the EJBCA Mutual TLS (mTLS) Ingress file ejbca-mtls-ingress.yml
CODE
```
$ vim ejbca-mtls-ingress.yml
```

Add the following to the file:

YML

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    # Use AJP with appserver
    nginx.ingress.kubernetes.io/backend-protocol: AJP
    nginx.ingress.kubernetes.io/auth-tls-verify-client: "optional"
    nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream: "true"
    nginx.ingress.kubernetes.io/auth-tls-secret: "ejbca-k8s/mtls-trust-chain"   
  name: ejbca-node1
  namespace: ejbca-k8s
spec:
  ingressClassName: public
  rules:
  - host: ejbca-node1
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: ejbca-service
            port:
              number: 8009
  tls:
  - hosts:
    - ejbca-node1.ejbca-k8s
    secretName: tls-ejbca-node1

Save and close the file:
CODE
```
:wq
```
Remove the current EJBCA Ingress configuration:
CODE
```
$ kubectl delete -f ejbca-ingress.yml
```
Apply the YAML file to create the EJBCA mTLS Ingress:
CODE
```
$ kubectl apply -f ejbca-mtls-ingress.yml
```

Ingress is now using a certificate issued from the EJBCA Management CA. Continue to the next step to deploy and configure Apache HTTPD.

Step 11 - Deploy Apache HTTPD for internal Kubernetes cluster access

Apache HTTPD is used as a reverse proxy to terminate TLS and provide access to EJBCA for internal cluster access. Containers, service mesh, or whatever else needs to access EJBCA within the cluster will use Apache HTTPD.

To deploy and configure Apache HTTPD, follow these steps:

Use a text editor such as vim to create the EJBCA HTTPD file ejbca-httpd.yml
CODE
```
$ vim ejbca-httpd.yml
```

Add the following to the file:

YML

---
apiVersion: v1
kind: Service
metadata:
  name: ejbca-internal
  namespace: ejbca-k8s
  labels:
    app: ejbca-httpd
spec:
  type: ClusterIP
  ports:
  - name: apache
    port: 443
    targetPort: 443
  - name: open
    port: 80
    targetPort: 80
  selector:
    app: ejbca-httpd
---
apiVersion: v1
data:
  httpd.conf: |+
    LoadModule mpm_event_module modules/mod_mpm_event.so
    LoadModule headers_module modules/mod_headers.so
    LoadModule authz_core_module modules/mod_authz_core.so
    LoadModule access_compat_module modules/mod_access_compat.so
    LoadModule log_config_module modules/mod_log_config.so
    LoadModule proxy_module modules/mod_proxy.so
    LoadModule proxy_http_module modules/mod_proxy_http.so
    LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
    LoadModule unixd_module modules/mod_unixd.so
    LoadModule filter_module modules/mod_filter.so
    LoadModule substitute_module modules/mod_substitute.so
    LoadModule rewrite_module modules/mod_rewrite.so
    LoadModule socache_shmcb_module modules/mod_socache_shmcb.so
    LoadModule ssl_module modules/mod_ssl.so
    MaxKeepAliveRequests 1000
    KeepAlive On
    KeepAliveTimeout 180
    # Don't think we need this
    # Include conf/extra/httpd-ssl.conf
    <IfModule unixd_module>
        User daemon
        Group daemon
    </IfModule>
    ErrorLog /proc/self/fd/2
    LogLevel info
    <IfModule log_config_module>
        LogFormat "%h %A:%p %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
        LogFormat "%h %A:%p %l %u %t \"%r\" %>s %b" common
        CustomLog /proc/self/fd/1 common
    </IfModule>
    ServerRoot "/usr/local/apache2"
    Listen 443
    Listen 80
    <Directory />
        AllowOverride none
        Require all denied
    </Directory>
    <VirtualHost *:443>
        DocumentRoot /var/www/html/
        # Disallow any HTTP method that is not HEAD, GET or POST
        RewriteEngine On
        RewriteCond %{REQUEST_METHOD} !^(HEAD|GET|POST|PUT)$ [NC]
        RewriteRule .* - [F,L]
        SSLEngine on
        SSLCipherSuite HIGH:!ADH:!aDSS:!aDH
        SSLProtocol all -SSLv2 -SSLv3 -TLSv1 +TLSv1.2 -TLSv1.3
        # SSLProtocol -all +TLSv1.2
        SSLOptions +ExportCertData +StdEnvVars
        SSLCertificateFile /etc/httpd/ssl/ejbca-internal.crt
        SSLCertificateKeyFile /etc/httpd/ssl/ejbca-internal.key
        SSLVerifyClient optional
        SSLVerifyDepth 3
        SSLCACertificateFile /etc/httpd/ssl/ca.crt
        <Location /ejbca/ejbcaws>
            SSLVerifyClient require
        </Location>
        <Location /ejbca/adminweb>
            SSLVerifyClient require
        </Location>
        # Allow encoded slashes for OCSP GET
        AllowEncodedSlashes On
        ProxyPass /ejbca/        ajp://ejbca-service:8009/ejbca/ keepalive=On ping=500ms retry=1 timeout=300
        #Add ProxyPass for EST and .well-known URLs
        ProxyPass /.well-known/        ajp://ejbca-service:8009/.well-known/ keepalive=On ping=500ms retry=1 timeout=300
        # Redirect /, /ejbca, /signserver and non-proxied URLs to /ejbca/
        RewriteCond %{THE_REQUEST} !(/ejbca/.*|/.well-known/.*)
        RewriteRule (.*) https://%{HTTP_HOST}/ejbca/
    </VirtualHost>
    <VirtualHost *:80>
        DocumentRoot /var/www/html/
        # Disallow any HTTP method that is not HEAD, GET or POST
        RewriteEngine On
        RewriteCond %{REQUEST_METHOD} !^(HEAD|GET|POST)$ [NC]
        RewriteRule .* - [F,L]
        # Redirect legacy EJBCA enrollment to HTTPS
        RewriteCond %{HTTPS} !=on
        RewriteRule ^/?ejbca/enrol/(.*) https://%{SERVER_NAME}/ejbca/enrol/$1 [R,L]
        # Allow encoded slashes for OCSP GET
        AllowEncodedSlashes On
        ProxyPass /ejbca/      ajp://ejbca-service:8009/ejbca/ keepalive=On ping=500ms retry=1 timeout=300 nocanon
        ProxyPass /signserver/ ajp://ejbca-service:8009/signserver/ keepalive=On ping=500ms retry=1 timeout=300
        # Redirect /, /ejbca, /signserver and non-proxied URLs to /ejbca/
        RewriteCond %{THE_REQUEST} !(/signserver/.*|/ejbca/.*) [OR]
        RewriteCond %{THE_REQUEST} (/ejbca/ejbcaws.*)
        RewriteRule (.*) http://%{HTTP_HOST}/ejbca/
        RewriteCond %{THE_REQUEST} (/ejbca/ejbcaws.*|/ejbca/adminweb.*)
        RewriteRule (.*) https://%{HTTP_HOST}/ejbca/
    </VirtualHost>
kind: ConfigMap
metadata:
  namespace: ejbca-k8s
  name: config-httpd-configmap
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ejbca-httpd
  namespace: ejbca-k8s
  labels:
    app: ejbca-httpd
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ejbca-httpd
  template:
    metadata:
      labels:
        app: ejbca-httpd
    spec:
      containers:
        - name: httpd
          image: library/httpd:latest
          ports:
            - containerPort: 443
              name: httpd-http
            - containerPort: 80
              name: http
          volumeMounts:
            - name: config-httpd-volume
              mountPath: /usr/local/apache2/conf/
            - name: certificates-volume
              mountPath: /etc/httpd/ssl
      volumes:
        - name: config-httpd-volume
          configMap:
            name: config-httpd-configmap
        - name: certificates-volume
          configMap:
            name: httpd-certs-configmap

Save and close the file:
CODE
```
:wq
```
Apply the YAML file to deploy and configure the Apache HTTPD container:
CODE
```
$ kubectl apply -f ejbca-httpd.yml
```

Apache HTTPD is now deployed and configured for internal cluster resources to access.

Next steps

In this tutorial, you learned how to deploy EJBCA in MicroK8s using MariaDB as the database and configure access to EJBCA internally and externally.

Here are some next steps we recommend:

To learn how to use a service mesh to issue mutual TLS certificates with EJBCA running in Kubernetes., follow the tutorial Deploy EJBCA container to issue certificates to an Istio service mesh.

If you are interested in EJBCA Enterprise, read more on Keyfactor EJBCA Enterprise.

If you are interested in EJBCA Community, check out EJBCA Community vs Enterprise or read more on ejbca.org.
If you are an EJBCA Enterprise customer and need support, visit the Keyfactor Support Portal.
Discuss with the EJBCA Community on GitHub Discussions.