fix(buildkit): the shared daemon is not a project job #421

Merged

binjovi-bot merged 1 commit from fix/buildkit-not-a-project-job into trunk

2026-09-07 15:58:42 +00:00

sean commented

2026-09-07 15:57:44 +00:00

Owner

The shared daemon could not reach minio. Not because of buildkitd-restrict — that was retargeted correctly and minio was removed from its deny list — but because of CiliumNetworkPolicy binjovi-project-jobs, which selects app.kubernetes.io/managed-by=binjovi and hard-denies egress to minio, cnpg, openbao, shipwright-build and 16 more namespaces.

The daemon wore that label, inherited from the Release daemon when the lanes merged. It should never have: binjovi-project-jobs fences short-lived pods running project-controlled code that Binjovi creates. This daemon is long-lived infrastructure delivered by Flux, and the policy written for it is the cluster-scoped buildkitd-restrict.

Cilium resolves deny before allow, so the daemon-s own allow rule for minio:9000 could never win. Left alone this fails the Zelnet package and IBM i RPG lanes at build time, on cutover, with a connection timeout and nothing pointing at a network policy in a different file.

How it was found: probing the live daemon after deploy — nc to postgres and openbao correctly denied, zot and forgejo correctly reachable, minio unexpectedly not — then confirming by testing the same host from the old package daemon, which does not carry the label and reaches it fine. No gate catches this: a policy that denies too much is indistinguishable from a working one until something needs what it denies.

The guard now fails if the label returns. It is anchored to a real label line, because the comment explaining the omission names the label too and a plain match fires on the explanation — which it did, on the first run.

https://claude.ai/code/session_01KZoQin34jeyt6nDGqvJA76

The shared daemon could not reach minio. **Not** because of `buildkitd-restrict` — that was retargeted correctly and minio was removed from its deny list — but because of CiliumNetworkPolicy `binjovi-project-jobs`, which selects `app.kubernetes.io/managed-by=binjovi` and hard-denies egress to minio, cnpg, openbao, shipwright-build and 16 more namespaces. The daemon wore that label, inherited from the Release daemon when the lanes merged. It should never have: `binjovi-project-jobs` fences short-lived pods running project-controlled code that Binjovi creates. This daemon is long-lived infrastructure delivered by Flux, and the policy written for it is the cluster-scoped `buildkitd-restrict`. Cilium resolves **deny before allow**, so the daemon-s own allow rule for `minio:9000` could never win. Left alone this fails the Zelnet package and IBM i RPG lanes at **build** time, on cutover, with a connection timeout and nothing pointing at a network policy in a different file. **How it was found:** probing the live daemon after deploy — `nc` to postgres and openbao correctly denied, zot and forgejo correctly reachable, minio unexpectedly not — then confirming by testing the same host from the old package daemon, which does not carry the label and reaches it fine. No gate catches this: a policy that denies too much is indistinguishable from a working one until something needs what it denies. The guard now fails if the label returns. It is anchored to a real label line, because the comment explaining the omission names the label too and a plain match fires on the explanation — which it did, on the first run. https://claude.ai/code/session_01KZoQin34jeyt6nDGqvJA76

sean added 1 commit

2026-09-07 15:57:44 +00:00

fix(buildkit): the shared daemon is not a project job

binjovi/ci Binjovi completed the frozen plan

Details

ffab9abfab

The shared daemon could not reach minio. Not because of buildkitd-restrict --
that was retargeted correctly and minio was removed from its deny list -- but
because of CiliumNetworkPolicy binjovi-project-jobs, which selects
app.kubernetes.io/managed-by=binjovi and hard-denies egress to minio, cnpg,
openbao, shipwright-build and 16 more namespaces.

The daemon wore that label, inherited from the Release daemon when the lanes
merged. It should never have: binjovi-project-jobs fences short-lived pods
running project-controlled code that Binjovi creates. This daemon is long-lived
infrastructure delivered by Flux, and the policy written for it is the
cluster-scoped buildkitd-restrict.

Cilium resolves deny before allow, so the daemon's own allow rule for
minio:9000 could never win. Left alone this would have failed the Zelnet
package and IBM i RPG lanes at BUILD time, on cutover, with a connection
timeout and nothing pointing at a network policy in a different file.

Found by probing the live daemon after deploy -- nc to postgres and openbao
correctly denied, zot and forgejo correctly reachable, minio unexpectedly not --
and confirmed by testing the same host from the old package daemon, which does
not carry the label and reaches it fine. No gate catches this: a policy that
denies too much is indistinguishable from a working one until something needs
what it denies.

The guard now fails if the label comes back. It is anchored to a real label
line, because the comment explaining the omission names the label too and a
plain match fires on the explanation -- which it did, on the first run.

Claude-Session: https://claude.ai/code/session_01KZoQin34jeyt6nDGqvJA76

binjovi-bot merged commit ffab9abfab into trunk

2026-09-07 15:58:42 +00:00

No reviewers

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

sean/seanfarm!421

No description provided.

Rows
Columns