feat(pm-agent): pin the first published agent-runner digest, start dry, and fix the token scopes

Rebased #61 onto the CI image pipeline (#81). This commit makes the remaining in-git blockers to going live go away: - deployment.yaml and PM_WORKER_IMAGE pin images run 340's digest (sha256:c4eba5b3..., tag sha-523cd9118f95 = main), read from the registry. Renovate markers unchanged. - PM_DRY_RUN=true and PM_REQUIRE_LABEL=agent for the first run. Dry run is required, not just cautious: the run-340 image's baked worker template predates imagePullSecrets, so admission would deny its Jobs until CI re-publishes after this merge and Renovate bumps. - Token scopes: Gitea 1.24.3 scopes GET /api/v1/user (the dispatcher's first call) under read:user. The documented list was missing it. Now read:user, write:repository, write:issue, read:package everywhere. - Org-package read documented as a team (Packages=Read, no repos), not just a scope. - sops is toolbox-only; the .examples say so and give the in-place edit. - runbook: key-name check no longer emits Secret values before the pipe. Co-Authored-By: Claude Opus 5.5 <[email protected]>
2026-10-30 01:16:21 -05:00
1 parent a7eadd4054
commit 7f0cbc7ba2
@@ -46,15 +46,17 @@ waive the sensitive-path human review on its own pull request.
 Both are deliberate, and both fail **visibly** rather than silently:

 1. **The image is published by CI, not by a person.** `platform/pm-agent/deployment.yaml` and
-   `PM_WORKER_IMAGE` in `configmap.yaml` carry an all-zero digest placeholder until the first
-   publish. `.gitea/workflows/images.yaml` builds `agent-runner` on rootless BuildKit
+   `PM_WORKER_IMAGE` in `configmap.yaml` carry the digest of the **first** publish (images
+   run 340, `sha-523cd9118f95`), pinned once on 2026-10-30 so going live did not wait on
+   Renovate's first run; every later bump is Renovate's. That digest predates the worker
+   template's `imagePullSecrets` entry, so worker Jobs built from it are refused by
+   admission — which is why `PM_DRY_RUN` starts `true` (see `configmap.yaml`). `.gitea/workflows/images.yaml` builds `agent-runner` on rootless BuildKit
   (`platform/buildkit/`) — the same Containerfile, and the same `verify` stage, that
   `infra/agent/build-image.sh` builds locally — and on a push to `main` publishes it to
   `gitea.home.keithjackson.dev/home-network/agent-runner` under `sha-<commit>` and `main`.
   Renovate then follows the `main` tag through the `# renovate-digest:` marker above **both**
   lines and moves them together in one pull request. Nobody builds-and-pushes this image from
-   a workstation, and nobody pastes a digest. Until the first publish, and until that PR
-   merges: `ImagePullBackOff`. The one operator prerequisite on the publishing side is the
+   a workstation. The one operator prerequisite on the publishing side is the
   `REGISTRY_PUSH_TOKEN` Actions secret (see the header of `.gitea/workflows/images.yaml`);
   without it the publish job fails loudly rather than skipping.

@@ -83,7 +85,7 @@ Both are deliberate, and both fail **visibly** rather than silently:
     `pm-agent-registry` is a `dockerconfigjson` Secret referenced by both the Deployment and
     the committed worker Job template, and the admission policy pins it to exactly that
     name. What is left to you is the value: the Gitea token must carry **`read:package`** in
-     addition to `write:repository` and `write:issue`, and the dockerconfigjson is built from
+     addition to `read:user`, `write:repository` and `write:issue`, and the dockerconfigjson is built from
     it. Steps:
     [`pm-agent-registry.sops.yaml.example`](./pm-agent-registry.sops.yaml.example).

@@ -99,8 +101,11 @@ Both are deliberate, and both fail **visibly** rather than silently:

   They hold the **same** Gitea token in two formats, because a Secret cannot be both — the
   same one-value-in-two-files pattern the Keycloak client secret already uses here. So mint
-   it once, with all three scopes: `read:package` (the pull), `write:repository` (clone,
-   branch push, pull request) and `write:issue` (issue comments). The first `.example`
+   it once, with all four scopes: `read:package` (the pull), `read:user` (the dispatcher's
+   startup `GET /user` — Gitea 1.24.3 scopes the whole `/user` group), `write:repository`
+   (clone, branch push, pull request) and `write:issue` (issue comments). The account also
+   needs package *permission*, not just the scope: a `pm-agent-pull` org team with Packages
+   = Read and no repositories (steps in the registry `.example`). The first `.example`
   explains which account to create and why it must *not* be an administrator.

   Until they are filled in: the pull fails `401`, and if you fix only the pull, the
