feat(sec): provision the narrow conformance CI trigger credential -- and refuse to arm a fake green

Conversation 1 Commits 3 Files Changed 3

+769 -3

3 Commits

Author	SHA1	Message	Date
jakman85andClaude Opus 5	ad5de2dba9	docs(decisions): move PR #19 's handoff out of the frozen DECISIONS-LOG.md gate / gate (pull_request) Successful in 1m35s Details gate / conformance (pull_request) Has been skipped Details This branch originally appended ~99 lines to the tail of DECISIONS-LOG.md. That tail is the hunk every concurrent branch collides on: measured against the live Gitea on 2026-09-29, four of the five open PRs were mergeable:false and DECISIONS-LOG.md was the ONLY conflicting path in all four. PR #19 was one of them. Nothing was wrong with the change; the log's storage format serialised work that was otherwise parallel. So the handoff now lives in its own file, decisions/2026-09-29-conformance-trigger-kubeconfig.md, in the one-entry-per-file layout PR #24 introduces (frontmatter date/branch/title, plus "What changed" / "What I verified" / "What I did NOT verify"). Concurrent branches then touch disjoint paths and there is nothing to merge. The branch was rebuilt on today's main with the DECISIONS-LOG.md change dropped entirely; infra/gitea/README.md and infra/gitea/conformance-trigger-kubeconfig.sh are byte-identical to the original commits. The original commit that touched ONLY DECISIONS-LOG.md -- the measurement that PR #19's CI has no approval-policy check -- was dropped as a commit and its substance folded into the new entry verbatim in meaning, including every UNVERIFIED it recorded. No content was upgraded. The script is still UNEXECUTED: nothing minted, no Gitea object written, no kubectl mutation, and the Gitea variables API shape remains documentation rather than measurement. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>	2026-09-29 22:51:14 -05:00
jakman85andClaude Opus 5	ae5c7385a5	docs(gitea): the README still named the ILLEGAL secret GITEA_SETTINGS_TOKEN PR #15 renamed the Actions secret to SETTINGS_API_TOKEN because Gitea RESERVES the GITEA_ prefix and rejects such a name with HTTP 400 "invalid secret name" -- the defect that left the branch-protection detector inert and unnoticed. The README in this very directory, which documents that story, went on naming the illegal name in its behaviour table and in its closing "remaining step" line. Both now say SETTINGS_API_TOKEN, plus a note recording what ci/gitea-settings.sh ACTUALLY does, quoted from the file rather than assumed: TOKEN="${SETTINGS_API_TOKEN:-${GITEA_SETTINGS_TOKEN:-}}" GITEA_SETTINGS_TOKEN is still honoured, but ONLY as an environment variable for a local run -- it can never be the CI wiring, because the secret that would feed it cannot be created at all. The closing line also predated PR #15 storing the secret; it now says so. Documentation only. No behaviour change. NOT fixed here, because it is outside this PR's diff: ci/gitea-settings.sh:45 still instructs the reader to "create a Gitea repo secret GITEA_SETTINGS_TOKEN", which is impossible. Same defect, different file -- worth its own one-line change. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>	2026-09-29 22:47: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

Author

SHA1

Message

Date

jakman85andClaude Opus 5

ad5de2dba9

docs(decisions): move PR #19 's handoff out of the frozen DECISIONS-LOG.md

gate / gate (pull_request) Successful in 1m35s

Details

gate / conformance (pull_request) Has been skipped

Details

This branch originally appended ~99 lines to the tail of DECISIONS-LOG.md. That
tail is the hunk every concurrent branch collides on: measured against the live
Gitea on 2026-09-29, four of the five open PRs were mergeable:false and
DECISIONS-LOG.md was the ONLY conflicting path in all four. PR #19 was one of them.
Nothing was wrong with the change; the log's storage format serialised work that
was otherwise parallel.

So the handoff now lives in its own file, decisions/2026-09-29-conformance-trigger-kubeconfig.md,
in the one-entry-per-file layout PR #24 introduces (frontmatter date/branch/title,
plus "What changed" / "What I verified" / "What I did NOT verify"). Concurrent
branches then touch disjoint paths and there is nothing to merge.

The branch was rebuilt on today's main with the DECISIONS-LOG.md change dropped
entirely; infra/gitea/README.md and infra/gitea/conformance-trigger-kubeconfig.sh
are byte-identical to the original commits. The original commit that touched ONLY
DECISIONS-LOG.md -- the measurement that PR #19's CI has no approval-policy check
-- was dropped as a commit and its substance folded into the new entry verbatim in
meaning, including every UNVERIFIED it recorded.

No content was upgraded. The script is still UNEXECUTED: nothing minted, no Gitea
object written, no kubectl mutation, and the Gitea variables API shape remains
documentation rather than measurement.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

2026-09-29 22:51:14 -05:00

jakman85andClaude Opus 5

ae5c7385a5

docs(gitea): the README still named the ILLEGAL secret GITEA_SETTINGS_TOKEN

PR #15 renamed the Actions secret to SETTINGS_API_TOKEN because Gitea RESERVES the
GITEA_ prefix and rejects such a name with HTTP 400 "invalid secret name" -- the
defect that left the branch-protection detector inert and unnoticed. The README in
this very directory, which documents that story, went on naming the illegal name in
its behaviour table and in its closing "remaining step" line.

Both now say SETTINGS_API_TOKEN, plus a note recording what ci/gitea-settings.sh
ACTUALLY does, quoted from the file rather than assumed:

    TOKEN="${SETTINGS_API_TOKEN:-${GITEA_SETTINGS_TOKEN:-}}"

GITEA_SETTINGS_TOKEN is still honoured, but ONLY as an environment variable for a
local run -- it can never be the CI wiring, because the secret that would feed it
cannot be created at all. The closing line also predated PR #15 storing the secret;
it now says so.

Documentation only. No behaviour change.

NOT fixed here, because it is outside this PR's diff: ci/gitea-settings.sh:45 still
instructs the reader to "create a Gitea repo secret GITEA_SETTINGS_TOKEN", which is
impossible. Same defect, different file -- worth its own one-line change.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

2026-09-29 22:47: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

feat(sec): provision the narrow conformance CI trigger credential -- and refuse to arm a fake green #19