Secrets
Every credential a Datastrato Enterprise install needs is held in a Kubernetes Secret, never in the ConfigMap that carries the server's configuration. The chart creates the Secrets it needs from the values file, or uses Secrets you create yourself, so that the values file can carry no credential at all. The server reads the credentials from the Secrets when its pod starts.
Secrets the chart creates
{release} is the release name. When the release name contains gravitino, the chart drops the
extra -gravitino from these names.
| Secret | Holds | Keys | Your own Secret instead | Kept on uninstall |
|---|---|---|---|---|
{release}-gravitino-license | The license key | license-key | gravitino.license.existingSecret | No |
{release}-gravitino-admin-credentials | The first service administrator's user name and password | username, password | gravitino.admin.existingSecret | Yes |
{release}-gravitino-postgresql | The in-cluster PostgreSQL's passwords | postgres-password, password | gravitino.postgresql.auth.existingSecret | Yes |
{release}-gravitino-mysql | The in-cluster MySQL's passwords, when MySQL is used | mysql-root-password, mysql-password | gravitino.mysql.auth.existingSecret | Yes |
{release}-gravitino-entity-store | The password for an external metadata database | jdbc-password | None | Yes |
{release}-gravitino-iceberg-rest | Storage and backend credentials set under gravitino.icebergRest, when any are | jdbc-password, s3-access-key-id, s3-secret-access-key, oss-access-key-id, oss-secret-access-key, azure-storage-account-key, azure-client-secret | gravitino.icebergRest.existingSecret | No |
{release}-gravitino-opensearch | The server's OpenSearch password | password | gravitino.search.opensearch.existingSecret | No |
{release}-marquez | The lineage database password | marquez-db-password | marquez.marquez.existingSecretName | Yes |
opensearch-auth-secret, opensearch-certs | OpenSearch's admin login and its TLS certificates | opensearch.tls.existingSecret for the certificates | No | |
| The MCP server's token and OAuth Secrets | The MCP server's credentials for calling the server | token, client-secret | mcp.auth.existingSecret, mcp.auth.oauth.existingSecret | No |
A password left empty in the values file is generated: 24 random characters. Once a kept Secret exists, the chart reuses its passwords on every upgrade, so a value changed later in the values file has no effect; see Rotate credentials.
Secrets you create yourself are referenced, not owned, by the chart, so the chart neither changes nor
deletes them: the image pull Secret, TLS certificates for the published hosts, a Google service
account key, CA certificates for the trust store, and any Secret named in an existingSecret value.
Keep credentials out of the values file
For production, create the Secrets first and name them in the values file. The values file and the release record then hold no password or key.
kubectl -n "$NAMESPACE" create secret generic datastrato-license \
--from-literal=license-key="$(tr -d '\n' < "$LICENSE_FILE")"
kubectl -n "$NAMESPACE" create secret generic datastrato-admin \
--from-literal=username=admin --from-literal=password="$ADMIN_PASSWORD"
kubectl -n "$NAMESPACE" create secret generic datastrato-postgresql \
--from-literal=postgres-password="$(openssl rand -hex 16)" \
--from-literal=password="$(openssl rand -hex 16)"
gravitino:
license:
existingSecret: datastrato-license
admin:
existingSecret: datastrato-admin
postgresql:
auth:
existingSecret: datastrato-postgresql
marquez:
marquez:
inClusterDB:
postgresql:
secretName: datastrato-postgresql
The license key must not end with a newline, which the license check rejects as invalid encoding;
the tr command above removes it. Lineage creates its database with the PostgreSQL
superuser password, so a PostgreSQL Secret of your own has to be named for lineage as well, as above.
With a license Secret, leave --set-string gravitino.license.key off the install command.
To keep Secrets in an external store such as HashiCorp Vault or AWS Secrets Manager, have a controller such as the External Secrets Operator create these Kubernetes Secrets from it, and name them in the values file the same way.
Rotate credentials
| Credential | How to change it |
|---|---|
| License key | Update the license Secret, or run the install command with the new key, then restart the server |
| Admin password | Change it as that user, in the UI or with the user API; see Local users and groups. The admin Secret only seeds the admin user on a new install, so changing the Secret changes nothing |
| In-cluster database passwords | Change the password in the database, then the matching key in its Secret, then restart the server, metrics service and lineage |
| External database password | Change it in the database and in the jdbc-password key of {release}-gravitino-entity-store, then restart the server and metrics service |
| Iceberg REST storage credentials | Update the Secret, or the values and run the install command, then restart the server |
| Catalog credentials | Change the catalog's properties in the UI or with the catalog API; no restart is needed |
Restart a workload with kubectl rollout restart; see Start, stop and restart.
Credentials in catalogs
Credentials for connected sources, such as a JDBC password or an S3 secret key, are catalog properties, held in the metadata database rather than in Kubernetes. The server never returns them: catalog responses leave them out, and the UI shows them as Write-only. Engines that need storage access receive vended credentials for each table instead of the catalog's own keys.