Page Comparison

helm repo add digitalroute https://digitalroute-public.github.io/usage-engine-private-edition

docker login -u AWS \
-p $(AWS_ACCESS_KEY_ID=<your aws access key> AWS_SECRET_ACCESS_KEY=<your aws secret access key> aws ecr get-login-password --region eu-west-1) \
462803626708.dkr.ecr.eu-west-1.amazonaws.com

kubectl create secret docker

-registry ecr-cred \
    --docker-server=https://462803626708.dkr.ecr.eu-west-1.amazonaws.com

docker pull 462803626708.dkr.ecr.eu-west-1.amazonaws.com/usage-engine-private-edition:<version>-operator

UI image:

  \
    --docker-username=AWS \
    --docker-password=$(AWS_ACCESS_KEY_ID=<your aws access key> AWS_SECRET_ACCESS_KEY=<your aws secret access key> aws ecr get-login-password --region eu-west-1) \
    -n <namespace>

Where <your aws access key> and <your aws secret access key> are the access keys provided by Digital Route (see https://infozone.atlassian.net/wiki/spaces/UEPE4D/pages/161481605/Common+Pre-requisites#ECR-Access-Keys in case you have not received any access keys yet).

System Database

Anchor
system-database-preparations system-database-preparations

The Usage Engine Private Edition helm chart is capable of automatically creating the system database at install time. However, that assumes that you are able to supply database administrator credentials (see Bootstrapping System Credentials).

If, for one reason or another, you are unable to supply that, the system database must be created manually prior to installing the Usage Engine Private Edition helm chart.

A tool called uepe-sys-db-tool.jar is provided to facilitate this.

To use it, simply go to Release Information, download it for the relevant version, and then execute it like this:

java -jar uepe-sys-db-tool.jar

The instructions on screen will guide you through the process of configuring the database, and once done, a set of database scripts will be generated. These database scripts can then be used to create the system database.

TLS

Anchor
tls-preparations tls-preparations

It is recommended to install Usage Engine Private Edition with TLS enabled, and there are two different ways of providing the required certificate:

• Cert-manager

• Secret

Here follows an explanation of the preparations required for each of the two.

Cert-manager

The most automated and secure way to provide the certificate is to use cert-manager.

If it is not already installed in your Kubernetes cluster, follow these instructions on how to install cert-manager.

Cert-manager must be backed by a certificate authority (CA) to sign the certificates. Once configured with a CA, cert-manager will automatically sign and renew certificates for the system as needed. Configuring cert-manager with a CA is done by creating an Issuer or ClusterIssuer resource (this resource will be referenced later when installing Usage Engine Private Edition).

Refer to Configuring Issuers for a all the details.

It’s also possible to use an issuer specifiction that will issue a self-signed certificate:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: example-issuer
spec:
  selfSigned: {}

Note that this is only recommended for testing purposes and not in production.

Regardless of the chosen issuer specification, to create the issuer, simply put the specification in a yaml file (here we call it example-issuer.yaml), and then execute a command like this:

kubectl apply -f example-issuer.yaml

Based on the example above the created ClusterIssuer can be inspected like this:

kubectl get clusterissuers example-issuer -o yaml

Secret

If you do not want to automate the certificate provisioning with cert-manager, you can instead manually install a public certificate in a Kubernetes Secret and then refer to that when installing Usage Engine Private Edition.

The Secret must include a keystore file (keystore.jks) in JKS format as well as separate files for key (tls.key) and certificate (tls.crt).

This is an example script that can generate a Secret like that (make sure to set the parameters at the beginning of the script before executing it):

#!/bin/sh
KEY_PASSWORD=<your chosen key password>
STORE_PASSWORD=<your chosen keystore password>
DNAME=CN=exampledomain.com,O=Example
NAMESPACE=<namespace>
keytool -genkey -keystore keystore.jks -storepass $STORE_PASSWORD -keypass $KEY_PASSWORD -alias certificate -keyalg RSA -keysize 4096 -dname $DNAME
keytool -importkeystore -srckeystore keystore.jks -srcstorepass $STORE_PASSWORD -srckeypass $KEY_PASSWORD -destkeystore keystore.p12 -deststoretype PKCS12 -srcalias certificate -deststorepass $STORE_PASSWORD -destkeypass $KEY_PASSWORD
openssl pkcs12 -in keystore.p12  -nokeys -out tls.crt -password pass:$KEY_PASSWORD
openssl pkcs12 -in keystore.p12  -nodes -nocerts -out tls.key -password pass:$KEY_PASSWORD
kubectl create secret generic uepe-cert -n $NAMESPACE --from-file=keystore.jks --from-file=tls.key --from-file=tls.crt

Note that this will generate a self-signed certificate, which is not suitable for use in publicly exposed interfaces.

Once the Secret has been generated, its content can be inspected like this:

kubectl -n <namespace> get secrets uepe-cert -o yaml

Bootstrapping System Credentials

Anchor
bootstrapping-system-credentials bootstrapping-system-credentials

Usage Engine Private Edition uses a number of system credentials in order to function as expected.

These system credentials are kept in a Kubernetes secret called env-secrets located in the same namespace as where Usage Engine Private Edition is being installed.

This secret can be populated in three different ways:

• Manually creating and populating it prior to installing Usage Engine Private Edition.

• Providing the credential(s) as helm values at install time. In which case the secret will be automatically created (if it does not already exist) and populated with the corresponding helm value(s). Be aware that storing credentials in a values.yaml file in version control is not secure. If you still need to do this you should consider using tools like https://github.com/mozilla/sops .

• Letting it be automatically populated at install time. In which case the secret will be automatically created and populated. Passwords will consist of eight randomly generated characters.

Note that the three options are not mutually exclusive. It is possible to populate some credentials in advance, some through helm values, and let some be automatically generated.

Here follows an explanation of the system credentials used by Usage Engine Private Edition:

This is an example of how to create and populate the secret with some credentials:

kubectl create secret generic env-secrets -n <namespace> \
--from-literal=jdbcPassword=<your chosen jdbc password> \
--from-literal=mzownerPassword=<your chosen mzowner password>

To inspect the content of the secret, simply execute the following command:

kubectl get secret/env-secrets -n <namespace> -o yaml

To retrieve a given credential in cleartext, simply execute a command like this:

kubectl get secrets/env-secrets -n <namespace> --template={{.data.jdbcPassword}} | base64 -d