Skip to main content

Security hardening

A production checklist for a Datastrato Enterprise install. Each item names the setting and links to the page that covers it in full. Work through it after Install with Helm and the Production checklist, and before the install holds real metadata or serves real users.

Sign-in​

  • Sign in through your identity provider. Set gravitino.authenticators to oauth,basic and configure the provider, so people sign in with their corporate identity and lose access when the provider disables them. See Identity provider.
  • Provision users and groups from your directory. Turn on SCIM provisioning so accounts and group membership follow your directory rather than being kept by hand.
  • Keep one local administrator for recovery. With basic listed after oauth, the local admin account still signs in when the identity provider is unreachable. Create its password in a Secret of your own (see Secrets), keep it out of everyday use, and change it after each use. See Local users and groups.
  • Keep the service administrator list short. gravitino.authorization.serviceAdmins names the accounts that manage metalakes, the directory and identity settings. List the recovery account and the people who run the install, nobody else.
  • Set session limits. Choose an idle timeout and a maximum session length that match your policy; see Session timeout.

Access​

  • Grant through roles, to groups. Give each job a role carrying only the privileges it needs, and grant roles to groups from your directory rather than to individuals. See Roles and Privileges.
  • Assign owners deliberately. An object's owner manages it and its grants. Keep ownership of metalakes and catalogs with a group or a service account, not a person who may leave.
  • Remove access when people leave. When the directory deactivates or deletes a provisioned user, SCIM disables or removes the account here; see Deprovisioning. Suspend a local account under Configure → Directory.
  • Review access regularly. Authorize → Users, Groups and Roles show who holds which role. The audit log records every grant, revoke and ownership change, for the review between two dates.

Network​

Publish only the hosts your callers need, each on its own name with a certificate they trust:

HostPublish whenValue
UI and MCPAlwaysingress.hosts, ingress.tls
Server APIJava or Python clients, or Gravitino connectors, run outside the clustergravitino.ingress.hosts, gravitino.ingress.tls
Iceberg RESTIceberg engines run outside the clusteringress.iceberg.host, ingress.iceberg.tls
Lance RESTLance clients run outside the clusteringress.lance.host, ingress.lance.tls
SCIMYou provision from a cloud identity providergravitino.scim.ingress.host, gravitino.scim.ingress.tls

  • Use TLS on every published host. The ingress controller terminates TLS with the certificate in each host's Secret. cert-manager issues and renews them. Any standard ingress controller works: nginx, Traefik, a cloud load balancer controller or the OpenShift router.

  • Advertise the Iceberg REST host to connectors. The Gravitino connectors for Trino and Spark ask the server where the Iceberg REST service is and route Iceberg catalogs through it. When the service is published, set its public address so engines outside the cluster use it:

    my-values.yaml
    gravitino:
      additionalConfigItems:
        gravitino.iceberg-rest.advertised-uri: "https://{iceberg_host}/iceberg"

  • Keep the metrics paths inside the cluster. /metrics and /prometheus/metrics answer on the server API, Iceberg REST and Lance REST ports. Scrape them from inside the cluster, and deny those two paths at the ingress controller on any published host. See Metrics.

  • Keep lineage inside the cluster. The lineage API and web view are not published by default. Leave ingress.lineage.enabled off, or publish it only behind an authenticating proxy; see Lineage.

  • Never publish the databases or OpenSearch. The metadata database, the lineage database and the search index serve only the workloads in the release.

  • Restrict traffic between workloads. Ports and network lists every connection each workload makes. Write network policies from those tables, allowing inbound traffic from your ingress controller's namespace and the inside and outbound rows for each workload.

  • Encryption inside the cluster. TLS ends at the ingress controller, and the workloads talk to each other over the cluster network. Where your policy requires encryption between pods as well, run the release in a service mesh with mutual TLS.

Credentials​

  • Keep credentials out of the values file. Create the license, administrator and database Secrets yourself and name them in the values file; see Secrets.
  • Vend temporary credentials to engines. Give each object storage catalog a credential provider that issues short-lived, table-scoped credentials, such as s3-token or aws-irsa on Amazon S3, rather than handing engines a long-lived key. See Credential vending.
  • Give the server a role, not a key, where the cloud allows. On EKS and GKE, attach a cloud identity to the server's service account with gravitino.serviceAccount.annotations; see Object storage.
  • Mirror images into your own registry. Pull from a registry you control and scan; see Air-gapped installation.

Audit and recovery​

  • Ship the audit log off the cluster. Forward it to your log platform, where it is kept for your retention period and cannot be changed by the people it records. See Splunk and Datadog.
  • Back up and protect the backups. Back up the metadata and lineage databases and the release values, and store them with the same access controls as the install. See Backup and restore.
  • Upgrade promptly. Install each release's fixes as they ship; see Upgrades.
Last updated on