The DataQI Helm chart uses a “Pre-requisite Day 2” secret model. Helm does not generate any credentials or certificates on deployment. All credentials must be provisioned into the cluster as standard Kubernetes Secret resources before running helm upgrade --install.
The chart expects these secrets to follow a canonical dataqi-<component> naming scheme by default. If you use other tools, such as External Secrets Operator, you can map custom secret names in the chart’s values.yaml under the secrets: block.
Purpose: Provides authentication credentials to pull DataQI container images from a private registry. Not required when pulling from an unauthenticated registry (for example if you are mirroring the images to a local registry). In that case, set secrets.registry: "" in your values file to skip imagePullSecrets entirely.
Required keys:
.dockerconfigjson: A JSON payload containing the registry credentials.
Example payload before Base64 encoding:{"auths":{"acrdataqi-ayguf2ahfghaenfn.azurecr.io":{"username":"<YOUR_USER>","password":"<YOUR_PASSWORD>","auth":"<BASE64_USER_PASS>"}}}.
Tip: You can easily generate this secret using the following kubectl command:
Purpose: Mounted into the NATS message broker pod as an auth.conf configuration file to enforce client authentication.
Important: The password must be alphanumeric only (NATS rejects special characters in its config file) and exactly match the password in dataqi-nats-connection.
Purpose: Provides the endpoint and ingestion key used by the OpenTelemetry (OTel) Collector to export traces and metrics. The presence of this secret activates telemetry exporting. If omitted, the collector will still deploy and process traffic but will drop the payloads instead of exporting them.
Purpose: Contains a PFX certificate and its password. This is used by the API to securely encrypt and decrypt credentials that are used for connecting to external systems. For instructions on generating this certificate, see the Data protection certificate guide.
Required keys:
dataprotection.pfx: <binary-certificate-data> (Must be properly Base64 encoded if passing via YAML data: block).
certificate-password: <certificate-password>.
Warning: Beware of double encoding
Do not use kubectl create secret ... --from-literal=dataprotection.pfx="<base64>" to inject a Base64-encoded string from the command line or CI/CD pipelines. This causes Kubernetes to Base64 encode the string again, resulting in a corrupted certificate when the pod mounts the file.
Correct approach: Always create this secret directly from the binary file:
Auto-rotating the Data Protection PFX certificate in your secrets manager will instantly destroy the decryption keys running in the cluster. This will immediately prevent the application from decrypting user secret values rendering them permanently un-decryptable and breaking user functionality.
Note: This certificate is used for encrypting user credentials that are stored in the database. It does not need to be signed by a trusted Certificate Authority because there is no trust relationship between the certificate and any external systems.
Purpose: Contains the initial admin credentials for the Keycloak management console. This secret is automatically created by the Keycloak Operator when Keycloak starts for the first time — you do not need to create it yourself.
Keys:
username: The admin username.
password: The auto-generated admin password.
Tip: Retrieve the auto-generated admin credentials after installation:
Purpose: Automatically provisions an upstream Microsoft identity provider in Keycloak. Omitting this secret leaves Keycloak configured for local authentication only.
Purpose: Provides the bind credentials for Keycloak to connect to an external LDAP directory (e.g., Active Directory). The name of this secret must be explicitly provided in your values file under infra.keycloak.ldap.bindCredentialSecretName.
Purpose: Provides the API key used to authenticate external systems calling the workflow trigger endpoint. Each deployment instance should use a unique key.
Required keys:
api-key: <randomly-generated-api-key>.
Tip: Generate a strong random key and create the secret:
DataQI supports two ways to supply a custom Certificate Authority (CA) bundle to outbound-facing pods, so they trust internal corporate PKI or self-signed certificates that are not present in standard Linux root stores. Choose whichever approach fits your environment — both are supported across both charts:
dataqi chart: covers the API, telemetry ingress, Extractor, and MCP Sandbox pods. Required when Keycloak, your AI model gateway, or another endpoint uses an internal CA.
dataqi-aiops chart: covers all enabled MCP server pods (Intersight, vROps, Virtana, ServiceNow). Required when any of those target systems use an internal CA.
Option A — Kubernetes Secret (secrets.customCaBundle)
Tip: On enterprise Windows machines enrolled in a corporate PKI, you can export the relevant root CAs directly from the Windows certificate store. Run the following in PowerShell on any domain-joined machine that already trusts the corporate PKI, replacing COMPANYNAME with the common name identifier used in your organisation’s CA subject:
This exports every matching root certificate from the machine trust store into a single PEM bundle. You can then create the Kubernetes secret directly from that file:
If your platform already manages CA certificates via a ConfigMap (for example, OpenShift’s cluster CA injection or a custom operator), point the chart at that ConfigMap instead of creating a Secret.
The ConfigMap must contain a ca-bundle.crt key holding a PEM-encoded certificate bundle. On OpenShift, create an empty ConfigMap with the injection label and the cluster operator will populate it automatically:
By default, DataQI preserves existing OS trust. When networking.caBundleMergeImage.enabled is true (the default), an init container merges the supplied PEM file with the OS CA roots before the application starts. The merge image is configured under networking.caBundleMergeImage. In private-registry environments, override networking.caBundleMergeImage.repository and networking.caBundleMergeImage.tag to point to a mirrored, shell-capable image that is already approved for your cluster.
Note: Leaving networking.caBundleMergeImage.registry empty ("") causes the chart to fall back to global.imageRegistry. If the merge image lives in a different registry (for example the default mcr.microsoft.com while your app images use an internal mirror), set registry explicitly.
Only set networking.caBundleMergeImage.enabled: false when your bundle is a complete replacement that already contains both public roots and your private roots — this disables the merge init container entirely and mounts the source directly.
These secrets are required when deploying the dataqi-aiops chart, which runs various Model Context Protocol (MCP) integrations connecting the assistant to enterprise infrastructure. Since each MCP server is optional, you only need to provide the secrets for the MCP servers you intend to deploy. Note that each MCP server is disabled by default and must be explicitly enabled in the values file.
Important: Base URL Configuration
All MCP servers (Intersight, vROps, Virtana, ServiceNow) manage their own internal API path routing automatically. When configuring the baseUrl or instanceUrl for any of these services (whether in values.yaml or a secret), you MUST provide the domain root only, with no trailing slashes or path segments.
The dataqi-aiops chart uses the same dataqi-image-registry secret as the core chart. No separate registry secret is required. Ensure dataqi-image-registry is provisioned in the same namespace before deploying either chart.
The dataqi-aiops chart supports the same CA bundle options as the core chart — either a Kubernetes Secret via secrets.customCaBundle or a ConfigMap via networking.caBundleConfigMap. See Custom CA bundle above for full setup instructions.
