Skip to main content

Notebook dependency resolution and internal network boundary assessment design

Objective​

Extend the existing Notebook Execution assessment with evidence gathered on 9 September 2026 from the dev-north-alicloud workspace. The update records two separate concerns:

  1. Maven package resolution is a Spark Operator controller responsibility with a bounded, pod-local Ivy cache and a demonstrated PostgreSQL JDBC path.
  2. A user-controlled Spark runtime can reach a platform-owned KubeBlocks PostgreSQL endpoint directly, which weakens the intended application and governed-data access boundaries.

The assessment describes current behavior and desired boundaries. It does not implement remediation or include credential values.

Documentation model​

The reliability and security concerns remain separate findings because they have different causes, owners, impact, and closure evidence.

REL-NB-011 — Operate bounded Maven dependency resolution​

Record the observed failure before driver creation, the controller-local cache remediation, and the successful resolution and use of org.postgresql:postgresql:42.7.7. The canonical Spark Operator page describes the lifecycle once; the finding links to it and concentrates on assessment, residual risk, and closure conditions.

Residual risks include cold cache after controller replacement, independent caches if controller replicas are introduced, bounded-volume exhaustion, and missing usage, eviction, and dependency-resolution telemetry.

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

Record independently verified DNS/TCP reachability from a Spark driver to the Hive Metastore KubeBlocks PostgreSQL service. Record the successful JDBC read as user-reported evidence rather than an independently captured query result.

The expected boundary denies direct notebook and Spark workload access to platform-owned database ports. Approved access continues through governed services such as Trino, the Hive Metastore API, and application APIs. Explicitly approved tenant or external JDBC connections remain possible through a separate governed egress and credential path.

This finding links to SEC-NB-002 because readable runtime credentials and internal database reachability compound blast radius, but it does not duplicate that finding's credential analysis.

Evidence and safety rules​

Safe evidence may include resource state, package coordinates, artifact paths, volume type and capacity, lifecycle timestamps, service identity, port number, and success or failure state. It must not include passwords, tokens, client secrets, decoded Secret data, notebook content, or database rows.

The live evidence distinguishes:

  • independently verified deployment, cache, artifact, and TCP observations;
  • a user-reported successful JDBC probe;
  • proposed security controls that are not current behavior;
  • unverified questions such as effective NetworkPolicy coverage and whether a workload identity can retrieve unrelated database credentials.

The implementation updates:

  • docs/features/notebook-execution/index.md with evidence dates, findings, limitations, and links;
  • docs/features/notebook-execution/architecture.md with dependency-resolution lifecycle and workload-to-internal-service trust boundaries;
  • docs/features/notebook-execution/live-evidence.md with NB-S023 and NB-S024;
  • new detailed findings for REL-NB-011 and SEC-NB-003;
  • docs/tenant-platform/infra/03-spark-operator.md with canonical package-cache behavior and lifecycle;
  • broader security documentation with links only when needed, avoiding a second copy of the finding.

Implementation references remain behind the existing component pages or assessment issue links, following repository policy.

Verification​

Verify the documentation by:

  1. building the Docusaurus site;
  2. checking internal links and navigation;
  3. confirming every new finding follows the assessment format;
  4. scanning changed text for credential-shaped material and prohibited secret values;
  5. confirming evidence claims match the captured live observations and label the JDBC result as user-reported;
  6. confirming reliability and security closure conditions are independently testable.