SEC-NB-003 — Restrict notebook workloads from platform-owned databases

Field	Value
Status	Open; direct internal database network reachability is live-verified
Architecture state	Deployed network boundary does not demonstrate default-deny egress
Severity	High
Affected surface	User-controlled Jupyter and Spark code with workspace-cluster network access
Components	sparqd/platform-stacks, Kubernetes networking, JupyterHub, Enterprise Gateway, Spark workloads, platform-owned databases
Associated issue	Not opened

Where the problem appears

Notebook users control Python code and third-party packages in remote Spark kernels. That workload can initiate network connections from the driver toward cluster-internal services. Namespace separation and internal DNS names do not, by themselves, prevent this east-west traffic.

Concrete observed case

On 9 September 2026, a disposable Spark driver in gj76anadpsc / w-t5e2kcxjd resolved the internal Hive Metastore PostgreSQL service and established a TCP connection to port 5432. The backing KubeBlocks database cluster was running. This independently verifies network reachability from user-controlled Spark code to a platform-owned database endpoint.

The user conducting the notebook test reported that a PySpark JDBC read also succeeded with an application credential. The assessment did not retain the credential or query result, so database authorization and returned data are not claimed as independently captured evidence.

Expected condition

User-controlled notebook servers, Spark drivers, and executors are denied direct network access to platform-owned database ports by default. They reach data through governed interfaces such as Trino, the Hive Metastore API, and platform APIs, where identity, authorization, audit, and data policy can be enforced.

Explicit access to tenant-owned or external JDBC targets remains possible only through an approved connector and egress path. That exception must not create a route to platform control-plane or service databases.

Cause and evidence

The successful TCP connection proves that the deployed path permits the tested driver-to-service traffic. It does not prove why the path is allowed, whether a NetworkPolicy exists elsewhere, whether every database is reachable, or which credentials the workload can obtain.

The expected design is default-deny egress for user-controlled workloads plus explicit allow rules for required destinations. The allow-list may include DNS, object storage, Enterprise Gateway control and kernel traffic, driver/executor communication, the Hive Metastore API on its governed service port, approved platform APIs, and explicitly approved external data endpoints. Platform-owned database pods and services must be labeled and denied as direct targets.

Network policy is defense in depth, not a substitute for database authentication, least privilege, credential isolation, or audit. Conversely, database authentication alone does not establish a safe network boundary when user code can receive or discover credentials.

Why it matters

A notebook is an arbitrary-code boundary. Direct reachability lets user code and downloaded packages attempt database authentication, exploit a service, or reuse credentials that should have remained behind a trusted API. Combined with SEC-NB-002, reachable internal services increase the blast radius of any credential exposed to the runtime.

Reachability alone does not establish data disclosure, so this finding is High rather than Critical on the current evidence. The risk belongs to the Tier-0 security boundary because it affects tenant isolation, secrets, and internal service access.

Existing controls and workarounds

Governed query paths through Trino and Ranger can enforce user-level data policy. Database authentication may reject a caller that lacks a valid credential. Neither control removes the verified network route.

Until the egress boundary is enforced, do not provide platform database credentials to notebook code, do not use internal database services as notebook JDBC targets, and treat third-party packages as code with the same network reach as the kernel.

Alternatives considered

1. Recommended: default-deny egress for notebook servers, Spark drivers, and executors, followed by identity- and destination-specific allow rules.
2. Governed egress proxy or connector service for approved external JDBC access, with destination policy and audit.
3. Database firewall and authentication controls only — necessary but rejected as the sole boundary because traffic still reaches sensitive services.
4. Namespace isolation only — rejected because the observed cross-namespace service connection succeeded.

Component involvement

• sparqd/platform-stacks owns workload labels, namespace composition, NetworkPolicy, and the allow-list for required platform paths.
• Kubernetes networking and the cluster network-policy provider enforce the selected egress and ingress rules.
• JupyterHub and Enterprise Gateway define which user-controlled pods are in scope and which control paths must continue to work.
• Spark drivers and executors require explicit mutual communication, DNS, object storage, metastore, and approved service paths.
• Platform database owners must enforce authentication and identify service endpoints that are never direct notebook targets.

Reproduction and verification

Follow NB-S024.

Resolution conditions

Close after a reviewed default-deny policy covers every user-controlled notebook and Spark workload; required platform flows and approved external data paths pass; direct connections to labeled platform database ports are denied; database authentication remains least-privileged; policy-denial telemetry and a runbook exist; and the boundary is continuously tested across supported compute profiles.

Validation and blockers

DNS resolution and TCP connection from one deployed Spark driver to the Hive Metastore PostgreSQL service on port 5432 are live-verified. A successful JDBC read is user-reported. The effective NetworkPolicy inventory, reachability to other internal databases, credential discoverability, and the complete list of required egress paths remain unverified. No additional internal-service probing was performed.