Epic: Per-function environment variables and flexible Secret/ConfigMap mapping

Epic for giving a Function first-class, per-function configuration: literal env vars, key-level Secret/ConfigMap references, whole-object projection, and a configurable mount path — with identical semantics on every executor.

Why this epic

Today the only per-function configuration channel is a pair of name-only references (FunctionSpec.Secrets/ConfigMaps) whose meaning differs by executor: poolmgr and newdeploy run a fetcher that writes them as files under a fixed /secrets/<ns>/<name> path, while the container executor injects them as whole-object envFrom. There is no way to set a plain DATABASE_URL=... at all without owning the Environment's podspec — which is per-environment, so values leak across every function sharing it.

Four long-standing issues ask for pieces of this:

• #1545 — Set environment variables from configmaps and secrets — the core 12-factor ask; every mainstream FaaS (Lambda, Cloud Functions, OpenFaaS) ships per-function env vars.
• #1556 — Flexible secret/configmap mapping — key selection, renaming, prefixing instead of all-or-nothing object references.
• #2407 — Custom secret/configMap file path — the file-projection path is hardcoded; code written for any other platform's layout must change.
• #3241 — Insecure secretKeyRef exposure patterns — informs the security section (reserved-name denylist, authenticated specialize channel, no resolved values in pod args).

The per-executor divergence is worse than a gap — it is a trap: moving a function between the container executor and poolmgr/newdeploy silently changes its configuration from env vars to files.

What "done" looks like

1. FunctionSpec carries env (corev1.EnvVar, literals + secretKeyRef/configMapKeyRef) and envFrom (corev1.EnvFromSource, optional prefix) — upstream types, so kubectl explain, GitOps schemas, and user intuition align; webhook narrows them.
2. Identical observable semantics on poolmgr, newdeploy, and container executors — native injection on per-function-pod executors; specialize-time injection (references-only on the wire, resolved pod-locally by the fetcher) behind a runtime capability gate on poolmgr.
3. Rotation propagates: rotating a referenced Secret/ConfigMap recycles exactly the referencing functions, including references made only via the new fields.
4. MountPath on the existing references (#2407): redirects the file projection, constrained to the /secrets and /configs roots for cross-executor consistency.
5. CLI parity: fission fn create/update --env-var/-e, --env-from-secret, --env-from-configmap, mirrored by fission spec and the run-local loop.
6. Security invariants hold: reserved platform names denied/dropped (FISSION_*, proxy/interpreter-hijack vars), no resolved secret value in executor logs/pod args/events, env injection honored only on an authenticated specialize channel.

Sub-issues

• #1545 — per-function env vars from literals, configmaps and secrets
• #1556 — key-level Secret/ConfigMap mapping (select, rename, prefix)
• #2407 — configurable mount path for file projection
• #3241 — secretKeyRef exposure audit folded into the security/docs section

RFC

RFC-0030 (Per-function environment variables and flexible Secret/ConfigMap mapping) covers the CRD surface, the executor-by-executor injection design, the specialize-channel security analysis, capability gating for poolmgr, change propagation, and CLI surface. It will be published for review; this issue tracks the work.