2 Commits

Include renames

Author	SHA1	Message	Date
jakman85andClaude Opus 5.5	e539109830	feat(images): build, verify and publish the three images in CI; Renovate carries the digests ... Operator rule 2026-10-29: image creation, hosting and lifecycle belong to CI/CD, never to a workstation build/push. Nothing had ever been pushed to the Gitea registry. - .gitea/workflows/images.yaml + scripts/images.sh: PRs build+verify (no credential); main builds, verifies and pushes toolbox, agent-runner (FROM toolbox) and conformance-runner as sha-<commit> + main, reading the digest back from the registry. Only changed images build. - Each image's own build-image.sh does the build and in-image verification, now engine-neutral (DinD: no podman-only calls, probe over stdin not a bind mount). New toolbox build-image.sh. - Digest references carry `# renovate-digest:` markers; renovate.json5 gains a custom.regex manager for them. The worker Job template is deliberately untracked (it would loop). - renovate.yaml pins renovate-version 44.167.0: the action's default (39.264.0) rejects the current config's managerFilePatterns, so every run would have died at CONFIG_VALIDATION. - Push credential: REGISTRY_PUSH_TOKEN secret; the Actions token has no package scope in Gitea 1.24.3 (container.go Authenticate). Retention: infra/gitea/registry-retention.sh. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-29 23:59:55 -05:00
jakman85andClaude Opus 5	19f9a8ae0c	feat(sec): provision the narrow conformance CI trigger credential -- and refuse to arm a fake green ... docs/plans/l2-l3-conformance-ci-wiring.md §3 item 6, as an operator script: infra/gitea/conformance-trigger-kubeconfig.sh. UNEXECUTED here -- minting a cluster credential and changing Gitea variables are operator actions. It mints a token for conformance/conformance-trigger (TokenRequest), wraps ONLY that token with the cluster CA and server into a kubeconfig, and stores it as the Actions secret CONFORMANCE_TRIGGER_KUBECONFIG. Never cluster-admin, never a copy of the operator's own kubeconfig. The token is never printed and never reaches argv: it goes into a 0600 file and into the PUT body FILE (--data @file), and the script refuses to run under `set -x` because xtrace would print it. Two traps this repo already paid for are designed around: * GITEA_ is a RESERVED secret-name prefix (HTTP 400 "invalid secret name"), so the name is CONFORMANCE_TRIGGER_KUBECONFIG -- which is also what gate.yml and merge-gate.yaml already reference. * `curl -sS` exits 0 on an HTTP error. Every write checks %{http_code} AND reads the object back. The secret read-back proves presence by NAME only (Gitea never returns secret values) and the script says so rather than implying its content was checked; the variable read-back asserts the value is exactly "true", which is what gate.yml compares against. PRECONDITIONS ARE SPLIT IN TWO, and the split is the security argument: mint-blocking (cluster) -- SA/Role/RoleBinding present, and ClusterPolicy conformance-trigger-job-shape present + Enforce + failurePolicy Fail + Ready. Any failure and NOTHING IS MINTED. Kubernetes places no `use` check on a Job's serviceAccountName, so a `create jobs` token in that namespace IS the privileged conformance-runner identity unless admission bounds its shape. RBAC cannot close that (plan §4); minting before the boundary is live hands CI the escalation the boundary exists to close. arm-blocking (repo) -- digest-pinned CONFORMANCE_RUNNER_IMAGE, an initContainer plus the admitted image in chainsaw-job.yaml, and CONFORMANCE_TRIGGER_KUBECONFIG referenced in ci/conformance.sh CODE rather than a comment. These block only vars.CLUSTER_AVAILABLE, because storing the secret early is harmless (the job is gated off) and is the plan's own order. All three arm-blocking checks FAIL in the tree today, so a live run would store the secret and then REFUSE to arm CLUSTER_AVAILABLE, naming each missing item. That is the intended behaviour: measured 2026-09-29, CLUSTER_AVAILABLE=true with no trigger path scaffold-skipped all 54 tests at rc 0 and the stage printed "L2/L3 conformance passed". ci/conformance.sh now blocks that case, so arming early does not enable L2/L3 -- it only breaks every PR. Arming needs the explicit flag, every precondition green, and a typed confirmation on a TTY. Before storing anything, the credential is PROVEN narrow: auth whoami must be system:serviceaccount:conformance:conformance-trigger, a real `get jobs` round-trip must succeed, and an auth can-i matrix asserts both halves -- granted (create/get jobs, get pods, get pods/log) and DENIED (delete jobs, create pods/exec, get secrets, create jobs in default, get nodes, '*' '*' --all-namespaces). A mismatch aborts before any store, and says explicitly not to widen conformance/incluster/rbac.yaml to make it pass. Verified only by `bash -n` (clean) and reading. The Gitea variables API shape (POST creates, PUT updates, body field `value` not `data`) is from documentation, not measurement: the script tries POST then PUT, prints the response body on failure, and treats the read-back as the authority. Kyverno readiness is accepted from either .status.ready or a Ready condition, and "neither present" blocks rather than assuming ready. Gate (pinned toolbox): MERGE GATE: UNDETERMINED (rc 3) -- spec-immutability and gitea-settings unrun, the expected local result. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>	2026-09-29 22:47:55 -05:00