Fission

### Summary The Fission router registers an internal-style route — `/fission-function/` and `/fission-function//` — for every `Function` object, independent of whether any `HTTPTrigger` exists for that function. The route was mounted on the same listener as user-defined `HTTPTrigger`s (`svc/router`, port 8888), so any caller who could reach the router could invoke any function by guessing its `metadata.name` (and namespace), bypassing the host / path / method / method-allow-list restrictions encoded in `HTTPTrigger` objects. ### Affected component - `pkg/router/httpTriggers.go:280-284` — `internalRoute` registration via `utils.UrlForFunction(fn.Name, fn.Namespace)`, bound to the function handler. ### Impact An external caller who reaches the public router could: 1. Invoke functions that the operator intentionally did not publish through an `HTTPTrigger` (e.g. functions used only as Kubewatcher / Timer / MessageQueue trigger targets, internal helpers, or sample functions). 2. Bypass `HTTPTrigger`-level restrictions: a function published only on `POST /api/v2/foo` could still be invoked as `GET /fission-function//` with arbitrary headers and body. 3. Enumerate function names by probing the response semantics (404 vs 200 vs 502 from cold start). In multi-tenant deployments this also crosses tenant boundaries when functions in tenant namespace B are reachable from tenant A's pods (or from anywhere on the internet if the router is ingress-exposed). ### Root cause `/fission-function/...` was historically used by internal trigger sources (timer, kubewatcher, mqtrigger) that share the cluster network with the router, but the route was registered on the public listener that also serves user `HTTPTrigger`s. The two audiences were never separated. ### Fix Released in [v1.23.0](https://github.com/fission/fission/releases/tag/v1.23.0): - **PR #3369** (commit `814d232c`): the router now runs **two** listeners — a public listener (port 8888, `svc/router`) that serves only user-defined `HTTPTrigger`s, `/router-healthz`, and `/_version`, and an internal listener (port 8889, `svc/router-internal`, ClusterIP-only) that exclusively serves `/fission-function//`. The internal listener is wrapped with the `pkg/auth/hmac.ServiceVerifier` using the `ServiceRouterInternal` derived key — internal trigger sources sign their requests with a per-service HKDF-derived key from a cluster master secret. Empty master secret falls back to pass-through (preserves compatibility for clusters not yet rotating in a secret). - **PR #3365** (commit `0aa24788`): added per-service `NetworkPolicy` resources to `charts/fission-all`, ensuring `svc/router-internal` is only reachable from `kubewatcher`, `timer`, `mqtrigger`, and `mqt-keda` pods inside the release namespace. - The internal-listener path itself is still **`/fission-function//`** — only its location moved. ### Mitigation (until upgrade) 1. Apply a `NetworkPolicy` to the Fission namespace that allows ingress to `svc/router` (port 8888) only from the consuming project's ingress controller, and blocks `/fission-function/...` at the ingress layer (path-based filter on the ingress). 2. Avoid exposing the router directly via LoadBalancer/NodePort; front it with an ingress that path-filters `/fission-function/`. 3. Treat function `metadata.name` as **not** a secret — names should not be the access control boundary.

### Summary Fission runtime pods were created with `ServiceAccountName: fission-fetcher`, and the `fission-fetcher` ServiceAccount was granted namespace-wide `get` on `secrets` and `configmaps` (it needs that to load function code, env vars, and config). The runtime pod's automounted token was reachable from inside the user's function container at `/var/run/secrets/kubernetes.io/serviceaccount/token`, so user-supplied function code inherited the same Kubernetes API privileges and could read any secret or configmap in the function's namespace — far beyond the `Function.spec.secrets` allowlist that the function specification suggests. ### Affected component - `pkg/executor/executortype/poolmgr/gp_deployment.go:154-156` — pool-manager runtime pod `ServiceAccountName`. - `pkg/executor/executortype/newdeploy/newdeploy.go:225-227` — new-deploy runtime pod `ServiceAccountName`. - `pkg/utils/serviceaccount.go:51-64` — `fission-fetcher` RBAC: namespace-wide `get` on `secrets` / `configmaps`. ### Impact A user able to deploy or update a function in any namespace where Fission runtime pods are scheduled could: 1. Read every secret in that namespace (TLS keys, OIDC client secrets, database credentials, cloud provider credentials). 2. Read every configmap in that namespace. 3. Use those credentials to pivot to other Kubernetes resources or external systems the secrets unlock. This violates the principle that `Function.spec.secrets` is the authoritative declaration of which secrets a function can read. ### Root cause The fetcher sidecar legitimately needs the SA token to call the Fission control plane and fetch package archives. Setting `ServiceAccountName: fission-fetcher` on the pod gives every container in the pod (including the user container) the automounted token. Kubernetes does not provide per-container service-account scoping inside a single pod, so the user container has to be moved into a separate identity / token-mount scheme. ### Fix Released in [v1.23.0](https://github.com/fission/fission/releases/tag/v1.23.0): - **PR #3366** (commit `fe1842ef`): - The user function container now sets `AutomountServiceAccountToken: false` at the container level (via projected-volume token suppression), so the user container no longer sees the pod's SA token even though the fetcher sidecar still does. - The fetcher sidecar retains its existing token mount (separate projected volume) since it needs cluster API access for its own work. - For the few legitimate use cases where a function needs its own Kubernetes API access, the user is expected to mount a different ServiceAccount via `Function.spec.podspec` with the minimum necessary RBAC (documented separately). ### Mitigation (until upgrade) 1. Restrict who can create / update `Function` and `Package` CRDs in your cluster — treat the ability to ship function code as equivalent to namespace-wide secret read. 2. Reduce the `fission-fetcher` ClusterRole / Role scope where possible (e.g. constrain it to specific named secrets via separate Role bindings). 3. Add NetworkPolicy egress rules denying function pods access to the Kubernetes API server (this blunts the token even if it leaks).

