Installation
In this guide, you will set up nevisAdmin 4 on an existing Kubernetes cluster.
If you don't have a cluster yet, or need to prepare an Oracle volume, see Preparation first. See Restrictions in Kubernetes Setups for limitations specific to Kubernetes.
For a quick, automated test setup instead, see Test Setups, covering Azure and OpenShift. These are not recommended beyond test setups, as they make several assumptions.
We tested the installation with Azure, but other providers may work as well. For details about supported providers and versions, see Kubernetes Support Policy for Nevis.
Pay attention to the following:
- nevisAdmin 4 requires between 4 GB and 16 GB of RAM and between 2 and 6 CPU cores, depending on project size and how many deployments/edits happen concurrently.
- For the database, we recommend using PostgreSQL server, especially since support for MariaDB got removed in Azure. Use a database service whenever possible, especially for end user facing components. See the Nevis Product Lifetime and Platform Support Matrix for supported database versions.
- In some Kubernetes installations, special permission settings or entitlements are required, for example, for the
ingress-nginxcomponent.
Prerequisites
- Have an existing Kubernetes cluster and enough permissions to create resource groups and resources, which includes RBAC permissions.
- The installation of the crds, ingress-nginx and the cert-manager component needs cluster-wide permissions, for the rest, namespace scoped permissions are enough.
- If using MariaDB as a database, the following server configuration is needed:
autocommit=0
transaction-isolation = READ-COMMITTED
log_bin_trust_function_creators = 1
lower_case_table_names = 1
character-set-server = utf8mb4
- A Linux environment with the following software pre-installed:
kubectl: Kubernetes command line interface. The same minor version is recommended as the used Kubernetes version.docker: Docker client.helm: Helm CLI
This guide requires basic knowledge of Linux and Kubernetes. If you are new to these topics, we recommend that you see tutorials or courses available online. If you have limited time, focus on Kubernetes tutorials, for example, Viewing Pods and Nodes.
Prepare Git Deployment Repository
In this tutorial, we use GitHub as the Git system. However, it is possible to use Bitbucket, Gitea, GitLab and more instead. The same options should be available in every case.
To configure the Git connection for nevisOperator, perform the following steps:
-
Prepare GitHub.
- Create a GitHub account.
- Create an empty Git repository called
deploy. - Set the GitHub repository to private. See https://help.github.com/en/articles/setting-repository-visibility#making-a-repository-private for detailed instructions
-
Create the SSH key material through the following commands:
#generate key pairssh-keygen -t ecdsa -C "kubernetes" -m PEM -P "" -f key# create know_hosts file, replace the github domain if other Git system is usedssh-keyscan github.com > known_hosts# make sure ssh keys were generatedcat keycat key.pubThe created key is used by both nevisOperator and nevisAdmin 4 to connect to GitHub.
-
Add the key
key.pubto your GitHub account, or to the repository itself as a deployment key.
- See http://help.github.com/en/articles/adding-a-new-ssh-key-to-your-github-account.
- See the Deploy keys section in http://developer.github.com/v3/guides/managing-deploy-keys
Set environment variables
The remaining steps use the following environment variables:
| Variable | Default | Description |
|---|---|---|
NEVISADMIN_PASSWORD | — | Initial password for the nevisAdmin 4 admin user. |
NEVIS_VERSION | — | Release version to install, for example 9.2605.2. Find the latest one on the Nevis Portal download page or in the nevisAdmin 4 release notes. Used both for the image sync below and for the --version flag on the chart installs further down, so images and chart stay in sync. |
CONTAINER_REGISTRY | — | Container registry of your Kubernetes cluster. Azure registries use a flat URL, for example nevis.azurecr.io. |
RELEASE_NAMESPACE | nevisadmin4 | Kubernetes namespace the Helm chart is installed into. You usually do not need to change this. |
RELEASE_NAME | nevisadmin4 | Name of the Helm release. You usually do not need to change this. |
DATABASE_HOST | — | Database host, for example nevisakvtest.postgres.database.azure.com for PostgreSQL. |
DB_ROOT_USER | dbroot | Root/administrator user of the database. If you are using an Azure database, do not include the host in the username. |
DB_ROOT_PASSWORD | — | Password for DB_ROOT_USER. If you used the nevis-kubernetes-support Terraform template to create the database, retrieve it with terraform output db_password. Otherwise, ask your database administrator or check your cloud provider's console. |
DB_NEVISADMIN_SCHEMA_USER_PASSWORD | — | Password for the nevisAdmin 4 schema user, which is created during installation. |
DB_NEVISADMIN_APP_USER_PASSWORD | — | Password for the nevisAdmin 4 application user, which is created during installation. |
GIT_REPOSITORY_URL | — | URL of the Git deployment repository nevisAdmin 4 and nevisOperator will use. |
DOMAIN | — | Domain where nevisAdmin 4 will be available, for example test.westeurope.cloudapp.azure.com. The chart requires this value at install or upgrade time. Pick your domain first, then wire up DNS after installing the gateway. |
CLOUDSMITH_PASSWORD | — | Temporary Cloudsmith credential used to pull the Nevis Helm charts and Docker images. Obtain it by clicking the download button for one of the Docker images at the Nevis Portal. |
Upload Nevis Docker Images
Download the docker images from the Nevis Portal registry and upload them to the container registry of the Kubernetes cluster.
export NEVIS_VERSION=<the version you picked, for example 9.2605.2>
The sync-images.sh script in the nevis-kubernetes-support repository automates the upload: it pulls each image from Cloudsmith (or GitHub Container Registry) and pushes it to your target registry.
./sync-images.sh --source cloudsmith --token $CLOUDSMITH_PASSWORD --target $CONTAINER_REGISTRY --version $NEVIS_VERSION
-
$CLOUDSMITH_PASSWORDobtained this way is a temporary token. If pulls or pushes suddenly start failing withunauthorizedor400 Bad Requestpartway through, the token has likely expired — get a fresh one from the portal and retry. -
Not every component image is tagged with the same version string as the overall release — a component still on an older tag will fail with
manifest unknown. If you do not need that component yet (it is not part of the base nevisAdmin4 install, and only gets pulled in later by nevisOperator once a project uses it), skip it:./sync-images.sh --source cloudsmith --token $CLOUDSMITH_PASSWORD --target $CONTAINER_REGISTRY --version $NEVIS_VERSION \--skip-images nevislogrend nevisfido nevisfido-dbschema nevisidm nevisidm-dbschema nevismeta nevismeta-dbschema \nevisadapt nevisadapt-dbschema nevisdetect-admin nevisdetect-core nevisdetect-entrypoint nevisdetect-persistency \nevisdetect-persistency-dbschema nevisdp nevis-base-flywayOtherwise, use
--tags <image>:<tag>to pin the correct tag for that component. The script still processes every non-skipped image, so preserve the previous--skip-imageslist and remove the target component from it. -
Individual Nevis components can ship patch releases independently of the overall release. The image tag that nevisOperator will actually request when deploying a component is determined by the patterns plugin, not by
$NEVIS_VERSION. If a deploy fails because nevisOperator tries to pull an image that is not in your registry — for examplenevisidm:9.2605.3when you synced9.2605.2— rerun the sync with an override for that component. Preserve the previous--skip-imageslist and removenevisidmfrom it:./sync-images.sh --source cloudsmith --token $CLOUDSMITH_PASSWORD --target $CONTAINER_REGISTRY \--version $NEVIS_VERSION --tags nevisidm:9.2605.3 \--skip-images nevislogrend nevisfido nevisfido-dbschema nevisidm-dbschema nevismeta nevismeta-dbschema \nevisadapt nevisadapt-dbschema nevisdetect-admin nevisdetect-core nevisdetect-entrypoint nevisdetect-persistency \nevisdetect-persistency-dbschema nevisdp nevis-base-flywayThe exact version required can be seen in the deployment preview inside the
NevisComponentresource associated with the service in nevisAdmin 4, or inferred from the image pull error in the deployment log.
Deploy Envoy Gateway
Envoy Gateway is the recommended external routing solution for new installations. ingress-nginx reached end-of-life in March 2026 and no longer receives feature or security updates — only use it if you have a specific reason to stay on it for now, see Deploy ingress-nginx below.
At least Envoy Gateway 1.6.0 is required. Use a current, supported, non-EOL release; 1.6.0 itself is EOL. Check the Envoy Gateway releases page for the latest supported version and use it in the install command:
helm install eg oci://docker.io/envoyproxy/gateway-helm \
--version <envoy-gateway-version> \
--namespace envoy-gateway-system \
--create-namespace
After the installation, create a GatewayClass and an EnvoyProxy configuration resource. The EnvoyProxy is recommended to merge all gateways into a single proxy (avoiding multiple load balancers) and to enforce TLS 1.3 toward backend nevisProxy instances.
The Envoy Gateway namespace is configurable. The installation script uses envoy by default, while the commands and examples below use the namespace configured for your installation; adjust namespace-qualified commands and YAML resources if you choose a different namespace.
Please note that using Envoy Gateway requires TLS 1.3 toward the backend nevisProxy instance. This is enforced globally in the same EnvoyProxy resource:
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyProxy
metadata:
name: gateway-config
namespace: envoy-gateway-system
spec:
logging:
level:
default: warn
mergeGateways: true
backendTLS:
maxVersion: "1.3"
minVersion: "1.3"
---
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
name: envoy-gateway
spec:
controllerName: gateway.envoyproxy.io/gatewayclass-controller
parametersRef:
group: gateway.envoyproxy.io
kind: EnvoyProxy
name: gateway-config
namespace: envoy-gateway-system
Apply it with kubectl apply -f <file>. For more EnvoyProxy configuration options, see Customize EnvoyProxy.
Gateway support was introduced in nevisAdmin4 chart versions 8.2511.3 and 7.2511.3. Versions below 9.2605.0 still use the ingress API with ingress-nginx by default, so the nevisadmin4 chart values have to be set explicitly to use Envoy Gateway instead — see the Install nevisAdmin 4 Chart section.
Deploy cert-manager
If the Kubernetes cluster does not have cert-manager already installed, then follow the official guide: https://cert-manager.io/docs/installation/helm/
Gateway API support is required when using Envoy Gateway. Without it, cert-manager cannot perform HTTP-01 challenges via a Gateway, and TLS certificates will not be issued automatically. Enable it during installation:
Replace <cert-manager-version> with a currently supported cert-manager version compatible with your Kubernetes version.
helm install cert-manager cert-manager \
--repo https://charts.jetstack.io \
--version <cert-manager-version> \
--namespace cert-manager \
--create-namespace \
--set installCRDs=true \
--set config.apiVersion="controller.config.cert-manager.io/v1alpha1" \
--set config.enableGatewayAPI=true \
--set config.kind=ControllerConfiguration
If cert-manager is already installed, upgrade it to add Gateway API support:
helm upgrade cert-manager cert-manager \
--repo https://charts.jetstack.io \
--version <cert-manager-version> \
--namespace cert-manager \
--reuse-values \
--set config.apiVersion="controller.config.cert-manager.io/v1alpha1" \
--set config.enableGatewayAPI=true \
--set config.kind=ControllerConfiguration
Wait for the cert-manager pods to restart and become ready before proceeding.
--set config.enableGatewayAPI=true sets the enableGatewayAPI field in cert-manager's ControllerConfiguration, which is the same approach described in the migration from Ingress to Gateway API guide.
For details, see Configuring the HTTP-01 Gateway API solver in the cert-manager documentation.
Configure DNS after installation
This section covers the case where a LoadBalancer IP is provisioned automatically by the cluster. If you are using a pre-provisioned public IP, annotate the LoadBalancer service via the EnvoyProxy resource instead — see the Envoy Gateway documentation for details.
After the Envoy Gateway Helm chart is installed and a Gateway resource exists (deploying a nevisAdmin 4 project is one way to create it), retrieve the external IP assigned to the LoadBalancer service:
kubectl get svc -n envoy-gateway-system
Look for the EXTERNAL-IP of the Envoy Gateway LoadBalancer service. If you are using ingress-nginx instead, run kubectl get svc -n ingress-nginx. Then configure the DNS record for DOMAIN to point to that IP.
Azure: The standard way to assign a stable hostname is to add the service.beta.kubernetes.io/azure-dns-label-name annotation to the LoadBalancer service. This gives you an FQDN of the form <label>.<azure-region>.cloudapp.azure.com. Replace <azure-region> with the Azure region where the public IP is provisioned. The annotation can be set via the EnvoyProxy resource's spec.provider.kubernetes.envoyService.annotations field:
spec:
provider:
type: Kubernetes
kubernetes:
envoyService:
annotations:
service.beta.kubernetes.io/azure-dns-label-name: <label>
Set DOMAIN to the resulting FQDN before running the install, or update it afterwards with helm upgrade.
Other environments: Create a DNS A record pointing DOMAIN to the LoadBalancer IP in your DNS provider.
Deploy ingress-nginx (opt-out)
As of March 2026, ingress-nginx is end-of-life (EOL) and no longer receives any feature or security updates. Only use it if you have a specific reason to stay on it — for example, an existing setup already on it, or a chart version below 8.2511.3/7.2511.3, which doesn't support Envoy Gateway. New installations should use Envoy Gateway instead.
Follow the official installation instructions: https://kubernetes.github.io/ingress-nginx/deploy/. This is also the default if you don't deploy Envoy Gateway and don't set nginx.enabled=false — see the Install nevisAdmin 4 Chart section for the required chart values either way.
If you already have an existing ingress-nginx installation instead of deploying a new one for this release, see Using existing ingress-nginx installation.
Install CRD Chart
Install the helm chart that contains the CustomResourceDefinitions used by nevisAdmin 4.
helm install nevisadmin4-crd nevisadmin4-crd --version $NEVIS_VERSION --repo https://dl.cloudsmith.io/$CLOUDSMITH_PASSWORD/nevissecurity/rolling/helm/charts/
Uninstalling this chart deletes all the existing CustomResources, which results in the deletion of all the deployments made with nevisAdmin 4
Install nevisAdmin 4 Chart
Prepare secrets for installation
Prepare the required secrets to be used by the helm chart. This is done to avoid plain secret values in the values.yaml.
Create namespace
kubectl create namespace $RELEASE_NAMESPACE
Create credential secrets
These secrets are used to avoid having plain values in the values.yaml.
# nevisAdmin 4 admin user credential
kubectl create secret generic nevis-nevisadmin4-admin-credential \
--from-literal=password=$NEVISADMIN_PASSWORD \
-n $RELEASE_NAMESPACE
# git credential
kubectl create secret generic nevis-git-credential \
--from-file=key=key \
--from-file=key.pub=key.pub \
--from-file=known_hosts=known_hosts \
--from-literal=passphrase="" \
--from-literal=username="" \
--from-literal=password="" \
-n $RELEASE_NAMESPACE
# database credential
kubectl create secret generic nevis-database-credential \
--from-literal=username=$DB_ROOT_USER \
--from-literal=password=$DB_ROOT_PASSWORD \
-n $RELEASE_NAMESPACE
# nevisAdmin 4 database credential
kubectl create secret generic nevis-nevisadmin4-database-credential \
--from-literal=applicationUser=admin4appuser \
--from-literal=applicationUserPassword=$DB_NEVISADMIN_APP_USER_PASSWORD \
--from-literal=schemaUser=admin4schemauser \
--from-literal=schemaUserPassword=$DB_NEVISADMIN_SCHEMA_USER_PASSWORD \
-n $RELEASE_NAMESPACE
The nevis-database-credential secret can be used for the Root Credential and Root Credential Namespace fields in the database patterns inside nevisAdmin 4.
For more configuration options, see the section in the appendix.
The dbschema job uses database.root to create the application database, the citext extension it needs, and the schema/app users. If your Postgres role for database.root is locked down rather than a true admin/superuser, you can shrink what it needs to just CREATEROLE by pre-provisioning the rest yourself, connected as your actual database admin, before installing:
CREATE DATABASE nevisadmin4 OWNER <database.root user>;
\connect nevisadmin4;
CREATE EXTENSION IF NOT EXISTS citext;
When citext already exists, CREATE EXTENSION IF NOT EXISTS is a no-op — on any platform, not just Azure — so the dbschema job's own attempt to create it succeeds without needing extension-creation privileges, and it will not need CREATEDB or (on Azure) azure_pg_admin membership either.
Install
The commands below use Envoy Gateway, the recommended default. In versions below 9.2605.0, ingress-nginx is the default external routing solution if you don't set these values explicitly. To opt out and use ingress-nginx instead — see Deploy ingress-nginx first — replace the Envoy-specific settings with:
--set nginx.enabled=true \
--set nevisAdmin4.ingress.enabled=true \
--set nevisAdmin4.gateway.enabled=false \
--set nginx.nameOverride=$RELEASE_NAMESPACE-nginx
Kubernetes
helm install $RELEASE_NAME nevisadmin4 -n $RELEASE_NAMESPACE --version $NEVIS_VERSION \
--repo https://dl.cloudsmith.io/$CLOUDSMITH_PASSWORD/nevissecurity/rolling/helm/charts/ \
--set image.repository=$CONTAINER_REGISTRY \
--set git.repositoryUrl=$GIT_REPOSITORY_URL \
--set git.credentialSecret=nevis-git-credential \
--set database.type=postgresql \
--set database.port=5432 \
--set database.host=$DATABASE_HOST \
--set database.root.preparedCredentialSecret=nevis-database-credential \
--set nevisAdmin4.domain=$DOMAIN \
--set nevisAdmin4.credentialSecret=nevis-nevisadmin4-admin-credential \
--set nevisAdmin4.database.credentialSecret=nevis-nevisadmin4-database-credential \
--set nginx.enabled=false \
--set nevisAdmin4.ingress.enabled=false \
--set nevisAdmin4.gateway.enabled=true
database.type defaults to mariadb and database.port independently defaults to 3306 — setting database.type=postgresql alone does not change the port. If you're using PostgreSQL (the recommended option, see Prerequisites) but omit database.port=5432, the dbschema job will silently try to connect on the wrong port and fail with a timeout, not a clear error. This is being fixed upstream so postgresql/5432 become the new defaults together — until that ships, set both explicitly.
Deploy components to a separate namespace
By default, nevisAdmin 4 can only deploy Nevis components (for example nevisIDM, nevisAuth, and nevisProxy) into its own release namespace. If you want to deploy components into a different namespace — for example, to separate the nevisAdmin 4 management plane from the runtime components — you must:
-
Create the target namespace:
kubectl create namespace <component-namespace> -
Grant nevisAdmin 4 permission to deploy there by adding it to
additionalComponentNamespaces:helm upgrade $RELEASE_NAME nevisadmin4 -n $RELEASE_NAMESPACE \--repo https://dl.cloudsmith.io/$CLOUDSMITH_PASSWORD/nevissecurity/rolling/helm/charts/ \--version $NEVIS_VERSION \--reuse-values \--set "additionalComponentNamespaces={<component-namespace>}"This can also be set during the initial install by adding
--set "additionalComponentNamespaces={<component-namespace>}"to thehelm installcommand above. The namespace must exist before nevisOperator attempts to deploy into it — nevisOperator does not create it automatically. -
Select
<component-namespace>as the component namespace in the nevisAdmin 4 inventory. Adding a namespace toadditionalComponentNamespacesgrants permission to deploy there but does not change the deployment target.
OpenShift
This variant currently documents ingress-nginx only — Envoy Gateway on OpenShift is not yet covered here.
As ingress-nginx must run with user 101 and needs capabilities such as NET_BIND_SERVICE, it's required that the used SecurityContext is changed on OpenShift.
Additionally, it's not allowed to set the fsGroup of the nevisAdmin 4 deployment.
# Username for the registry
REGISTRY_USERNAME=
# Password for the registry
REGISTRY_PASSWORD=
# Prepare registry secret
oc create secret docker-registry registry-secret --docker-server="$CONTAINER_REGISTRY" --docker-username="$REGISTRY_USERNAME" --docker-password="$REGISTRY_PASSWORD" -n "$RELEASE_NAMESPACE"
# Prepare nginx service account
oc create serviceaccount nevisadmin4-nginx -n "$RELEASE_NAMESPACE"
oc adm policy add-scc-to-user privileged -z nevisadmin4-nginx -n "$RELEASE_NAMESPACE"
helm install $RELEASE_NAME nevisadmin4 -n $RELEASE_NAMESPACE --version $NEVIS_VERSION \
--repo https://dl.cloudsmith.io/$CLOUDSMITH_PASSWORD/nevissecurity/rolling/helm/charts/ \
--set image.repository=$CONTAINER_REGISTRY \
--set image.imagePullSecretName=registry-secret \
--set git.repositoryUrl=$GIT_REPOSITORY_URL \
--set git.credentialSecret=nevis-git-credential \
--set database.type=postgresql \
--set database.port=5432 \
--set database.host=$DATABASE_HOST \
--set database.root.preparedCredentialSecret=nevis-database-credential \
--set nevisAdmin4.domain=$DOMAIN \
--set nevisAdmin4.podSecurityContext.fsGroup=null \
--set nevisAdmin4.credentialSecret=nevis-nevisadmin4-admin-credential \
--set nevisAdmin4.database.credentialSecret=nevis-nevisadmin4-database-credential \
--set nginx.serviceAccount.create=false \
--set nginx.serviceAccount.name=nevisadmin4-nginx \
--set nginx.nameOverride=$RELEASE_NAMESPACE-$RELEASE_NAME
Upgrade
To upgrade the installation, copy over the new images from Upload Nevis Docker Images then run:
helm get values $RELEASE_NAME -n $RELEASE_NAMESPACE > values.yaml \
&& helm upgrade $RELEASE_NAME nevisadmin4 -n $RELEASE_NAMESPACE -f values.yaml \
--repo https://dl.cloudsmith.io/$CLOUDSMITH_PASSWORD/nevissecurity/rolling/helm/charts/ \
--set <your-new-values> \
--version <version-to-upgrade>
If the version is not provided, it upgrades to the latest one.
Using existing ingress-nginx installation
Set the nginx.enabled to false, and set the nginx.controller.ingressClassResource.name and nginx.controller.ingressClass values to the ingress class of the existing ingress-nginx controller.
Starting with nginx 1.12, snippet annotations have a Critical risk level, and Ingress resources containing them are ignored by the controller by default. As this is required for the side-by-side deployment to function, make sure that you have the following in the ConfigMap used by ingress-nginx:
allow-snippet-annotations: "true"
annotations-risk-level: Critical
annotation-value-word-blocklist: load_module,lua_package,_by_lua,location,root,proxy_pass,serviceaccount,',\
It's recommended to use a blocklist to prevent misuse.
Appendix: nevisAdmin 4 Chart Values
additionalComponentNamespaces
By default, the permissions and accessory resources are set up in a way that it's only possible to deploy from nevisAdmin4 to the same namespace where the chart is installed. Listing additional ones here, will make it so that nevisAdmin4 can deploy to these namespaces. The namespace itself has to exist already.
Type: list
Default:
[]
bootstrap
Supports importing initial projects and inventories into nevisAdmin 4 and creating a repository in gitea.
Type: object
Default:
annotations: {}
gitea:
enabled: false
image:
version: 1.3.0
labels: {}
nevisAdmin4:
enabled: false
podAnnotations: {}
podLabels: {}
bootstrap.annotations
Annotations to put onto the Job.
Type: object
Default:
{}
bootstrap.labels
Labels to put onto the bootstrap job.
Type: object
Default:
{}
bootstrap.podAnnotations
Annotations to put onto the pods.
Type: object
Default:
{}
bootstrap.podLabels
Labels to put onto the bootstrap job pod.
Type: object
Default:
{}
certManager.createCAIssuer
Create a CA Issuer to the main release namespace, it also creates a self-signed issuer to prepare the root CA
Type: bool
Default: true
certManager.createLetsEncryptIssuer
Creates a Let's encrypt issuer to every component namespace
Type: bool
Default: true
certManager.httpSolverGateway
Specify the gateway to be used for the http01 challenge solver. Must have a HTTP listener that allows routes from nevisadmin4 and component namespaces. By default, the nevisadmin4 gateway is used.
Type: string
Default: not set
certManager.httpSolverGatewayNamespace
Namespace of the gateway to be used for the http01 challenge solver. By default, the release namespace is used.
Type: string
Default: not set
database.host
Database host, example: mariadb29a7439e.mariadb.database.azure.com
Type: string
Default: not set
database.port
Database port
Type: string
Default: "3306"
database.root.credentialSecret
DEPRECATED: Use preparedCredentialSecret instead. Secret containing the username and password for the root user. Must have the "username" and "password" key.
Type: string
Default: "helm-database-credential"
database.root.password
Root password in plain value. It's recommended to prepare a secret instead.
Type: string
Default: not set
database.root.preparedCredentialSecret
When using this value, root-creds secret will only be created in the namespace where nevisAdmin4 resides. Adjust the Root Credential Namespace in the Database patterns of nevisAdmin 4 before the migration to this value.
Type: string
Default: not set
database.root.username
Root username in plain value. It's recommended to prepare a secret instead.
Type: string
Default: not set
database.type
Type of the database, supported values: mariadb, postgresql
Type: string
Default: "mariadb"
git.caCert64
Base64 PEM CA certificate, used to trust a private/internal CA for HTTPS git connections. Not needed for public CAs. Alternatively, a "ca.crt" key can be added to credentialSecret. If both are set, this value takes precedence over credentialSecret's "ca.crt" key.
Type: string
Default: not set
git.credentialSecret
Secret containing the git credentials, to avoid having plain values in the values file. Must have "key", "key.pub", "known_hosts", "passphrase", "username", "password" secret keys. In case only http or ssh is used, the corresponding values can be empty, but the keys still have to exist in the secret. Optionally, a "ca.crt" key can be added to trust a private/internal CA for HTTPS connections.
Type: string
Default: not set