Are Your Builds Running Separately from Your Production Cluster? (Q1)
summary
Claim: never run CI builds on the same Kubernetes production cluster because a compromised Dockerfile can execute arbitrary commands during image builds. Demo uses Docker BuildKit to mount secrets and shows an image build opening a listener on port 9001 and exfiltrating an environment secret. If the build agent shares the docker socket with production, that build can start containers or access host resources, effectively gaining root. Mitigations shown: sandbox builds, use dedicated build hosts and move to rootless docker.
AI-written summary · about
chapters (5)
- 0:00Intro
- 4:30Are your builds running separately from your production cluster?
- 5:16Don't run builds in your production cluster
- 7:16Demo
- 11:45Don't run builds in your production cluster continued
related talks
30mRootless, Reproducible, and Hermetic: Secure Container Build Showdown
34mUnprivileged Image Builds: What are the Challenges and Where are we Today?
43mBuilding Docker Images on Kubernetes: A Long Journey!
46mA Security State of Mind: Continuous Security with Kubernetes
21mContinuous Security by Design
43mContainer Security: So Many Options, Use Them All!
47mReverse Engineering and Exploiting Builds in the Cloud
34mHow to Contain Security in your Containers