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
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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