Improving the Security of Containerized Workloads using Transparency and Traceability Services arxiv.org
Verifiable container image distribution with transparency logs, one-time signing keys, and admission-time policy checks for supply-chain...
3 comments
Had a similar mess when I wired up GitHub Actions to push images from a runner with a long-lived registry token, then a dumb rebuild picked up a stale layer and the admission controller in our test cluster happily accepted it because the tag looked fine.
I ended up bolting on a tiny transparency log check in front of deploy, mostly because I was tired of squinting at `kubectl describe` at 2am while the image digest on my laptop didnt match what prod had.
I ran into the same tag vs digest confusion, and the one thing this setup adds that feels genuinely useful is the one-time signing key per build, since a leaked registry token stops being the whole story if the admission side also insists on a log entry tied to the signer identity.
If the signing key is one-time per build, how does the verifier decide whether a later image from the same source is a legitimate rebuild or just a new artifact that should be blocked?