When deploying a PKI, whether it is a single centralized PKI, multiple distributed PKIs, or perhaps short-lived PKIs for specific purposes, it is suitable to do so using the same tools and processes used for the rest of your environment. Two common tools used are Ansible and Kubernetes and EJBCA plays well with both.
The following covers how to deploy your PKI as VMs or containers and how to use Ansible to automate PKI deployment and configuration
Deploying Your PKI as VMs or Containers
The PKI, while in many cases being a central service consumed by other application teams, can itself run in any infrastructure preferred by your organization. In addition to the more traditional deployment methods, your PKI products can also be consumed in virtualization environments should your organization prefer such a deployment option.
Examples of classic deployment options:
- On-premise software, our Solution Platform, allowing you to install the software with full flexibility.
- On-premise hardware, our Hardware Appliance, allowing you to run a secure PKI including a built-in Hardware Security Module (HSM), as a turn-key solution including all required software and hardware.
- Cloud, allowing you to deploy PKI and signature solutions in your AWS or Azure cloud environment.
Examples of PKI products consumed in virtualization environments:
- Software Appliance, self-sustained, packaged virtual machine (VM), utilizing your existing virtualization environment, connecting to network-attached Hardware Security Modules (HSMs).
- Docker Container, allowing you to deploy PKI in your container infrastructure, with the full flexibility (and complexity) expected from containerized environments.
Deploying PKI in Kubernetes and OpenShift
Kubernetes has gained massive popularity as the most common container runtime/orchestrator, with on-premise installations as well as cloud service offerings. If your IT infrastructure is based around containers, your PKI can typically also be run in a container runtime given that you have considered the security aspects. Running the PKI or digital signature solution as containers can be streamlined and can also be combined with Ansible for automation and parameterized configuration.
EJBCA Community and SignServer Community are available for immediate deployment from Docker Hub, allowing you to get a test PKI or digital signature solution up in a few seconds. For more information and community container downloads, refer to EJBCA on Docker Hub and SignServer on Docker Hub.
To customize more complex, best practices deployments in Kubernetes, PrimeKey provides container deployment examples with ready-to-use YAML files for MicroK8s and Docker-engine, setting up separate containers for the database, EJBCA, and Ingres. For container deployment examples, refer to Keyfactor GitHub.
This technology is also used to deploy and run EJBCA in Red Hat OpenShift. Red Hat OpenShift is an enterprise-ready Kubernetes platform assembled using vetted components supporting developers manage cloud deployments. EJBCA community edition is available in the trusted Red Hat container catalog, contact Keyfactor for more information.
For the container versions of the Enterprise edition of EJBCA, please contact Keyfactor.
Adding Your HSM PKCS#11 Drivers to Container Image
Many organizations already have HSMs in place, often with skilled specialist teams managing these HSMs. The HSM PKCS#11 drivers used may be specifically approved versions, thoroughly tested with the HSM firmware version deployed. It is therefore difficult to by default include the correct drivers for specific users in containers. Additionally, HSM drivers are distributed under license from the manufacturer, meaning that it may not be permitted to re-distribute drivers integrated with our containers.
This creates a need to be able to add specific HSM drivers to pre-packaged containers in a straightforward way. For information on adding HSM drivers on top of the EJBCA container using a Dockerfile, refer to HSM driver examples on Keyfactor GitHub.
Using Ansible to Automate PKI Deployment and Configuration
Red Hat provides an open source automation tool, Ansible, that enables efficient and secure provisioning, configuration management, and deployment of software and containers. Ansible is a popular tool for automating deployment and configuration in Dev(Sec)Ops environments. With Ansible you write Ansible Playbooks that perform automated tasks, repeatable, parameterized, and idempotent.
From a PKI perspective, you can use Ansible for several tasks, including:
Deploy the PKI and/or digital signature solutions. When a CA needs to be set up, this can be done in seconds using an Ansible playbook, according to your playbook with the parameters needed for the specific deployment. A PKI hierarchy, with one or several CA's, can be fully configured, using pre-tested templated configurations. The configured PKI server(s), be it VMs or containers, can also be deployed automatically in your virtualization or container runtime environment.
When deploying application services, using Ansible, these services can automatically be provisioned with the correct machine identities (certificates) as they are automatically deployed to your VM or container runtime. During the configuration of the services, the Ansible playbook will contain steps to enroll unique machine identities for the application servers being instantiated.
Internally at PrimeKey, we use Ansible to set up specific versions and configurations, for example different databases and Java versions, of EJBCA and SignServer for testing. The VMs are automatically deployed to an internal virtualization environment, making a specific configuration available for tests in a matter of seconds.
We provide a collection of Ansible playbooks to use with EJBCA, SignServer, and integrations. Both Community and Enterprise versions of EJBCA are supported. Using these Ansible playbooks, you can easily get EJBCA or SignServer up and running, including a complete technology stack. For more information, refer to Keyfactor GitHub/Ansible. For additional EJBCA example tools scripts, refer to Keyfactor GitHub/Scripts.