Prerequisites

The following table contains the required software version that this release of KeySafe 5 has been tested on and any minimum version requirements.

In addition to the set of required software, this release of KeySafe 5 requires an external identity provider that supports OIDC and OAuth2 for user and machine authentication.

Software	Minimum version	Tested version
Kubernetes	-	1.22
MongoDB	4.0	4.4.12
RabbitMQ	3.0	3.9.13

Optional Software

KeySafe 5 is shipped with a Helm chart that configures an Istio Ingress Gateway to provide external access to the KeySafe 5 application running in Kubernetes. Other Ingress Gateways can be used, see Helm Chart Installation: Configure a customer ingress provider.

Software	Minimum version	Tested version
Istio	-	1.13

Software

Minimum version

Tested version

Istio

1.13

Kubernetes cluster

KeySafe 5 has been tested on Kubernetes version 1.22

Using namespaces

When deploying an application to a Kubernetes cluster that is shared with many users spread across multiple teams, Entrust recommends using Namespaces to isolate groups of resources.

To create a namespace for the KeySafe 5 application:

$ kubectl create namespace nshieldkeysafe5
namespace/nshieldkeysafe5 created

To set the namespace for a current request, use the --namespace flag. For example:

$ helm install --namespace=nshieldkeysafe5 my-release helm-keysafe5-backend/
$ kubectl --namespace=nshieldkeysafe5 get pods

If you are using Istio in your Kubernetes cluster, beyond acting as an API Gateway for KeySafe 5, you might also want to configure Istio injection for this Kubernetes namespace to take advantage of other Istio features. This step is not required for KeySafe 5 to function.

$ kubectl label namespace nshieldkeysafe5 istio-injection=enabled
namespace/nshieldkeysafe5 labeled

MongoDB

MongoDB is the persistent data store for the KeySafe 5 application data. Any sensitive Security World data stored in the database is stored in standard nShield encrypted blobs. You should restrict access to this database in the same way that you would normally restrict access to the Key Management Data directory on an nShield client machine.

The MongoDB used must be a Replica Set.

If you have an existing MongoDB database you can configure the application to use this, otherwise you must securely deploy a MongoDB instance.

Entrust recommend that you configure MongoDB with authentication enabled and TLS enabled and with RBAC configured. The database user for KeySafe 5 should be given the minimum capabilities required, see Database: User Roles.

Bitnami MongoDB Helm chart

To install MongoDB in the same Kubernetes cluster as the KeySafe 5 application, you can install the Bitnami MongoDB Helm chart

$ helm repo add bitnami https://charts.bitnami.com/bitnami
$ helm install mongo-chart \
 --set image.tag=4.4.12 \
 --set architecture=replicaset \
 --set auth.enabled=true \
 --set tls.enabled=true \
 --set tls.existingSecret=my-mongo-tls-secret \
bitnami/mongodb --version 11.1.10

KeySafe 5 has been tested with version 11.1.10 of the Bitnami MongoDB Helm Chart.

Monitor MongoDB for security vulnerabilities and regularly update the version of MongoDB installed to apply any required updates.

RabbitMQ

You need a RabbitMQ message bus for the interprocess communication between the KeySafe 5 backend services and keysafe5-agent instances running on nShield client machines.

If you have an existing RabbitMQ instance you can configure the application to use this, otherwise you must securely deploy a RabbitMQ instance.

Entrust recommend that you configure RabbitMQ with authentication enabled and TLS enabled. If the RabbitMQ instance being used is shared with other applications, then a dedicated virtual host should be created for the KeySafe 5 application. The RabbitMQ user used for KeySafe 5 should only have access to that specific virtual host.

Bitnami RabbitMQ Helm chart

To install RabbitMQ in the same Kubernetes cluster as the KeySafe 5 application, you can install the Bitnami RabbitMQ Helm chart.

$ helm repo add bitnami https://charts.bitnami.com/bitnami
$ helm install rabbit-chart \
 --set image.tag=3.9.13 \
 --set auth.username=user \
 --set auth.existingPasswordSecret=my-password-secret \
 --set auth.tls.enabled=true \
 --set auth.tls.existingSecret=my-rabbitmq-tls-secret \
bitnami/rabbitmq --version 8.32.1

KeySafe 5 has been tested with version 8.32.1 of the Bitnami RabbitMQ Helm Chart.

Monitor RabbitMQ for security vulnerabilities and regularly update the version of RabbitMQ installed to apply any required updates.

External identity provider (IdP)

You need an external identity provider that supports OIDC and OAuth2 to provide user and machine authentication to KeySafe 5. This is required to gain access to the UI and authenticate commands sent to the backend services.

At the IdP, Entrust typically expects the following to be configured:

A single OIDC public client application

This provides user identity information and an id_token for use by the UI
Multiple OAuth2 private client application

This provides machine-to-machine credentials. Typically you would want an instance of this per application identity required to limit the sharing of the client_secret value.

For more information, refer to Client Types.

OIDC public client

The OIDC public client application provides user identity information and an id_token for use by the UI in its calls to the backend services. It is a public client due to the UI being a client side application, and as such cannot be trusted with the client_secret like a server side application would be.

Entrust recommends the following settings:

Setting	Value
Grant Types	Authorization Code with PKCE
Refresh Token
Authorization Code PKCE Code Challenge Method	S256
Scopes	openid

Setting

Value

Grant Types

Authorization Code with PKCE

Refresh Token

Authorization Code PKCE Code Challenge Method

S256

Scopes

openid

For more information, refer to Authorization Code flow with PKCE.

OAuth2 private client

The OAUTH2 private client provides client credentialing for machine-to-machine authentication by applications that do not hold user identification. This requires the use of the client_secret value, which must be securely held.

You would typically want a separate private client instance for each application for which you provide access, resulting in a separate client_id and client_secret for each application. This eases management of the client_secret by reducing the number of application that have knowledge of it. It also provides easy identification of which application is doing what at the KeySafe 5 end.

Entrust recommend the following settings:

Setting	Value
Grant Type	Client Credentials

Setting

Value

Grant Type

Client Credentials

For more information, refer to Client Credentials.