fix(node-image): give the bake its policy and credential in binjovi-builds #459
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/node-image-job-namespace"
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?
The ARM bake moved from an Argo Workflow in
workflowsto a native Job inbinjovi-builds. Its ServiceAccount exists in both namespaces, so that lookedfine. Two things did not move with it:
CiliumNetworkPolicy/binjovi-node-image-bakeexisted only inworkflows.A pod carrying these labels with no policy in its namespace loses egress
silently — the git fetch and the candidate push just hang.
ClusterSecretStore/binjovi-node-image-candidate-registryadmitted onlyworkflows, so the candidate dockerconfig ExternalSecret could not becreated in
binjovi-buildsat all.The first live bake caught the second one loudly:
This is the dangling-reference class the migration plan already names — a
reference that resolves today may be scoped to a namespace being left behind.
Check the Secret, the ServiceAccount and the NetworkPolicy before repointing
a consumer.
The new policy grants strictly less
kube-apiserver— the Job setsautomountServiceAccountToken: false,so there is no token to use one with. Argo needed it for its executor sidecar.
minio— the Argo pod archived its own logs. Binjovi reads a Job'slogs through the API, so the pod never talks to object storage.
What is left is DNS, the Forgejo git fetch, and the zot candidate push.
Guard
It now pins the namespace set of these policies rather than "at least one",
because "at least one" is exactly what let this ship broken. Verified with a
negative control: deleting the
binjovi-buildspolicy from a scratch copy failsthe check, and restoring it passes.
tests/check.shgreen.https://claude.ai/code/session_01KZoQin34jeyt6nDGqvJA76
The ARM bake moved from an Argo Workflow in ns workflows to a native Job in ns binjovi-builds. Its ServiceAccount exists in both namespaces, so that looked fine. Two things did not move with it: * CiliumNetworkPolicy binjovi-node-image-bake existed only in workflows. A pod carrying these labels with no policy in its namespace loses egress SILENTLY -- the git fetch and the candidate push just hang. * ClusterSecretStore binjovi-node-image-candidate-registry admitted only workflows, so the candidate dockerconfig ExternalSecret could not be created in binjovi-builds at all. The first live bake caught the second one loudly: MountVolume.SetUp failed for volume "docker-config": secret "binjovi-hetzner-node-image-candidate-dockerconfig" not found This is the dangling-reference class the migration plan already names: a reference that resolves today may be owned by something being retired, or scoped to a namespace being left behind. Check the Secret, the ServiceAccount AND the NetworkPolicy before repointing a consumer. The new policy grants strictly LESS than the Argo one: * no kube-apiserver -- the Job sets automountServiceAccountToken: false, so there is no token to use one with. Argo needed it for its executor. * no minio -- the Argo pod archived its own logs. Binjovi reads a Job's logs through the API, so the pod never talks to object storage. What is left is DNS, the Forgejo git fetch and the zot candidate push. The guard now pins the namespace SET of these policies rather than "at least one", because "at least one" is exactly what let this ship broken. Verified with a negative control: deleting the binjovi-builds policy from a scratch copy fails the check. Claude-Session: https://claude.ai/code/session_01KZoQin34jeyt6nDGqvJA76