Move secrets out of ENV.

[ajcollett]

Secrets are tricky to do well. But it seems that many think having them in the ENV is a bad idea.

Some opinion around the issue.

I propose that config is stored in the ENV, but Secrets are moved to files that are mounted as volumes with restricted access. This is basically how Dockers own Secrets system works.

Some guidance as to why this is a good idea.

Basically, this would mean that a file represents either one secret, or a bunch of secrets are stored in one file. Mariadb/Mysql already supports reading secrets from a file.

The official MariaDB allows the use of secrets.

[ajcollett]

@DawoudIO @jaskipper thoughts?

[jaskipper]

I agree. Let me get a working setup again, and then we can look at making this better. I do think that it needs to be simple for anyone who wants to try it to just set it and run it. Not sure how much complexity that adds to the installation. I'll read the links that you've shared. Thanks!

[crossan007]

Yes. Let's try to follow the most-secure best practices.

[ajcollett]

Just to chime in here again. I will have a look at your new branch asap, but another point i didn't mention was that there should be no default password set. Once I look at how you have things I can maybe add something about how best to make this simple and easy to use, without letting users "forget" to change the default pass.

[jaskipper]

The default password for ChurchCRM is a different issue. That would be over on the ChurchCRM repository. The Docker installation is only to get ChurchCRM to run on Docker... if that's what you are talking about. The passwords for MariaDB is different. MariaDB/MySQL set the default pwd's as well, but recommend changing them.

[ajcollett]

Well, maybe we can add a script to create the mariadb secrets? Instead of providing them? Should I put a script together for that? I would consider that a massive win over having default passwords. Especially for the DB, where the sysadmin hardly ever has to interact with the password (there-by leaving a good chance that it is never changed). Front-end... well the same applies, but at least that is more "obviously" something that needs to be changed by the user.

[jaskipper]

I agree that it is an issue. I think that a script would be great... but I'm a little worried that it's not very Docker like...

Docker builds are non-interactive, so we could set up a script to create the Docker Secrets file on the host... but doesn't that make it even more complicated for the end user?

[ajcollett]

I think that is exactly what i mean. This bit of complexity is good.

If the pipeline is:
Enter variables in .env -> Run secret setup script -> run docker-compose up

Then I think we are not adding too much complexity.

Alternatively, simple document that these secrets must be created, and docker will complain if the secrets don't exist. I don't think that is too much to expect someone to be able to do.

[jaskipper]

Actually, the setup script wouldn't be necessary, since the user would still be entering the variables into the SECRETS file (Same as .env, but now Docker Secrets). We can leave the defaults blank, and as you say Docker will complain if they don't exist. We can make the Shell Output very clear that they need to enter the values and rerun the build script.