### Summary The Fission `storagesvc` component registers archive CRUD handlers (`/v1/archive` GET / POST / DELETE and `/v1/archives` list) directly on its HTTP router without performing any authentication or authorization. Any caller able to reach the `storagesvc` ClusterIP — including any other workload in the same Kubernetes cluster — could enumerate archive IDs, download archives belonging to other tenants, upload arbitrary archive content, and delete archives. ### Affected component - `pkg/storagesvc/storagesvc.go` — handler registration and per-route handler logic at lines 72-95 (list), 167-199 (download/delete), and 263-270 (route wiring). ### Impact A workload elsewhere in the cluster (e.g. a compromised function pod, a noisy-neighbour tenant in a multi-tenant deployment, or any pod whose egress is not constrained by NetworkPolicy) could: 1. Enumerate every function deployment archive in the cluster. 2. Download the deployment archive of any function in any namespace, exposing the function's source code and any embedded secrets. 3. Delete archives, causing the next function specialization or rebuild to fail. 4. Upload arbitrary archives that subsequent function specializations would fetch and execute. In multi-tenant Fission deployments this completely breaks the tenant boundary for function code. ### Root cause `pkg/storagesvc/storagesvc.go` mounts the handlers without an authentication middleware. Network-layer controls (`NetworkPolicy`) were the only line of defence before this fix, and the chart shipped no `NetworkPolicy` for `storagesvc` by default, so reachability was open. ### Fix Released in [v1.23.0](https://github.com/fission/fission/releases/tag/v1.23.0): - **PR #3368** (commit `2455fc0c`) wraps the `storagesvc` archive routes with the application-layer HMAC verifier from `pkg/auth/hmac` using the `ServiceStoragesvc` derived key. Callers (executor, fetcher, builder, CLI) sign their requests using a shared cluster master secret derived per-service via HKDF. Mismatched signatures are rejected with `401`. - Defence in depth: **PR #3365** added a `NetworkPolicy` for `storagesvc` so only the executor/fetcher/builder pods can reach it network-layer (independent of authentication). ### Mitigation (until upgrade) 1. Enable the Helm chart's per-service NetworkPolicy (set `networkPolicy.enabled=true`). 2. Restrict `storagesvc` egress/ingress to the executor, builder, and fetcher pods only. 3. Avoid running untrusted workloads in the cluster that hosts Fission.

### Summary Before the round-1 security sweep, `pkg/builder/builder.go` passed `Environment.spec.builder.command` directly into `exec.Command(...)` after a `strings.Fields` split, with no validation of the executable path or its arguments. A user who could create or update `Environment` CRDs in a namespace observed by the buildermgr could thereby point the builder pod at any executable inside the builder image (e.g. `/bin/sh -c '...'`) and execute arbitrary code in the builder pod context. ### Affected component - `pkg/builder/builder.go:254` — call site (`exec.Command(buildCmd, buildArgs...)`). - `pkg/builder/builder.go:106` — input source: `buildCmd, buildArgs = strings.Fields(req.BuildCommand)[0], strings.Fields(req.BuildCommand)[1:]`. ### Impact A subject with `create` / `update` privilege on `Environment` objects could: 1. Cause the builder pod for any package using that environment to execute arbitrary code. 2. Read whatever files the builder pod has access to inside its `/packages` shared volume (deployment archive payloads for that package). 3. Write arbitrary content into the `/packages` shared volume, which the fetcher subsequently uploads as the package deployment archive. The builder pod runs in the user's namespace with the `fission-builder` SA (not the more-privileged executor SA), so the impact is bounded to that namespace's package contents and the builder pod's own filesystem. `PR:H` reflects that creating / modifying `Environment` CRDs is typically restricted to cluster admins or platform operators. ### Root cause `pkg/builder/builder.go`'s build-command parser did not validate the resulting executable path. Although `exec.Command` does not invoke a shell, it does locate the executable via `$PATH`, and `strings.Fields` splitting allowed multiple flags / sub-arguments to be passed. ### Fix Released in [v1.23.0](https://github.com/fission/fission/releases/tag/v1.23.0): - **PR #3364** (commit `0f45c911`) introduces `Builder.resolveBuildCommand` in `pkg/builder/builder.go`, which: 1. Accepts an empty string (treated as the default `/build`). 2. Accepts the literal `/build`. 3. Accepts any absolute path that survives `filepath.Clean` and contains no `..` segments. 4. Rejects anything containing whitespace metacharacters or relative paths. - `exec.Command` still receives only the validated absolute path; sub-arguments continue to come from `strings.Fields` of the original string but are now passed positionally with no shell expansion. ### Mitigation (until upgrade) 1. Restrict who can create / update `Environment` CRDs to trusted operators only. 2. Audit `Environment.spec.builder.command` values for any non-`/build` paths. 3. Run the buildermgr with a tightened ServiceAccount that has no secret access in the builder namespace.