Komodo image-update dispatch credential preparation — 2026-10-30

Why this credential is separate

The optional request-image-pin-updates Action failed at Update 6ae544d09a29a6ea1a94f4a9 before dispatch because its Core-only token was absent. This is distinct from the corrected native image-check inventory accounting. The requested proposal was completed through the supported manual workflow as run 41155852028, which opened draft PR #554. Neither that proposal nor this credential preparation deploys workloads.

Credential preparation

The owner created a fine-grained GitHub token and supplied its private password-manager location. It was retrieved without logging its value, validated as a fine-grained token, and authenticated against the repository's image-update workflow with HTTP 200. Only the token value was encrypted into services/komodo/image-updates.sops.yaml, using the repository's existing three age recipients. Plaintext remained in process memory; no plaintext file, command-line token argument or shared environment was used. The ciphertext contains exactly the dispatch key and SOPS metadata.

The required policy is repository spadoople/homelab, Actions write and mandatory Metadata read only; no Contents write, Pull requests or administration permissions. Workflow-read authentication does not prove Actions write or absence of extra grants. Do not claim token permissions were fully inspected through GitHub's read response.

GitHub reports expiry 2027-11-01 01:39:10 UTC, consistent with the owner's October 31 local-date expiry. The owner owns rotation; renew by 2027-10-24, then repeat encrypted review, private rendering, controlled Core recreation and check-only qualification. No automated rotation or reminder has been installed.

Qualification boundary

A second password-manager access request timed out before an HTTP dispatch request could be made. Planned check-only request 6b286dba-a592-4c65-ac97-5b3e8a6c86df was reconciled against the latest workflow runs with no match. No dispatch is accepted or successful, and Actions-write permission remains unverified. Do not blindly retry an ambiguous request; inspect exact UUID-bearing runs before issuing new work.

No production credential file, host checkout, service configuration, permission, schedule or running container was changed. The encrypted source is preparation, not proof that Core has loaded it. Owner confirmation of a maintenance window and reviewed merge are required before host rendering or Core recreation.

Remaining controlled rollout

Follow the credential and maintenance runbook. Verify the reviewed ciphertext and unchanged renderer/Compose, drain competing writers/callers, validate unchanged existing database credentials and preserve the rollback state. Render only the root-owned Core input under /etc/homelab/komodo-core (parent 0700, file 0600); never relax permissions or copy the token into shared compose.env, Periphery, relay or runner credentials.

Once authorized, recreate Core only, not Mongo or Periphery. Verify database, Core and Periphery health privately, then run one check-only dispatch through Komodo and require its exact successful Update plus matching successful, non-skipped GitHub check run. No proposal, image pull, application deployment or automatic merge is part of qualification. Existing workload containers must remain untouched.

Before loading, rollback means withholding this optional input: the manual workflow remains available. After loading, rollback requires controlled Core-only recreation with the prior input set; do not rotate shared secrets or the database to undo this consumer-specific change. Preserve the credential in approved encrypted storage; do not delete or relocate backup artifacts as part of this task.