- PrivX requires PostgreSQL server version to >= 11.X. Before installing/upgrading to PrivX 35.0, please make sure that a supported PostgreSQL server version is used. For more information and supported helm variables, please check here.
privx-kube is a means to deploy PrivX in a kubernetes cluster.
This repo contains the PrivX helm chart that can be used to deploy the supported versions of PrivX on Kubernetes.
For more information on PrivX, please find the documentation here. An architecture diagram for PrivX on Kubernetes can be found here.
For a list of Kubernetes resources that are deployed, please check here.
- Kubernetes >= 1.20
- Kubectl >= 1.20
- Helm >= 3.6.3
- Volume/Storage requirements as described below
PrivX depends on its different components to be able to share storage for it to work correctly. For this reason, it is important that a choice for storage is made in such a way so that the following requirement is fulfilled:
This is required because it allows the PrivX pods to be able to share storage
and at the same time, the pods can be on different nodes in the cluster, which
allows for PrivX to be scalable in Highly Available (HA) fashion.
If for any reason, ReadWriteMany access mode is not available, the next best
option is to have the ReadWriteOnce access mode for the storage. The only
downside to this is that all the pods in a PrivX deployment would have to be
co-located in a single node. This makes it prone to failure if the node goes
down and manual intervention will be needed and possible loss of data.
The helm chart for PrivX makes a few assumptions and those have to be in place for PrivX to work.
As in any kubernetes cluster, a gateway or ingress is required to reach the application. PrivX uses Bitnami Nginx Ingress Controller as the ingress controller.
NOTE: Please keep this information in mind if an Ingress Controller or a similar component other than the one mentioned above is used.
The purpose of the ingress controller is to setup ingress to the PrivX microservices in a dynamic way. privx-kube provides an override file ingress.yaml with extra settings for deploying the Bitnami nginx ingress controller. The purpose of the file is to provide settings that are crucial to the workings of PrivX.
Depending on the type of Kubernetes cluster, this file might require further settings (e.g Load balancer settings). But the main requirement after installing the ingress controller is that it should be accessible for the clients that would end up using PrivX.
The installation of the Ingress Controller is tested to work on Kubernetes Server v1.24. Please be advised that new releases of the Kubernetes Server or Ingress Controller may cause some of these instructions to fail. Always consult the upstream Ingress Controller repo to make sure that the values are correct.
An Example installation instruction (Please update to a more secure version if available):
helm repo add bitnami https://charts.bitnami.com/bitnami
helm install \
-n ingress --create-namespace \
-f values-overrides/ingress.yaml \
--version 11.6.12 \
ingress bitnami/nginx-ingress-controller
Up to date instructions on new releases and any breaking changes can be found in the original repo.
PrivX uses Postgres database for relational transactions and internal notifications. Therefore, it is important that a database is available either internally in the cluster or outside of the cluster.
Once the database is present, the following values in the file privx.yaml should be changed for privx to be able to reach and interact with the database.
- db.address (database address) [mandatory]
- db.port (database port) [mandatory]
- db.name (database name) [mandatory]
- db.sslmode (database sslmode) [optional: default value=`verify-full`]
- db.sslDBcertificate (database string certificate) [mandatory if db.sslmode is `verify-full` or `verify-ca` and certificate file is not uploaded and the certificate is not inherently trusted]
- db.admin.createDB (true: create db.name, false: skip) [optional: default value=`true`]
- db.admin.createDBUser (true: create db.user, false: skip) [optional: default value=`true`]
- db.admin.name (database admin username) [mandatory if either db.admin.createDB or db.admin.createDBUser is true]
- db.admin.password (database admin password) [mandatory if either db.admin.createDB or db.admin.createDBUser is true]
- db.user.name (database privx user) [mandatory]
- db.user.password (database privx user password) [mandatory]
NOTE: The values db.sslmode and db.sslDBcertificate are important to setup correctly. More details on how to use these can be found here.
PrivX should be deployed in the privx namespace. To create the namespace, do
the following:
kubectl create namespace privx
PrivX assumes that at least two kubernetes secrets with specific certificates
are present in the privx namespace.
privx-tls(Used for storing server certificate for HTTPS Ingress)privx-ca-secret(Used for storing CA certificate that issued the server certificate)
The first certificate can be valid for a short duration and is used for securing
the ingress endpoints. The purpose of the second certificate is to be valid for
a longer duration so that any clients that rely on proxies and extenders can
utilize it for a long-living configuration. The value ingress.common.hosts[*].host in
the file privx.yaml must be changed to the
domain(s) that these certificates are issued for.
To create privx-tls use the following command:
kubectl create secret tls privx-tls \
--cert=<Path to cert file> \
--key=<Path to key file> \
--namespace privx
To create privx-ca-secret use the following command:
kubectl create secret generic privx-ca-secret \
--from-file=ca.crt=<Path to ca cert file> \
--namespace privx
NOTE: The names of the secrets should match exactly
PrivX assumes that a volume claim named privx-claim be present with
ReadWrite(Once/Many) access.
NOTE: The names of the volume claim should match exactly
The value for ms.licensemanager.licenseCode.prod.value in the file
privx.yaml should be changed to a
valid license value. NOTE: If offline licenses are used, then please wait
for more instructions as support for that is still under work.
The values for the following are mandatory and need to be set before installing PrivX in the file privx.yaml.
- privx.admin.username (admin username for PrivX UI login)
- privx.admin.password (admin password for PrivX UI login)
- privx.admin.email (admin email for PrivX UI login)
By default, PrivX containers are runing under User ID (uid) and Group ID (gid) 5111. To run containers under a custom uid/gid, customize the following values in charts/privx/values.yaml:
- podSecurityContext.fsGroup (Custom gid)
- podSecurityContext.runAsUser (Custom uid)
- securityContext.runAsUser (Custom uid)
To install PrivX use the following command:
helm install \
-f values-overrides/privx.yaml \
--namespace privx \
privx charts/privx/
For upgrading privx to the current version, follow the instructions here