Helm Chart Installation

To install the KeySafe 5 REST APIs you must install the helm-keysafe5-backend chart.

To install the KeySafe 5 graphical user interface you must also install the helm-keysafe5-ui chart.

To expose these services externally to the Kubernetes cluster, see Configure external access to KeySafe 5.

If you are upgrading an existing KeySafe 5 install, see Helm Chart Upgrade.


Helm is a package manager for Kubernetes.

As with kubectl you can apply a namespace to the Kubernetes resources created by a Helm chart by specifying --namespace my-namespace when using helm.

To install the chart with the release name my-release:

helm install my-release helm-keysafe5-backend/

List all releases using helm list.

To upgrade or modify the existing my-release deployment, configure the chart parameters and then run:

helm upgrade --install my-release helm-keysafe5-backend/

To uninstall or delete the my-release deployment:

helm delete my-release


The keysafe5-backend Helm chart deploys Kubernetes Services for the KeySafe 5 REST APIs.

  • codesafe-mgmt (nShield CodeSafe Management Service API)

  • hsm-mgmt (nShield HSM Management Service API)

  • sw-mgmt (nShield Security World Management Service API)

This Helm chart installs the KeySafe 5 services into a Kubernetes cluster but does not configure external access to the services. See Configure external access to KeySafe 5.

Kubernetes Secrets

The helm-keysafe5-backend Helm chart expects to be provided with pre-existing Kubernetes Secrets for the Database and AMQP connections.

For more information, refer to Kubernetes Secrets.

Purpose Description Secret Type

MongoDB SCRAM Auth

The username and password pairing used to authenticate with the MongoDB server


MongoDB TLS Certificates

TLS certificates used to connect to the MongoDB server. Can also be used as authentication if X509 auth is enabled



The username and password pairing used to authenticate with the AMQP server


AMQP TLS Certificates

TLS certificates used to connect to the AMQP server


Because TLS secrets have the Opaque type, the filenames they are created with are critical. Entrust expects the following:

  • CA certificate to be named ca.crt.

  • TLS certificate to be named tls.crt.

  • TLS key file to be named tls.key.

Your certificates will need to adhere to X.509 v3, sometimes known as a multiple-domain certificates, or SAN certificates. The X.509 extension Subject Alternative Name (SAN) allows specifying multiple hostnames, and has replaced Common Name as the source of the hostname.


To deploy the application, configure the chart with:

  • The Docker images to use for codesafe-mgmt, hsm-mgmt and sw-mgmt.

  • Database connection configuration.

  • Message Bus connection configuration.

  • A reference to the Persistent Volume Claim, in the same Kubernetes namespace, to use for large object storage.

For further details on the configurable values of the Helm chart, see the README.md in the root directory of the Helm chart. For example, you may wish to:

  • Increase or decrease the verbosity of the logging in the backend services.

  • Change the period of time before a resource liveness health check is marked as failing. For example, if you have decreased the rate at which KeySafe 5 agents report to the central platform, you will want to increase the health.livenessFailurePeriod value.

An example install:

helm install my-release \
  --create-namespace --namespace nshieldkeysafe5 \
  --set database.type=mongo \
  --set database.mongo.hosts="mongo-chart-mongodb-0.mongo-chart-mongodb-headless.mongons.svc.cluster.local:27017,mongo-chart-mongodb-1.mongo-chart-mongodb-headless.mongons.svc.cluster.local:27017" \
  --set database.mongo.replicaSet=rs0 \
  --set database.mongo.auth.type=pwd \
  --set database.mongo.auth.existingSecret=my-mongo-credentials-secret \
  --set database.mongo.tls.enabled=true \
  --set database.mongo.tls.existingSecret=my-mongo-tls-secret \
  --set messageBus.URL="rabbit-chart-rabbitmq-0.rabbit-chart-rabbitmq-headless.rabbitns.svc.cluster.local:5671" \
  --set messageBus.auth.type=pwd \
  --set messageBus.auth.existingSecret=my-amqp-credentials-secret \
  --set messageBus.tls.enabled=true \
  --set messageBus.tls.existingSecret=my-amqp-tls-secret \
  --set messageBus.type="amqp"
  --set objectStore.pvc=data-nshield-keysafe5 \
  --set logging.level=info \
  --set logging.format=json \


The keysafe5-ui Helm chart deploys a Kubernetes Service for the KeySafe 5 Graphical User Interface.

The chart deploys the web front-end of KeySafe 5. For the UI to be usable it must point to a deployed KeySafe 5 back-end services endpoint (as installed by helm-keysafe5-backend).

This Helm chart installs the KeySafe 5 UI into a Kubernetes cluster, but does not configure external access to the service. (See Configure external access to KeySafe 5.)


To deploy the application, configure the chart with:

  • The Docker image to use for the ui container.

  • OIDC Identity Provider config, if Authentication is enabled.

  • The location of the KeySafe 5 back-end services API that this UI displays information for.

For further details on the configurable values of the Helm chart, see the README.md in the root directory of the Helm chart.

An example install:

# Untar the chart and copy your OIDC provider config file into the config directory
tar -xf helm-charts/nshield-keysafe5-ui-1.3.0.tgz -C helm-charts
cp my-oidc-provider-config.json helm-charts/nshield-keysafe5-ui/config/OIDCProviders.json

# Install the chart
helm install keysafe5-ui \
  --create-namespace --namespace nshieldkeysafe5 \
  --set svcEndpoint="https://XXX.XXX.XXX.XXX" \
  --set authMethod=oidc \
  --wait --timeout 10m \