@@ -174,7 +179,7 @@ Job from a committed template. **The model's output is data, never a command.**
 - **The worker's own credentials are inside the model's reach.** The session runs as the same
  uid in the same container as the wrapper, so it can read the environment, including its
  `GITEA_TOKEN` and `CLAUDE_CODE_OAUTH_TOKEN`. There is no isolation between them and none is
-  claimed. What bounds it: the Gitea token is scoped `write:repository, write:issue` on **one
+  claimed. What bounds it: the Gitea token is scoped `read:user, write:repository, write:issue, read:package` on **one
  repository** with no admin permission, and egress reaches only this Gitea and tcp/443.
 - **`world:443` is wider than `api.anthropic.com`.** Cilium can express the tighter rule
  (`toFQDNs`) but nothing in this repository uses FQDN policy and its prerequisite (Cilium's
@@ -51,15 +51,20 @@ data:
  # the dispatcher and its workers share the committed Job template and the env-name
  # contract. A tag here is refused at startup (and would be DENIED by admission anyway).
  #
-  # PLACEHOLDER UNTIL THE IMAGE IS PUBLISHED. The all-zero digest below is deliberately
-  # impossible. CI builds, verifies and — on main — publishes agent-runner
-  # (.gitea/workflows/images.yaml), and Renovate replaces this value with the digest the
-  # REGISTRY returned for the image's `main` tag, in a pull request that also moves the
-  # Deployment's image (same marker, same branch). Nobody pushes this image from a workstation.
-  # Until the first publish the dispatcher starts, fails to pull, and says so — which is the
-  # visible failure, not a silent one.
+  # THE FIRST PUBLISHED DIGEST. CI builds, verifies and — on main — publishes agent-runner
+  # (.gitea/workflows/images.yaml). This value is images run 340's publish (tag
+  # sha-523cd9118f95, which `main` pointed at), read from the registry on 2026-10-30. From here
+  # on Renovate replaces it with the digest the REGISTRY returns for the `main` tag, in a pull
+  # request that also moves the Deployment's image (same marker, same branch). Nobody pushes
+  # this image from a workstation.
+  #
+  # READ BEFORE TURNING PM_DRY_RUN OFF: this digest PREDATES the worker template's
+  # `imagePullSecrets` entry (PR #61). Its baked template has none, and admission now REQUIRES
+  # it — so a worker Job built from this image is DENIED. The merge that adds the entry
+  # changes infra/agent/**, CI re-publishes agent-runner, and Renovate's bump to that digest
+  # is what makes worker Jobs admissible. Until then, dry run is the only mode that works.
  # renovate-digest: image=gitea.home.keithjackson.dev/home-network/agent-runner tag=main
-  PM_WORKER_IMAGE: "gitea.home.keithjackson.dev/home-network/agent-runner@sha256:0000000000000000000000000000000000000000000000000000000000000000"
+  PM_WORKER_IMAGE: "gitea.home.keithjackson.dev/home-network/agent-runner@sha256:c4eba5b3c508bf456a03391ac76f8275e7ea28a829da1450d99f6f6f25c6eb42"

  # --- the model -------------------------------------------------------------
  # The PM only reads a thread and answers with one JSON object, so it holds no tools and
@@ -104,13 +109,21 @@ data:
  # work somebody deliberately handed it while trust is being established, with no code
  # change and no redeploy of anything but this ConfigMap. The operator's call; the default
  # here honours the request as made.
-  PM_REQUIRE_LABEL: ""
+  #
+  # SET TO `agent` FOR THE FIRST RUN (2026-10-30, docs/plans/pm-agent-issue-to-pr.md
+  # follow-up 3). The label does not exist in the repository yet: create it in Gitea
+  # (Issues -> Labels -> New Label, name `agent`) before labelling a test issue.
+  PM_REQUIRE_LABEL: "agent"

  # Dry run: the PM still reads threads, still asks the model and still posts its decision as
  # an issue comment — so the operator can read exactly what it WOULD have done — but creates
  # no worker Job and so changes no code. The honest way to watch this service for a day
  # before letting it write anything.
-  PM_DRY_RUN: "false"
+  #
+  # "true" FOR THE FIRST RUN, and not only for caution: the pinned digest above cannot yet
+  # create an admissible worker Job (see the PM_WORKER_IMAGE comment). Flip to "false" in the
+  # same pull request as — or after — Renovate's first agent-runner digest bump.
+  PM_DRY_RUN: "true"

  # If the gate refuses a worker's change, the branch is NOT pushed by default and the issue
  # gets the gate log instead. Set to "true" to push anyway and open a red pull request —
@@ -48,7 +48,7 @@ spec:
        # It is a hand-maintained marker rather than a computed hash because Flux's
        # Kustomization here does not run a configmap generator; bump it in the same commit
        # as a change to configmap.yaml.
-        pm-agent.homelab.keithjackson.dev/config-generation: "1"
+        pm-agent.homelab.keithjackson.dev/config-generation: "2"
    spec:
      serviceAccountName: pm-agent
      # The kubelet's credential for pulling this image. Not the agent's Gitea credential —
@@ -73,10 +73,12 @@ spec:
          # disagree about the shape the admission policy enforces. Replaced together, in ONE
          # Renovate pull request: both lines carry the same marker, so Renovate treats them as
          # one dependency and bumps them in the same branch. The digest comes from CI's publish
-          # of agent-runner's `main` tag (.gitea/workflows/images.yaml) — the all-zero
-          # placeholder below is impossible on purpose (see configmap.yaml PM_WORKER_IMAGE).
+          # of agent-runner's `main` tag (.gitea/workflows/images.yaml). The value below is the
+          # FIRST publish (images run 340, tag sha-523cd9118f95 = main at the time), read from
+          # the registry's manifest endpoint on 2026-10-30 and pinned by hand once so the
+          # dispatcher does not wait on Renovate's first run; every later bump is Renovate's.
          # renovate-digest: image=gitea.home.keithjackson.dev/home-network/agent-runner tag=main
-          image: gitea.home.keithjackson.dev/home-network/agent-runner@sha256:0000000000000000000000000000000000000000000000000000000000000000
+          image: gitea.home.keithjackson.dev/home-network/agent-runner@sha256:c4eba5b3c508bf456a03391ac76f8275e7ea28a829da1450d99f6f6f25c6eb42
          imagePullPolicy: IfNotPresent
          command:
            - /usr/local/bin/pm-dispatch
@@ -60,11 +60,21 @@
 #     Keycloak service-account token therefore cannot authenticate to Gitea's API or to
 #     git-over-HTTP. Do not "upgrade" this to Keycloak without re-reading that.
 #
-#       Scopes: `write:repository` and `write:issue`. Nothing else — in particular NOT
-#       `write:admin`, NOT `write:organization`, NOT `write:user`.
+#       Scopes, exactly these four (one token serves both Secrets — see
+#       pm-agent-registry.sops.yaml.example):
+#         read:user         GET /user, the dispatcher's startup identity check. Gitea 1.24.3
+#                           puts the whole /api/v1/user group behind the `user` scope
+#                           category (routers/api/v1/api.go), so without it the dispatcher
+#                           CrashLoops on its first call even with an otherwise-valid token.
+#         write:repository  the clone, the branch push, the pull-request create, and the
+#                           dispatcher's reads of pulls/branches/commits.
+#         write:issue       reading open issues and posting issue comments.
+#         read:package      the kubelet's image pull (pm-agent-registry).
+#       Nothing else — in particular NOT `write:admin`, NOT `write:organization`, NOT
+#       `write:user`. (Until 2026-10-30 this list said two scopes; `read:user` was missing
+#       and `read:package` lived only in the registry template.)
 #
-#     `write:repository` covers the clone, the branch push and the pull-request create;
-#     `write:issue` covers reading and posting issue comments. (The repository's OTHER CI
+#     (The repository's OTHER CI
 #     token, `SETTINGS_API_TOKEN`, is a separate credential with `read:admin` — do not
 #     conflate them, and do not give this service that one. The 2026-10-02 measurement on
 #     PR #38 recorded in infra/gitea/approval-policy.json is about that token, not this one.)
@@ -94,6 +104,17 @@
 #
 # (4) COPY, FILL, ENCRYPT, COMMIT:
 #
+#     `sops` IS IN THE PINNED TOOLBOX, NOT ON THE HOST (measured 2026-10-30: absent from the
+#     workstation's PATH; sops 3.9.4 and vi in the toolbox). The simplest path needs no
+#     plaintext file at all — edit the committed, already-encrypted file in place, from a
+#     worktree, the way runbooks/vpn-remote-access.md does for its key:
+#
+#       ./infra/devcontainer/dev.sh run sops platform/pm-agent/pm-agent-credentials.sops.yaml
+#
+#     It opens vi on the decrypted document; replace the REPLACE-ME value(s), save, quit, and
+#     sops re-encrypts on write. If you take the cp route below instead, run the `sops -e -i`
+#     line through `./infra/devcontainer/dev.sh run` as well, and delete any plaintext temp file.
+#
 #       cp platform/pm-agent/pm-agent-credentials.sops.yaml.example \
 #          platform/pm-agent/pm-agent-credentials.sops.yaml
 #       $EDITOR platform/pm-agent/pm-agent-credentials.sops.yaml      # the two real values
@@ -120,7 +141,7 @@ metadata:
 type: Opaque
 stringData:
  # Gitea token for the dedicated, NON-ADMIN `pm-agent` account.
-  # Scopes: write:repository, write:issue.
+  # Scopes: read:user, write:repository, write:issue, read:package.
  gitea-token: REPLACE-ME-gitea-token
  # Output of `claude setup-token` on a subscription account. One year's validity.
  claude-code-oauth-token: REPLACE-ME-claude-code-oauth-token
@@ -34,12 +34,31 @@
 #     package and nothing else.
 #
 # (2) ADD THE PACKAGE SCOPE. Gitea token scopes are fixed at creation, so this means
-#     generating a token with all three scopes and using it in BOTH Secrets:
+#     generating a token with all four scopes and using it in BOTH Secrets:
 #
 #       read:package        <- NEW, what the kubelet needs to pull
+#       read:user           <- the dispatcher's startup GET /user (Gitea 1.24.3 scopes it)
 #       write:repository    <- the agent's clone / branch push / pull-request create
 #       write:issue         <- the agent's issue comments
 #
+#     THE SCOPE IS NOT THE PERMISSION. `read:package` only lets the token use whatever
+#     package access the ACCOUNT has, and these packages belong to the ORGANISATION
+#     (`home-network/…`), not to a repository. Gitea 1.24.3 decides org-package access in
+#     services/context/package.go `determineAccessMode`: the highest Packages-unit mode of
+#     any org team the user is in, else READ if the org is visible to that user. Home-Network
+#     is `public` today (measured 2026-10-30), so a signed-in non-member already gets read —
+#     but that is a side effect of a visibility setting nobody chose for this. Make it
+#     explicit, and independent of visibility:
+#
+#       Organisation Home-Network -> Teams -> New Team
+#         name: pm-agent-pull     permission: none (unit-level)
+#         repositories: NONE (do not tick "all repositories")
+#         units: Packages = Read; every other unit = No Access
+#       then add `pm-agent` as its only member.
+#
+#     That grants package read on the org and nothing on any repository; the repo `Write`
+#     comes only from the collaborator entry in the credentials template.
+#
 #     Gitea -> (as pm-agent) Settings -> Applications -> Generate New Token.
 #     Put the SAME value in `pm-agent-credentials` (`gitea-token`) and in the
 #     `.dockerconfigjson` below. One token, two consumers, two formats — the same
@@ -64,6 +83,17 @@
 #
 # (4) COPY, FILL, ENCRYPT, COMMIT:
 #
+#     `sops` IS IN THE PINNED TOOLBOX, NOT ON THE HOST (measured 2026-10-30: absent from the
+#     workstation's PATH; sops 3.9.4 and vi in the toolbox). The simplest path needs no
+#     plaintext file at all — edit the committed, already-encrypted file in place, from a
+#     worktree, the way runbooks/vpn-remote-access.md does for its key:
+#
+#       ./infra/devcontainer/dev.sh run sops platform/pm-agent/pm-agent-registry.sops.yaml
+#
+#     It opens vi on the decrypted document; replace the REPLACE-ME value(s), save, quit, and
+#     sops re-encrypts on write. If you take the cp route below instead, run the `sops -e -i`
+#     line through `./infra/devcontainer/dev.sh run` as well, and delete any plaintext temp file.
+#
 #       cp platform/pm-agent/pm-agent-registry.sops.yaml.example \
 #          platform/pm-agent/pm-agent-registry.sops.yaml
 #       # paste the one-line JSON from step 3 as the .dockerconfigjson value