Since you expect a secret to be present during build, I assume you pass it in as argument during build time and your question is: how do I access a secret I passed in into the build during the build?
Note: during build, each instruction creates a new container that uses the outcome of the previous instruction. Between instruction no process will remain running. Secrets are not persisted in the image, so if you didn’t pass a secret as argument into the build, there will be no secret available.
Ya, but I feel @amirulandalib seem to expect that it’s possible to extract secrets from an existing image…
You still need to configure a secret to use it, don’t you?
I guess I can’t extract it after googling it I found that it is encrypted I just wanted to check if it that dockerfile has any miners loggers stealers etc
To be honest, it is completly unclear what you want, as your posts are too ambigous (at least for me) and you don’t respond to any input. Have you tried to use google translate to translate the input to your native language - usualy the translation is good enough to get a fair understand.
If you just want to explore/browser an image, use GitHub - wagoodman/dive: A tool for exploring each layer in a docker image.
This will be my last response in this topic, because it is getting nowhere.
The problem is that we don’t know anything about how you created that secret. @meyay had questions that you have not answered. Since our answers depend on your answers to our questions, we can’t answer yours.
If the image is yours and you defined that secret, you should know what it was
If the image is not yours or you did not define the secret, because you ran a script downloaded from the internet, then you will not be able to get its value, since the secret does not exist anymore.
The instruction you quoted before
seems strange, since it wants to execute the secret. I guess it was an attempt to get the value, however, the secret will exist only in the container when you define it in the Dockerfile like this:
RUN --mount=type=secret,id=mysecret cat /run/secrets/mysecret
Very much agreed, and I can understand why the OP may be curious/worried about that smelly line, thinking/run/secrets/ would be part of the image, so thinking it was going to execute something they could not see nor control. But indeed the following is key in understanding it’s not part of the image at all:
Ah, I fooled myself into assuming the last line was the ENTRYPOINT used when running the container. It’s not So, the RUN command is really just an instruction to run when creating the image. I did not know /run/secrets would be available during creation of an image too, but why not. Still smelly, I feel!
(To see what is in the image simply run it using docker run -it anasty17/mltb and then browse around in the Bash shell you’ll get. To use it as intended see the Dockerfile on GitHub.)
Personaly; I would stay away from that image, as the whole magic is hidden away in a bash script handed into the container as secret during build time.
Something seems to make it necessary to obfuscate the image creation…
Curious: is there an easy way to see the difference between a previous layer and the final one, so before and after the secret was executed?
Of course, the very first:
ADD file:00dae10e79b05c4e1a3db053a1f85a4f38a39fe85cbbd88d74201a01a7dd59b5 in /
…which I guess copies the contents of a 27.5 MB directory into subfolders of the root (or is truly a file which is then handled when executing that secret), may already add shady things as well. Or not.
(Oh, that’s how Hub shows any file that is copied.)
Docker shows a build step that copies some 27 MB folder into subfolders of the image’s root, and another step involves executing some secret. Both make That makes it hard to see what’s really included in the image.
The ADD instruction is just in base images to add the base filesystem to a scratch image. You will see a similar instruction in every bases image. If you are curious what’s added, you can explore the layer with dive: docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive:latest anasty17/mltb:latest. It is as worrying as the RUN instruction that executes an arbitrary bash script.
The whole image is a black box! It is used as base image in the Dockerfile from the GH repo. I guess the GH repo is ment to be used for personal customizations of some sorts.
What I saw in the image, more or less seem to match the description of the GH repo. Some filesharing clients, some cloud storage connectors, a qbittorrent client. Oddly I have seen x11 and pulseaudio beeing added when investigating the layers with dive.
update: the ADD instruction adds a very slim ubuntu base-os tar as first layer, most likely created using debootstrap.