Code review · T4, kind and Kueue clusters in CI

review-code on autopilot/T4, range origin/autopilot/integration...7ae8838, 2026-10-28, tick 11. Reviewers: code-reviewer and security-reviewer, independent, in parallel. Format: README.md.

Round	Head	code-reviewer	security-reviewer
1	7ae8838	approve (0 blockers, 0 majors, 4 minors)	approve (0 blockers, 0 majors, 5 minors)
2	7fe53af (the round-1 fixes)	changes (0 blockers, 1 major, 1 minor)	changes (1 minor)
3	955a038 (the round-2 fixes)	approve (no findings)	approve (no findings)

Round 1 approved with minors; the fixes in 7fe53af were then reviewed as a delta (round 2), which found that the heads' deny check proved nothing (CR-T4-05). The round-2 fixes are in 955a038, approved in round 3. 4c9c64c then reads the task image from params.python_image, where the merge of #32 moved it (run 40673700904 had stopped on it); it was checked by shellcheck -x and CI, not re-reviewed. code-simplifier was not run; round 2's one simplification (CR-T4-07) was applied. Test command, in CI (kind needs cgroup v2):

bash dev/bootstrap.sh && bash dev/k8s/cluster.sh up kueue && \
  for s in kueue-wait nf26 runner; do bash tests/k8s/scenarios.sh "$s"; done

CODE  step=T4  review=approve b/M/m=0/1/6  security=approve b/M/m=0/0/6  rounds=3  simplify=notrun -0/+0  tests=pass

Id	Severity	Finding	Status
CR-T4-01	minor	RESULT runner: sufficient and tight claims a minimality the scenario does not measure	7fe53af (RESULT runner: sufficient; N out-of-Role calls denied); the Progress page says runner minimality is not measured
CR-T4-02	minor	install_kueue retries kubectl apply of the queues and goes on silently if every try fails	7fe53af (kubectl get clusterqueue cq-main cq-tight after the loop)
CR-T4-03	minor	up mini does not install the runner Role that the §4.2 k8s-mini row lists	recorded in the Progress page, Findings item 9, and in the §4.2 row
CR-T4-04	minor	cluster.sh copies the task image digest of the k8s profile, which can drift	7fe53af (read from tests/pipelines/synthetic/nextflow/nextflow.config, fails when absent)
SEC-T4-01	minor	The ServiceAccount kubeconfigs were written under .scenarios/, inside the repository that task pods mount as a hostPath, and first held the admin key	7fe53af (a mktemp -d directory under $RUNNER_TEMP, built from kubectl config view --raw --minify --flatten without users)
SEC-T4-02	minor	Task pods mount the default ServiceAccount token	7fe53af (default in spectio-work has automountServiceAccountToken: false; scenario_nf fails when the task pod has a kube-api-access-* volume)
SEC-T4-03	minor	Whoever can create Jobs or Pods in the shared namespace can run as any ServiceAccount there, mount a hostPath, and delete another run's pods	TRIAGE3
SEC-T4-04	minor	The runner deny list had 3 calls, and the heads had none	7fe53af (8 calls for the runner and both heads, plus create pods for the runner and nf-head-26)
SEC-T4-05	minor	Supply chain: the nf-k8s 1.2.3 plugin is fetched by version, the Kueue controller image is referenced by tag, and the whole bootstrap runs in the job	TRIAGE3
CR-T4-05	major	The heads' deny check ran through --as from the admin context, whose namespace is default, so every namespaced call was denied whatever the Roles held	955a038 (each ServiceAccount is checked with its own kubeconfig, whose context sets spectio-work)
SEC-T4-06	minor	The kubeconfig directory, holding 2-hour tokens, was never removed	955a038 (trap 'rm -rf "$KC_DIR"' EXIT)
CR-T4-07	minor (simplify)	The queue check after the retries named two of the five objects	955a038 (kubectl get -f kueue-queues.yaml)
CR-T4-08	minor	Found by CI once CR-T4-05 made the check real (run 40673827899): kubectl auth can-i create pods/exec reads exec as a pod name (TYPE/NAME, kubectl auth can-i --help), so nf-head-25, which may create pods, was reported allowed; the same held for serviceaccounts/token	--subresource=exec and --subresource=token