Database/Container, Kubernetes & orchestration
OpenShift builds: docker-build pod gets a writable hostPath mount of the node's kubelet pull secret
Impact
The docker-build container is given the node's /var/lib/kubelet/config.json through a hostPath mount that is not read-only. Anyone who can run a build on the cluster can read the node-level registry credentials used to pull from private repositories, and can also overwrite the file. Overwriting it stops the node pulling new images, which on a GPU node means replacement pods for a failed inference or training workload cannot start and the node is effectively out of the scheduling pool until an operator repairs it by hand. The credential read is the worse half: node pull secrets are usually shared fleet-wide, so one tenant build reaches a registry identity that spans every node.
Who can reach it
Any authenticated user with permission to create or run builds in the cluster (a namespace with build access is enough). No node access and no cluster-admin required.
What to do
Apply the OpenShift errata for your minor version (RHSA-2025:9269, RHSA-2025:9278, RHSA-2025:10270, RHSA-2025:10294, RHSA-2025:10747 cover 4.12 through 4.19). The fix ships through the cluster update channel, so plan it as a normal z-stream update rather than a one-daemon restart. Until it lands, restrict who can create builds, and treat the node pull secret as exposed on any cluster where untrusted tenants have build rights - rotate those registry credentials.
References
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.