Configuration

Every setting of the wrapper, the web front, the results proxy, the converter, the htrflow-batch chart and the frontend build, generated from the config models, the chart's values.yaml and the frontend's config.ts. The htrflow-devstack chart — the development support stack (RustFS, an in-cluster registry, devStack.insecureDefaults, rustfs.accessKey/secretKey) — is a separate surface, documented in its own README.

The wrapper's Config is not all it reads from the environment: the few names read directly are listed under "Also read from the environment", and described in Wrapper. Where the web front falls back to a computed value rather than the model's own default, the Default column says so.

Read outside these models. htrflow-campaigns apply reads HTRFLOW_APPLIED_BY, stamped as applied-by on each campaign it applies; unset, it uses the OS user (htrflow-campaigns CLI).

What the browser is told comes from /config.js, which the web front writes from HTRFLOW_RESULTS_URL; there is no second copy to keep in step (Web front & read API).

Two caps. FETCH_MAX_BYTES bounds an image on the wire and MAX_IMAGE_PIXELS bounds what decoding it costs; a page over either fails without a retry.

Security in four points

• Credentials are mounted files, with one scoped exception: S3 credentials reach a pod as a mounted Secret file (AWS_SHARED_CREDENTIALS_FILE, /secrets/s3/credentials), and packages/wrapper/tests/test_config.py fails if any field of these models, or any literal env read in the wrapper, is ever named like one. The exception is HF_TOKEN, which huggingface_hub reads from the environment: converter.yaml's hf_token_secret names a Secret whose token key the converter renders as HF_TOKEN into the warm-up pod alone — the short-lived pod that downloads models and holds nothing else. Campaign pods get neither the env nor the Secret name, and the test's exemption is per file, so reading a token anywhere but the warm-up entrypoint still fails. The devstack's own S3 store refuses to render on credentials nobody chose (devStack.insecureDefaults).
• The read API needs a login, the site does not: GET /api/v1/jobs[/…] answers 401 without a session on the results store, but the campaign browser's page, which asks for the login, is served to anyone who can reach the port. The network decides who gets that far: on a NodePort, network.web.ingressCidrs (the clients' own addresses); behind an ingress controller (web.ingress), network.web.ingressFrom names the controller and the controller's own allow-list is what keeps browsers out.
• The read API's RBAC is get and list, plus one write: create and patch on ConfigMaps in its own namespace, for the per-campaign status ConfigMap it writes from what it observes (The record a campaign leaves). It is a namespaced Role; it grants no watch or delete and no write to a Job or a Pod, and test_chart_agreement.py holds the rendered Role to exactly that. With security.policies.enabled, a Kyverno rule also holds its ConfigMap writes to names of the form campaign-<name>-status.
• The results bucket is private: nothing in it is anonymous. The results proxy reads it with each logged-in person's own store keys, sealed in an HttpOnly cookie only the proxy can open, and no pod holds a credential to read results. See the results boundary.

The Set by column says who can set each key in a deployment, read off what really sets it: the converter's Job skeleton and the job-shape policy's list of the env a Job may carry, the chart's web Deployment, the images' own ENV and the compose stack. A local run only means exactly that: nothing in a deployment can set it — no converter key renders it, and with security.policies on, job-shape refuses a Job that sets it — so it is for a hand run of the image, or the compose stack. The chart sets HTRFLOW_NAMESPACES to its own release namespace and offers no value for it: the read API parses a list, but one release reads one namespace.

The Security column below reads what the key exposes — who enforces it: cluster = the API server or an admission policy, render = helm template refuses it, nobody = convention only.

wrapper — the batch Job's container

Each key is an environment variable of the container.

Config is not the whole wrapper env: these 6 names are read directly, by the warm-up entrypoint or by the Job skeleton, never as a campaign setting.

Also read from the environment

web — the read API and campaign browser

Each key is an environment variable of the container.

results — the results proxy (htrflow-results)

Each key is an environment variable of the container.

converter — a campaigns repo

Each key is a key of converter.yaml.

chart — charts/htrflow-batch

Each key is a key of its values.yaml.

frontend — the campaign browser's build

Each key is an environment variable of bun run build, baked into the bundle: the published image builds with none set.

One-sided keys

namespace is the release namespace (a helm -n argument, not a chart value), and runtime_class has no chart key at all, so neither can be checked mechanically. The Hub-token Secret, like the S3 one, is the operator's own object: the chart names it only to allow it. The chart's queue quotas, NetworkPolicy CIDRs and image settings have no converter counterpart. Prose lives in Chart Values, Campaign & Pipeline YAML and Wrapper.