Suggestion: isolate RUN using another container (in the same pod)?

[AkihiroSuda]

If a malicious image is specified in FROM accidentally (e.g. due to a typo), the attacker can easily steal GCP credential via /secret.

To prevent such attacks, how about isolating RUN instruction using another container in the same pod, via a shared volume?

• "master" container downloads base images and the build context using /secret, and extract them to a shared volume. Then it pings the "worker" container via some RPC, probably via an UNIX socket in the shared volume.
• "worker" container (without access to /secret) builds the image and responds to the "master"
• "master" container pushes the image using /secret.

[dlorenc]

Good suggestions!

The secret should be scoped to only allow pushes to a registry, but separating the push portion from the build portion would allow us to restrict the push secret even further.

[alexellis]

Any updates on this? Does this observation from @AkihiroSuda affect whether this is secure/ready for use with untrusted builds? Thanks

[dlorenc]

I wouldn't suggest using kaniko (or anything else available today) on untrusted builds without wrapping it inside another security boundary, like kata containers or gvisor.

We've tested and documented with gvisor.

The main goal for now is to support trusted builds inside any standard cluster without requiring extra configuration (AllowPrivileged, etc.).

[AkihiroSuda]

kata containers or gvisor

IIUC it does not solve the credential leakage issue, right? (unless gvisor allows the kaniko process in the container to set up apparmor-equivalent)

[AkihiroSuda]

Landlock was merged into kernel 5.13, so I guess kaniko can be modified now to use landlock to restrict /secret access (maybe after the seccomp profile of Docker/containerd is updated to support landlock)

https://landlock.io/