Zot push credential for pipelines: secret-extension rule + AppRole path #112

Merged

tepichord merged 8 commits from feat/110-zot-push-credential into main

2026-10-03 12:38:51 -07:00

tepichord commented

2026-09-29 19:14:37 -07:00

Owner

Closes #110

Automated PR created by forgejo-done adapter.

Closes #110 Automated PR created by forgejo-done adapter.

tepichord added 7 commits

2026-09-29 19:14:38 -07:00

feat(woodpecker): serve ZOT_TOKEN to annia-infra's publish step 586a2ab839

Add the third secret-extension rule `annia-infra-publish`: a push or
manual run of tepichord/annia-infra gets `ZOT_TOKEN` from the logical
path `ci/zot` — a rule of its own rather than a wider secret on
`annia-infra-merged-pr`, so the file stays a list of what each token is
for. Push-only events are the gate that keeps the registry password off
every pull request, and the file's two AppRole comments move from two
paths to three to match.

Refs: #110

docs(woodpecker-ci): grant the AppRole read on secret/data/ci/zot 4217eabb4c

§9k step 1's policy gains the read-only `path "secret/data/ci/zot"`
block, placed with the other secret paths ahead of the `auth/token/*`
blocks — the rule and the block are one change (§9k's invariant: no
block without a rule, no rule without a block), and the root write stays
before the ConfigMap is relied on. The section's intro and step-1
comments now say three paths and name the publish step as the third
consumer.

Refs: #110

docs(zot): the ci/ prefix is granted; the milner rule is what is left 09fc746cf7

The AppRole now reads `secret/data/ci/zot` and the
`annia-infra-publish` rule serves it, so the three passages saying the
prefix is ungranted (or that nothing reads the entry, or that §9k grants
exactly one path) are wrong: README's `milner/**` paragraph and
"what holds the credential" table note, values.yaml's `milner/**`
comment, and set-credential.sh's header. Each now states the truth that
matters — the grant exists, and the follow-on retiring `milner/**` waits
on a rule for tepichord/milner, not on the grant. `accessControl` and
the `--creds` follow-on are untouched, as scoped.

Refs: #110

docs(tests): the AppRole reads three paths, not both 90331500c4

The comment in test_secret_extension_serves_the_build_notification_
credential still said the shared credential reads "both paths"; with
the registry push credential it is three.

Refs: #110

test(gitops): pin the publish rule to its policy block bf56cf2bd9

test_secret_extension_serves_the_registry_push_credential asserts the
annia-infra-publish rule's repo, events and ZOT_TOKEN secret against
annia-infra#310's from_secret contract, that ZOT_TOKEN is served by its
own rule rather than a wider secrets list, and that every rule's
logical path has a `secret/data/<path>` block in §9k's HCL — the
"no rule without a block" invariant, which the out-of-band root policy
write (§4h) otherwise leaves unenforced.

Refs: #110

docs(woodpecker): trim duplicated secret-extension rule comments 75477c38a7

Refs: #110

docs(zot): the AppRole grants the ci/zot path, not the ci/ prefix

ci/woodpecker/pr/gates Pipeline was successful

Details

41b06fd684

The §9k policy names exactly `secret/data/ci/zot`; README.md, values.yaml and
set-credential.sh described it as the `ci/` prefix, which reads as a wildcard
grant the policy does not make. Say path, matching the plan's wording.