New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
AkihiroSuda opened this Issue Apr 17, 2018 · 4 comments

Comments

Projects
None yet
3 participants
@AkihiroSuda

AkihiroSuda commented Apr 17, 2018

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

This comment has been minimized.

Member

dlorenc commented Apr 17, 2018

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

This comment has been minimized.

alexellis commented Jun 26, 2018

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

@dlorenc

This comment has been minimized.

Member

dlorenc commented Jun 26, 2018

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

This comment has been minimized.

AkihiroSuda commented Oct 3, 2018

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment