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.

Quick start

1. List the Secrets. Every Secret the install uses is in the release namespace; the names are described in Secrets the chart creates.

   List Secrets in the namespace

   kubectl -n "$NAMESPACE" get secrets

2. Read the admin password. With basic in gravitino.authenticators and gravitino.admin.initPassword left empty, the chart generated the password.

   Read the generated admin password

   kubectl -n "$NAMESPACE" get secret "$RELEASE-gravitino-admin-credentials" \
     -o jsonpath='{.data.password}' | base64 -d

3. Move credentials out of the values file for production. Create the Secrets yourself and name them in my-values.yaml, as described in Keep credentials out of the values file.

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.

Create the Secrets

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)"

my-values.yaml

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 their values: responses show ****** in place of a credential property, and of any undeclared property whose name contains secret, password, token, credential, access or account, 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.

Related

• Install
• Customize the Helm chart
• Security hardening
• Backup and restore
• Metadata database