Security And Networking

XTrinode is designed around separated namespaces and explicit platform boundaries.

Namespace Layout

Namespace	Purpose
xtrinode-system	Operator, API server, control-plane leases, control-plane config.
xtrinode-gateway	Gateway Deployment, route ConfigMap, gateway auth secrets, optional Redis.
Team namespaces	XTrinode, XTrinodeCatalog, secrets, Trino pods, KEDA objects, optional node-pool objects.

This layout keeps the exposed query plane separate from the control plane and lets platform teams apply RBAC, quota, and network policy by namespace.

Gateway Boundary

The gateway is a Trino-aware reverse proxy that works alongside cloud load balancers, DNS, and TLS edge policy.

Layer	Responsibility
Ingress or LoadBalancer Service	External reachability, DNS, TLS termination, provider edge integration.
XTrinode gateway	Route lookup, backend state, sticky query routing, rate limits, auth, resume calls.
Coordinator Service	Stable Kubernetes DNS name for a runtime coordinator.
Trino coordinator and workers	Query execution.

For production, terminate TLS at the edge or ingress layer until native coordinator HTTPS control support is enabled for managed runtimes.

Gateway Auth

Gateway auth supports API key mode and OAuth/OIDC bearer tokens. OAuth mode validates issuer, audience, expiry, nbf, subject, and RSA signatures from JWKS. The gateway does not strip the Authorization header, so a coordinator can validate the same bearer token when Trino OAuth is enabled behind the gateway.

gateway:
  auth:
    enabled: true
    type: oauth
    oauth:
      issuer: https://issuer.example.com
      audience: trino
      refreshInterval: 1h

If the issuer does not expose OIDC discovery, configure jwksURL explicitly. Gateway health and metrics endpoints bypass auth and rate limiting so Kubernetes probes and Prometheus scrapes can use normal cluster network controls.

Redis

Redis is optional. It is used for cross-replica sticky routing and distributed rate limiting. If you run more than one gateway replica, enable Redis or accept that sticky routing and rate limits are local to each gateway pod.

gateway:
  redis:
    enabled: true
    url: redis://redis.example.internal:6379/0
    existingSecret: xtrinode-gateway-redis
    existingSecretKey: redis-password

Use a managed Redis service for production deployments.

Catalog Secrets

Catalog credentials should remain in Kubernetes Secret resources. Catalog ConfigMaps should contain environment placeholders, not raw passwords.

apiVersion: v1
kind: Secret
metadata:
  name: postgres-credentials
  namespace: team-a
type: Opaque
stringData:
  password: change-me
---
apiVersion: analytics.xtrinode.io/v1
kind: XTrinodeCatalog
metadata:
  name: postgres-analytics
  namespace: team-a
spec:
  labels:
    team: analytics
  connector:
    postgres:
      connectionURL: jdbc:postgresql://postgres:5432/analytics
      connectionUser: trino
      connectionPasswordSecret:
        name: postgres-credentials
        key: password

The operator injects referenced secrets into Trino pods as environment variables, and Trino resolves the placeholders at runtime.

Privileged Overrides

spec.valuesOverlay is powerful and should be treated as privileged input. It can affect images, pod security context, volumes, environment sources, network policy, sidecars, resource groups, and Trino config.

Prefer typed fields when possible. Admission warns when valuesOverlay is present or changed, and platform policy should require operator-level authorization for privileged overlay content. Multi-tenant clusters can add ValidatingAdmissionPolicy, OPA Gatekeeper, Kyverno, or an equivalent local policy layer for stricter rules.

spec:
  valuesOverlay:
    server:
      config:
        authenticationType: PASSWORD
    auth:
      passwordAuthSecret: trino-password-auth
      groupsAuthSecret: trino-groups-auth

When Trino HTTP authentication is enabled, configure spec.trinoControlAuth so the operator and lifecycle hooks can call internal Trino control APIs. The referenced Secret must live in the same namespace as the XTrinode, and the same user must be present in Trino password auth configuration.

Admission rejects raw config-property overrides that disable the Trino HTTP listener or change the HTTP port. Use valuesOverlay.service.port for supported port changes so Services, routes, status, autosuspend, and graceful shutdown stay aligned. Native Trino HTTPS server mode is not supported for managed runtimes yet; terminate TLS outside Trino until native HTTPS coordinator/control support is implemented.

Network Policy

At minimum, allow:

• gateway to runtime coordinator Services;
• gateway to API server for resume calls;
• operator to Kubernetes API and watched namespaces;
• KEDA to metrics endpoints used by its triggers;
• Prometheus to enabled metrics endpoints;
• runtimes to the data sources declared by their selected catalogs.

Block broad namespace-to-namespace traffic by default where your Kubernetes platform supports it.