Because the OIDC Provider configuration is volume mapped into the Kubernetes application, you must untar the packaged Helm chart so that you can copy in the OIDCProviders.json file to the correct location before installing the chart.

Configure UI authentication

If authMethod is set to oidc then you must provide an OIDC configuration file detailing the accepted Identity Providers.

Copy the OIDC configuration file to config/OIDCProviders.json in the root directory of the Helm chart before installing the Helm chart. This file is a JSON document. You can find an example file at config/OIDCProviders.json.example.

The configuration document is a JSON list of individual provider configurations.

An example of provider configuration:

    "name":"Example Provider",
    "authority": "https://example-auth-provider.com/auth/auth",
    "redirect_uri": "https://example-keysafe5.com/callback",
    "response_type": "code",
    "scope": "openid",
    "post_logout_redirect_uri": "https://example-keysafe5.com/",
    "issuer": "https://example-auth-provider.com/auth",
    "authorization_endpoint": "https://example-auth-provider.com/auth/callback/authorize",
    "token_endpoint": "https://example-auth-provider.com/auth/token",
    "jwks_uri": "https://example-auth-provider.com/auth/keys",
    "end_session_endpoint": "https://example-auth-provider.com/auth/logout",
    "userinfo_endpoint": "https://example-auth-provider.com/auth/userinfo",
    "iconSVG" : "login.svg"

To display a custom icon for the provider in the user interface, copy an SVG-format image to the config directory and reference the file name under the key iconSVG in the provider configuration.

Configure external access to KeySafe 5

To enable external access to the services installed by helm-keysafe5-backend and helm-keysafe5-ui, you need to configure a Kubernetes Ingress Gateway to route requests to the appropriate Kubernetes Services.

If you use Istio, you can use the helm-keysafe5-istio Helm chart to configure an existing Istio Ingress Gateway. Alternatively, you can configure your own Ingress Gateway. (See Configure a custom ingress provider.)


The keysafe5-istio Helm chart creates an Istio Gateway and VirtualService for the KeySafe 5 back-end services and user interface to be accessible externally from the Kubernetes cluster.

The chart:

  • Routes HTTP requests to the KeySafe 5 application running in the same Kubernetes cluster.

  • Authenticates requests, if authentication is enabled (default) and an Identity Provider (IdP) is configured.

  • Applies CORS policy to requests to limit Cross-Origin Resource Sharing.

  • Applies security related HTTP Headers to responses including automatically applying the Content-Security-Policy header to help reduce Cross Site Scripting (XSS) risks.

  • Limits TLS protocol used to TLS v1.2 and higher.

  • Limits ciphers supported by the gateway.

Configure helm-keysafe5-istio

For further details of the configurable values of the Helm chart, see the README.md in the root directory of the Helm chart.

An example install:

helm install keysafe5-istio \
  --create-namespace --namespace=nshieldkeysafe5 \
  --set requireAuthn=true \
  --set httpsEnabled=true \
  --set portNumber=443 \
  --set issuer[0].authIssuer="https://foobar.auth0.com" \
  --set issuer[0].authJWKsURI="https://www.googleapis.com/oauth2/v1/certs" \
  --set issuer[0].authAudiences[0]="https://keysafe5.location" \
  --wait --timeout 1m \

helm-keysafe5-istio port number

If the port number changes to something other than 443 or 80, you need to open a port on the Istio Ingress Gateway. You can do this using your own istioctl install manifest. For more information, refer to https://istio.io/latest/docs/setup/install/istioctl/.

helm-keysafe5-istio authentication

Authentication can be provided by any OpenID Connect Provider, such as Entrust Identity As A Service.

If requireAuthn is true, then at least one authIssuer must be configured.

An example configuration:

  - authIssuer: 'https://foobar.auth0.com'
    authJWKsURI: 'https://www.googleapis.com/oauth2/v1/certs'
    authJWKs: ''
    - 'https://keysafe5.location'

For each authIssuer, authAudiences and one of authJWKsURI or authJWKs must be specified.

Key Description


Identifies the issuer that issued the JWT. A JWT with different iss claim will be rejected.


Identifies the list of JWT audiences that are allowed access. A JWT containing any of these audiences will be accepted.


URL of the provider’s public key set to validate signature of the JWT. For more information, refer to https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata.


JSON Web Key Set of public keys to validate signature of the JWT. For more information, refer to https://auth0.com/docs/jwks.

Once authenticated, a user has full access to view and manage the HSM and Security World resources accessible from the platform. No authorization policy is applied to requests.

Enable HTTPS for helm-keysafe5-istio

Configuring a TLS certificate for the Istio Gateway requires creating a Kubernetes secret.

To create a Kubernetes secret from an existing TLS private key and certificate:

You must create the Kubernetes Secret in the same namespace as the Istio Ingress Gateway.
kubectl --namespace istio-system create secret tls keysafe5-server-credential \
  --cert=path/to/cert/file \

Configure a custom ingress provider

If you do not want to use Istio, you can configure your own Kubernetes Ingress.

If you configure your own Ingress to the application, then it is your responsibility to configure routing to the services and any authentication or authorization to access the services.

Each part of the KeySafe 5 application is exposed as a Kubernetes Service.

helm-keysafe5-backend exposes the following Kubernetes Services for serving requests to the RESTful APIs:

ClusterIP Port API endpoints










helm-keysafe5-ui exposes a Kubernetes Service called keysafe5-ui-svc on ClusterIP port 8080 for accessing the graphical user interface of KeySafe 5.