Ahh yes, I probably should add this in when I revise the article for 2019.
Yup secrets built into containers : especially in particular public containers are a big one.
Mitigation beyond "not placing them in dockerfile" however is much more complicated.
Beyond that : only solutions like vault, or for every docker management system - be it kubernetes or swarm, text file based secrets management. Are currently the only main options.
For compose, and environment variables however : the practise is to simply not use it publicly but internally.
For heavily regulated industries, as far as I know. They would instead isolate the docker management system, and container repository from the developers. Where only a sysadmin (who has the keys anyway) could then perform the deployment, after building the containers from the source code into repository.
Not ideal as its not full CI/CD, and can sometimes be somewhat manual in the process
Great article. I think I have touched all issues you mentioned, and most of the time as expected. This article should be a must-read for all that consider using docker, but alas, too many developers just make it work not considering future consequences like how docker behave with a full disk or low RAM.
For the security that you discuss with @Artemis;
Hashicorp Vault works fine, but is not persistent as you mention in the article. Though you can connect Vault to any backend storage like Consul, HSM or just flat storage area with Vaults own encryption.
Still there will be a problem with public containers since the secrets are stored as plain text, and even in a specific location.
In a project, we got around it by using automatic generated passwords for containers like that, which means that if a container gets hacked, all that has to be done is restart the container and a new password is given.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.