Database Management

Nevis Identity Suite supports several ways to manage the databases used by nevisAdmin 4 and by Nevis components deployed to Kubernetes. Select the approach that matches your organization's separation of duties and database security policy.

This guide covers two related parts of an installation:

• The nevisAdmin 4 Helm chart, which installs nevisAdmin 4 and nevisOperator.
• Database patterns, which configure the databases used by Nevis components such as nevisIDM, nevisAuth, and nevisProxy.

For the complete installation procedure, including the Kubernetes cluster, image registry, secrets, CRDs, and Helm chart installation, see Kubernetes-based installation. The pages linked below focus on database preparation and configuration.

Database Management Approaches

Approach	Who creates the database and users?	Who runs schema migrations?	Database pattern
Fully automated	NevisDatabase custom resource, reconciled by nevisOperator	NevisDatabase custom resource, reconciled by nevisOperator	complete
Pre-provisioned database and users	DBA or customer tooling	NevisDatabase custom resource, reconciled by nevisOperator	schema
Fully external management	DBA or customer tooling	DBA or customer tooling	disabled

The schema approach is a hybrid ownership model: the DBA owns database provisioning and access control, while nevisOperator owns the application schema lifecycle by running Flyway migrations. It is often the best balance when the application must not hold a privileged provisioning credential, but automatic migrations are still desired. Use disabled instead when database change control requires the DBA or an external release process to approve and run every migration.

Components that use databases

Use this overview during planning to identify which databases may need to be prepared. The requirement depends on the component configuration and deployment topology. In particular, session databases are optional for single-replica deployments but are normally required when multiple replicas must share state.

Component	Database purpose	Database required?
nevisAdmin 4	Stores nevisAdmin 4 configuration, projects, inventories, and deployment data.	Yes, for the nevisAdmin 4 installation.
nevisIDM	Stores identities, credentials, authorizations, and related identity-management data.	Yes, when nevisIDM is deployed.
nevisAuth	Stores authentication sessions and out-of-context data.	Optional when sessions can remain in memory; normally required for multiple replicas or shared sessions.
nevisProxy	Provides a remote or hybrid session store for sessions required by configured filters or servlets.	Optional; required when the selected configuration needs shared or remote sessions.
nevisFIDO UAF	Stores nevisFIDO UAF sessions.	Optional for a single replica; required to share sessions between multiple replicas.
nevisFIDO FIDO2	Stores nevisFIDO FIDO2 sessions.	Optional for a single replica; required to share sessions between multiple replicas.
nevisAdapt	Stores adaptive-authentication risk-analysis state and persisted results.	Yes, when nevisAdapt is deployed.
nevisDetect Persistency	Stores nevisDetect persistency data used by the detection service.	Yes, when nevisDetect Persistency is deployed.
nevisMeta	Stores nevisMeta persistence data, including sessions.	Yes, when nevisMeta is deployed.

The exact database pattern, fields, and defaults are maintained with each component pattern. Consult the assigned pattern for the component version you deploy, especially when using schema or disabled, because the pattern determines which database and user credentials must be prepared.

Common prerequisites

Before choosing an approach, prepare the following:

• A supported database service that is reachable from the Kubernetes cluster.
• A database administrator or service principal that can perform the required preparation.
• A plan for storing database credentials securely. Helm chart database credentials must be provided through Kubernetes Secrets. Database pattern credentials can use nevisAdmin secret references or Kubernetes Secret references. Do not put passwords directly in Helm values or pattern configuration committed to a repository.
• A database and schema name for each component that uses a database.
• The required database users and grants for the selected approach.
• A migration procedure for initial installation and upgrades.

For PostgreSQL, the citext extension is required by the nevisAdmin 4 schema. It is not an optional Azure workaround: Flyway migrations use citext types and later migrations depend on the extension. If a restricted role is used, have the actual database administrator create the extension first.

nevisAdmin 4 Helm chart configuration

The chart uses the following database configuration surfaces:

• database.type, database.port, and database.host identify the database service.
• database.root.preparedCredentialSecret supplies the database user used by the nevisAdmin 4 dbschema job. The older database.root.credentialSecret value is legacy and should not be used for new installations.
• nevisAdmin4.database.credentialSecret supplies the nevisAdmin 4 schema and application users.

The existing nevisAdmin 4 Kubernetes installation shows how to create these Secrets and install the chart. For PostgreSQL, configure both database.type=postgresql and database.port=5432.

When the nevisAdmin 4 database and citext extension are pre-provisioned by an actual administrator, the chart database user does not need to be a fully privileged root user. CREATEROLE is sufficient for the chart dbschema job to create the nevisAdmin 4 schema and application users.

Database pattern configuration

In a component database pattern, configure the database connection and select Advanced settings > Database Management:

• complete creates the database prerequisites, users, grants, and schema migrations.
• schema expects the database and both users to exist and runs schema migrations only.
• disabled does not run database management. The database and migrations are fully external.

In all three modes, only the application (connection) user is placed in the running component configuration. The schema-owner user is used only by the dbschema job during migrations.

Each database pattern defines its own default names for the schema-owner user and the application user. Do not assume that components use the same naming convention. Check the database pattern and its credential fields for the values applicable to your component and release. When using schema, the DBA can choose different names, but must configure both users consistently in the pattern and in the database. When using disabled, configure only the application user in the pattern; keep the schema-owner credentials with the external migration job.

Credentials and upgrades

For complete and schema, the dbschema job runs during the deployment and during upgrades. The credentials used by the job must remain available to the deployment process.

For disabled, run the component dbschema image as a Kubernetes Job before the initial component deployment and before every upgrade that changes the schema. The migration job must use the schema owner credentials and must be configured so that it does not perform role management. The component pod must use only the application-user credentials.

For Helm chart database credentials, use Kubernetes Secrets. A vault integration may populate or synchronize those Secrets, but the Helm chart consumes Kubernetes Secret references only.

For database pattern credentials, use either nevisAdmin secret references or Kubernetes Secret references. A vault integration can synchronize credentials into a Kubernetes Secret before deployment.