Support security job images with verified embedded library #87
No reviewers
Labels
No labels
app-migration
bug
ci-cd
cluster
Documentation
duplicate
enhancement
gpu
invalid
networking
question
security
Storage
wontfix
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
Homelab/workflows!87
Loading…
Reference in a new issue
No description provided.
Delete branch "kiyi/security-runtime"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Security and delivery jobs reinstall the released library and verified tools on every run. Add eight explicit
preinstalled-*reusable entry points that run the published owned security image and activate its verified workflows v1.33.0 payload. Existing entry points remain byte-identical to reviewed main, retaining the runner-label environment and normal installation.The pinned Forgejo Runner v13.1.0 rejects a present credentials map containing empty values before any step starts. The new entry points require
security_image_digestand authenticate only the fixed owned registry/image; existing entry points contain no container override or pull-credentials map. This corrects the unreleased optional-input design identified in the compatibility review.Both modes preserve existing workflow names, job IDs, display names, outputs, concurrency, operation guards, scanner commands and deployment credential boundaries. Contract tests compare all eight pairs. Image activation verifies library/toolchain bytes and records the actual embedded
library_shain signed receipts. Existing report artifacts retainsecurity-runtime.jsonwith actual patched versions, source/module locks and binary hashes. Scanner logic remains the released v1.33.0 payload.The security image release is published at
sha256:67cb01038ac30c796e45c894db75689bc70ec1b750736a6f99beac457fd03cbc, source30ac6cb5762abffe98f6f5b1101e2c716947c116, with source/image decisions, mitigations, SBOM and signed receipt. Publication and runtime acceptance are distinct. New Security image compatibility jobs invoke local reusable fixtures for credential-free legacy startup and authenticated image startup; tests require the production container/activation configuration to match those fixtures. They retain sanitized startup and runtime evidence and perform no application delivery.This PR also contains reusable base-image selection, validation and required-gate implementations, preserving existing check contracts and candidate-owned routing. #88 remains closed. Owning callers adopt the new definitions only after an immutable workflow release; existing releases remain unchanged.
Validation of 15ebb699e2: 337 Linux source tests passed, one integration skip, including native Gitleaks 8.30.1 hook/history tests and operation-parity checks; YAML/Bash scaffold validation and 16 mocked gate cases passed; pinned Ruff defaults, PEP 8/257 and diff checks passed. The actual commit passed the installed staged-secret hook. Hosted compatibility 587, acceptance 585, security 586 and library 588 all passed at this commit. Compatibility 587 exercised both legacy startup without pull credentials and authenticated image startup with verified activation, offline tool smoke checks and retained sanitized provenance.
After owner review and merge, publish the next unused minor workflow release and review owning caller adoption with matching
uses/library_ref, the correspondingpreinstalled-*path and the accepted digest. Detailed procedure. Refs #86 and base-images#39.New commits pushed, approval review dismissed automatically according to repository settings
resolve the gitleaks finding
@gitchegumi, follow-up to the Gitleaks review:
I inspected run 559's retained sanitized decision. Its sole blocker is generic-api-key at tests/test_terraform_catalog.py:89, with zero scanner errors. That file is absent from this PR's HEAD and history. It is introduced by
c477730on kiyi/reusable-terraform-contracts; both branches share the released v1.33.0 ancestor. The repository scan deliberately uses Gitleaks history --all, so it also sees the separate Terraform branch. The indicated test is constructing a public acceptance object key, not a live credential.Per your direction to keep this chat focused on the security image, I have not changed or rewritten the separate Terraform branch, broadened the approved Go mitigation to secret findings, or narrowed history scanning. This Gitleaks review remains open for correction/review on that branch; the new security image does not remove that repository-history blocker.
For this task, b9460f69d5 adds actual patched-toolchain evidence retention to all eight wrappers; 316 local tests (2 existing skips), scaffold validation and 16 mocked cases pass. Hosted library and workflow acceptance checks passed. base-images #40 now has the Go/Python fixes and owner-directed reuse of the exact approved Go mitigation. Its full-image result and signed publication are pending. Publish and accept that image before merging/adopting this PR. #88 remains closed.
Follow-up to the Gitleaks change request and run 559: the public Terraform object-name finding is now addressed in 38b3432ae1.
This applies the same exact rule/path/public-literal review as PR #89, with immutable fixture evidence and a 2026-12-01 expiry. Full all-ref history and working-tree scans remain enabled; a changed value or unrelated credential still blocks. The source fixture is separately clarified on #89. This supersedes the historical blocker described in my earlier follow-up; the new hosted result remains pending.
Validation on this branch: all 49 source-secret/policy tests passed, including real pinned Gitleaks 8.30.1 scans of synthetic history, adjacent changed values, byte-column/line movement and sanitized evidence. No workflow files, scan names or job IDs changed. The push triggered fresh hosted checks; no image publication, release or deployment was dispatched.
Current dependency checkpoint at
38b3432ae1: this PR’s exact-head acceptance, library and source-security checks are green, and its narrow public-object fixture review is present. I am not duplicating the owner’s existing change-request review. The security job-image path still cannot be accepted/used yet: base-images #40 exact-head build run 181 fails to compile Trivy atpkg/iac/scanners/cloudformation/parser/parameter.go:57(json.SkipFunc), so no completed full-image scan, signed publication or digest exists. I posted that concrete build diagnosis on #40. Keep #87 unmerged/unadopted until #40 is fixed, screened and signed as the PR’s publication order requires; source CI green is not image-runtime acceptance.Blocking (default/legacy execution):
.forgejo/workflows/security.yml:30-34and the other seven modified reusable jobs always includecontainer.credentials, butsecurity_image_digestdefaults to empty. With that default, both credential expressions evaluate to empty strings. The pinned Forgejo Runner v13.1.0 callshandleCredentialswhile preparing a Docker job and rejects a present credentials map with an empty username (username is empty) before any step starts. Its empty-image fallback to theruns-onlabel does not bypass that credential check. Existing callers that omit the new input will therefore fail when this library release is adopted, despite the promised unchanged default path. Please make credentials absent in legacy mode (or use another runner-compatible design), and exercise both default and image-selected jobs on the actual runner before release/adoption.I verified the #40 merge and security-image release receipt, and the current exact-head checks and 335 local unit tests pass. Those checks do not execute the new reusable job's empty-input branch; this runner-level failure is not a documentation issue. Stale publication wording in the docs is non-blocking and can be updated separately.
@portegumi, addressed the legacy-startup change request in 15ebb699e2.
The eight existing reusable entry points are restored byte-for-byte to reviewed main: no container override or pull-credentials map is present. Eight explicit
preinstalled-*entry points require the image digest and contain the fixed owned image/registry credentials. Existing workflow names, job IDs, display names, operation guards, outputs and credential boundaries are preserved; contract tests compare all eight pairs.Hosted compatibility run 587, at this exact commit, passed both paths on the actual runner:
sha256:67cb01038ac30c796e45c894db75689bc70ec1b750736a6f99beac457fd03cbc.The run retained sanitized
security-runtime-legacy-startupandsecurity-runtime-image-startupevidence. Tests require the image fixture’s container and activation configuration to match all eight production image entry points.Local validation: 337 Linux source tests passed with one integration skip, including native Gitleaks 8.30.1 hook/history tests; YAML/Bash scaffold validation, 16 mocked gate cases, pinned Ruff/PEP checks and diff checks passed. The published commit passed the installed staged-secret hook. The runbook now documents explicit entry-point adoption and rollback.
PorteGumi, take a look at this one and let me know if it's ready for approval as far as you can see.
Reviewed current head
15ebb699e2in response to GitcheGumi's request. My earlier runner-startup change request is addressed: the eight legacy reusable entry points contain no container/credentials map, and eight separate preinstalled entry points require the digest and use the fixed owned image plus registry credentials. I inspected the changed wrapper, startup fixture, operation-parity tests and base-image gate definitions. Exact-head Actions acceptance, repository security, library checks and both real-runner startup modes are successful. No new code/CI blocker found; this is ready for GitcheGumi's fresh exact-head approval as far as the reviewed source and hosted checks establish. The earlier GitcheGumi REQUEST_CHANGES and my own earlier REQUEST_CHANGES are on older commits and should not be mistaken for current-head approval. I did not independently download/revalidate the published image's signed release receipt in this review; verify that acceptance separately before caller adoption. Nonblocking docs follow-up: README.md and docs/security-image.md still call hosted startup acceptance pending, though the current-head compatibility run passed; docs/base-images.md still mentions v1.30.0 as a future release. Neither is a reason to bypass fresh review or release order. No merge or deployment performed.Follow-up review of
15ebb699e2: my prior runner-startup blocker is resolved. All legacy reusable entry points now omit the container/credentials map, so callers using the original contract avoid the empty-username runner failure. The separate preinstalled entry points require an image digest and use the fixed owned image with registry credentials. I checked the old-to-new diff and operation-parity/startup tests, ran 336 local tests (1 skipped; 961 subtests) and scaffold validation, and verified seven successful exact-head CI contexts including hosted legacy and authenticated-image startup jobs. The published security-image release and matching digest are present. Stale documentation and the subsequent immutable workflow release/caller adoption are follow-ups, not blockers. Approving this head; no merge or deployment performed.