Stage 2 ran against a real daemon, and both live tests pass - #240
Open
thedancingdeveloper wants to merge 1 commit into
Open
Stage 2 ran against a real daemon, and both live tests pass#240thedancingdeveloper wants to merge 1 commit into
thedancingdeveloper wants to merge 1 commit into
Conversation
The first execution of any part of this repository against a real Docker
daemon. On Node B, in the deployed stack, against a dedicated Docker-in-Docker
daemon beside the controller:
success: True
.. [100%]
An agent reads and writes its own worktree, reads a declared mount, cannot
reach an undeclared sibling path that exists on the host, receives none of the
controller's credentials while still receiving explicitly passed variables, is
denied the network under `network=none` and allowed it under `bridge`, and its
container is gone after teardown.
The evidence package records the image digests, the Komodo update id and the
command to run it again, because "it passed" is not reproducible and a tag
moves.
**The Stage 2 exit is not claimed.** The security profile itself —
no-new-privileges, dropped capabilities, read-only rootfs, resource limits —
is asserted only in the `docker create` argv and never verified from inside a
live container. The nested daemon's own confinement is untested. One sandbox
image has been used, and the last defect this suite found was an assumption
about exactly that. No workload ran.
Also here: the build now pins and bumps the acceptance image by sha. It pinned
`:latest`, and `docker compose run` does not re-pull a tag it already holds --
so the live suite silently re-ran a stale image and reproduced a defect that
had already been fixed and deployed. An acceptance run that cannot name the
image it ran is not evidence.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The first execution of any part of this repository against a real Docker daemon — on Node B, in the deployed stack, against a dedicated DinD daemon beside the controller.
An agent reads and writes its own worktree, reads a declared mount, cannot reach an undeclared sibling path that exists on the host, receives none of the controller's credentials while still receiving explicitly passed variables, is denied the network under
network=noneand allowed it underbridge, and its container is gone after teardown.The evidence package records image digests, the Komodo update id and the reproduction command — "it passed" is not reproducible and a tag moves.
The Stage 2 exit is NOT claimed
no-new-privileges, dropped capabilities, read-only rootfs, resource limits, recorded digest) is asserted only in thedocker createargv and never verified from inside a live container.Also here
The build now pins and bumps the acceptance image by sha. It pinned
:latest, anddocker compose rundoes not re-pull a tag it already holds — so the live suite silently re-ran a stale image and reproduced a defect that had already been fixed and deployed (:latestwassha256:d73e54bd…, the current buildsha256:9808728b…). An acceptance run that cannot name the image it ran is not evidence.