passwords in ENV about dockerfiles HOT 4 CLOSED

Hi.

There are a few things to consider here.

1. Using ARG in the build phase is a bad idea IMHO. When you use an argument, you end up building a separate image for each set of arguments. As a result, if you have 10 containers, you have 10 separate images. This goes against the generic and shareable image approach. See:

https://oracle-base.com/articles/linux/docker-writing-your-first-dockerfile#arg-env

What's more, this is no more secure. If you replace the values in the file during the build phase, there's nothing to stop you starting the container with an alternate entry point, so it never actually starts ORDS, so these are never encrypted and someone can read the contents of the files unencrypted. This another reason why ARG is bad. Your image (not the container) has the credentials inside it.

2. Some of the sections need the information in the environment variables. For example, the database connection using SQLcl to check if the DB is up before you allow the ORDS configuration to proceed requires the values in the environment variables. The connection attempt needs credentials.

3. The ords_params.properties file is built on each startup, so it needs the connection details to work unchanged. That would be easy to alter this by only building it on first run, but as it stands, all environment variables are needed each time. I may change this bit.

4. On containers startup, it always attempts an ORDS install. As before, this could be altered so it only attempts an install on first run. I may change this bit.

5. I think you have to ask yourself who has access to the system at this level, and what they can do. In my organisation, the only people with access at this level already have access to these passwords, so the risk of exposure is less of an issue. That's no excuse not to try and improve things, but it's a really common issue in Docker containers. Try this for example:

docker run -dit --name mysql57-con -e MYSQL_ROOT_PASSWORD=Password123 -p 3306:3306 mysql:5.7.22

docker exec mysql57-con env

The exposure of environment variable values in this form is really common.

6. There is a real solution for this already exists. Lookup docker secrets. As far as I am aware they are only available if you are using compose or swarm (or other orchestration), not straight Docker on its own, but secrets is the way you handle stuff you don't want exposed.

The issue is, this is play around stuff to help people get to grips with Docker, not a production ready build. As a result, if I start adding in extra stuff like secrets, multi-stage builds and so forth, it makes it harder for people to see how it all hangs together, and makes the day 1 experience really bad.

In conclusion, I don't think this is a simple quick fix. There are a number of issues to consider, and in the context of what this is here for, they are probably all out of scope. :)

Cheers

Tim...

from dockerfiles.

Hi Tim,

thank you for your detailed reply! There are some things I did not consider yet... Thank you so much for pointing them out to me.

Yes, I use multiple stages. So the ARG problem is not so important to me.

The container is the most threatened part of my setup. It is usually very close to the internet (apache + proxy forward).

I know this is a very common approach. It seems very weird to me that people encrypt passwords in config files but have an unencrypted copy in memory. This is why I tried to work around this issue. But seems not to be perfect anymore :-). I know that no matter how hard I try there will never be a perfect solution. Even when I only deal with hashed passwords... Somewhere is always a weak point.

But now I can see an advantage in using ENV which is your point (3):
In my Dockerfile I can use dummy passwords. When I first run of my container, I can overwrite the ENV parameters with the real passwords and do all setup tasks. Later I can start the container without overwriting these variables because they are not needed anymore. If someone breaks my container he would see my dummy passwords as plain text and my real passwords as encrypted hash (config files).
(I don't have any SQLcl checks in my docker file... maybe I still need credential for that)

I don't know if this is compatible with a kubernetes... But my current environment needs do not fit kubernetes anyway.

Greetigs
Daniel

from dockerfiles.

from dockerfiles.

You're right! You're right! 🙈 The different levels (build, run, images, stages ...) still confuse me sometimes.
Of course the apache webserver is not in the same container... I was talking about: The problem that there is not much filtering when apache just works as a proxy. I do not always have an influence on the configuration of the apache webserver. Many customers/admins/developers still disable selinux or mod_security etc. rather than configuring it correctly.
So I try to harden my systems/containers as good as I can.

Thank you again for your explanations. By the way, I love your how-tos on oracle-base.com. Keep up the good work :-)

Greetings
Daniel

from dockerfiles.