Threat model

A short STRIDE-style threat model for knext's real components — not a generic web-application checklist. It is written for the platform and security teams who have to decide whether to run knext, and it states residual risk instead of implying it away. Each mitigation links to the page that documents the behavior: Security, Hardening and Operator & the NextApp CRD.

STRIDE: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege.

What is protected

• Cluster state. NextApp resources and the Knative Services and NetworkPolicies the operator reconciles from them. The operator is the single source of truth, so corrupting it corrupts every deploy.
• Published images. The operator image and your application images, plus their base images. They are signed and run in your cluster.
• Secrets. The cache-invalidation token, database DSNs and registry credentials. They live only in Kubernetes Secrets and environment.
• The ISR and data cache. Redis-backed; poisoning it serves wrong content.

Trust boundaries

1. The operator reconcile path: API server, then the controller, then Knative and NetworkPolicy objects.
2. Gateway to backend calls.
3. The cache-invalidation endpoint.
4. The supply chain: base image, build, SBOM and scan, registry, cluster pull.
5. The metrics scrape: Prometheus to the operator and to each app pod.
6. Request ingress to an app pod.

1. Operator reconcile path

2. Gateway to backend calls

3. Cache-invalidation endpoint

4. Supply chain

Base-image patching

Runtime stages of the shipped Alpine images run a whole-base apk upgrade on top of a digest-pinned base. That pulls only fixes already published on the same pinned Alpine branch — it cannot move the base to a different release. The trust anchor for what shipped is the scanned and signed output digest, not the input.

The vinext build target: scanning a compiled binary

The opt-in vinext target compiles to one executable with every JavaScript dependency inlined. An image scan of such an image can read the operating-system packages but nothing inside the binary, so a clean image scan there is clean because there is nothing left to scan. The mitigation is to scan the dependency tree that feeds the compiler, before it is compiled: knext's CI generates an SBOM over the installed tree and fails on HIGH and CRITICAL findings.

Two honest limits. The scan gates the reference example application, not yours: an application you build on the vinext target has no equivalent closure gate yet, so run your own SBOM and vulnerability scan over your installed dependencies before compiling. And the closure SBOM is a build artifact, not yet attached to the image as a signed attestation.

Native image-processing libraries

A vinext image ships the image-optimization native addon and its libvips libraries beside the executable, because a compiled binary cannot load native code from inside itself. That is the one place native code is neither compiled in nor covered by an SBOM, so it is pinned two ways:

• Provenance, at build time. Every staged native package must appear in the lockfile at exactly the version on disk, or the build fails. This pins which package, not which bytes.
• Bytes, at load time. The build writes a per-file SHA-256 manifest, and the loader re-hashes every native file it lists — libvips included — before loading. A mismatch, or an unlisted file, is fatal.

Residual risk. An image with no manifest warns and loads, because failing closed on absence would break images built before the manifest existed. The template Dockerfile fails the build if the manifest is missing, which narrows the window to an image modified after build. To close it today, set KNEXT_REQUIRE_NATIVE_INTEGRITY:

The last row is deliberate: a value the runtime cannot parse is neither read as "on" nor as "off", because guessing either way fails silently. A typo surfaces as a crash loop that names the accepted values. Set it from a reviewed manifest, not by hand on a live workload.

5. Metrics scrape

The operator exposes its metrics over HTTPS with a self-signed certificate by default, and the shipped ServiceMonitor scrapes with insecureSkipVerify: true. The endpoint requires authentication and authorization, so anonymous scrapes are rejected.

Decision. Skipping verification is accepted for the default install: the endpoint is cluster-local and read-only, the scrape is authenticated, and the metrics carry no secrets. To close the residual risk, enable cert-manager and the metrics TLS patch shipped with the operator, which references a serving-certificate Secret instead of skipping verification.

6. Request ingress to an app pod

Two paths reach a knext app and they are bounded differently. External traffic passes the load balancer, the Kourier gateway (Envoy), the activator and queue-proxy, then your container — three HTTP parsers, with containerConcurrency enforced. In-cluster traffic is a co-resident pod dialling the app pod directly. The default NetworkPolicy closes the second path by admitting only the queue-proxy and metrics ports (see Security), and a request-body cap is enforced inside the app on every build.

Scraping across namespaces

The default policy admits only knative-serving, kourier-system and the app's own namespace. A Prometheus in another namespace is admitted on the app metrics port only (9464) once that namespace carries the label knext.dev/metrics-scrape=true. A cluster that labels nothing keeps the stricter posture.

This is namespace RBAC, not a per-app privilege boundary. The label is on a cluster-scoped Namespace object, so whoever holds update namespaces can grant it — on a platform with self-service namespaces a tenant can grant itself. Once labelled, every pod in that namespace can scrape 9464 on every knext app, which on a shared cluster is cross-tenant metric disclosure. What is exposed is the exporter's seven series families, enumerated:

• knext_bunexec_http_requests_total, knext_bunexec_http_request_duration_seconds, knext_bunexec_http_inflight_requests, knext_bunexec_startup_duration_seconds, knext_bunexec_process_resident_memory_bytes and knext_bunexec_process_uptime_seconds, plus knext_deep_health_state.
• knext_deep_health_state is forwarded from your app's own registry, with tracing on or off, and is present only while the app has used its database in the last 45 seconds; an idle app serves no such series. It carries app, dependency and state labels with fixed values (twelve series per pod) — no host names, connection strings or error text — and tells an observer whether the app's database or cache is currently up. Nothing else from the app's registry is forwarded.
• No route, path, query, payload or method labels. The request counter carries only a status_class with five fixed values.
• From these an observer can infer request volume and error ratio, restart and scale-to-zero timing (and from it traffic patterns), and a coarse memory-load signal.

:9464 serves GET /metrics and nothing else. You cannot narrow the grant by adding a second NetworkPolicy, because policies are additive. To express a tighter grant, set spec.security.networkPolicy: false and write your own policy. Two operability gaps: a mistyped label value fails silently with scraping simply denied, and an app owner gets no signal that their app is being scraped from another namespace. Revocation applies to new connections; established keep-alive connections can outlive unlabelling.

Out of scope

• Global edge, WAF and CDN-layer DDoS protection. knext does not own the edge.
• Vulnerabilities in your application's business logic. knext secures the platform surface, not the tenant's code.
• Cross-zone data sovereignty. A zone owning its data and never reading another's is an architectural rule covered in SCS and zones.